Amazon EMR에서 Apache Knox를 사용하여 경계 보안 구현

KENNETH

4년 ago

Amazon EMR에서 Apache Knox를 사용하여 경계 보안 구현

경계 보안은 클러스터 외부에서 액세스하는 사용자에게 안전한 Apache 하둡 클러스터 리소스를 제공하는 데 도움이 됩니다. Apache 하둡 클러스터와의 모든 REST 및 HTTP 상호 작용을 위한 단일 액세스 지점을 제공하여 클라이언트와 클러스터의 상호 작용을 간소화합니다. 예를 들어 클라이언트 애플리케이션에서 Kerberos가 활성화된 클러스터의 서비스와 상호 작용하려면 Kinit 또는 SPNEGO를 사용하여 Kerberos 티켓을 받아야 합니다. 이 게시물에서는 Apache Knox를 설정하여 Amazon EMR 클러스터의 경계 보안을 활성화하는 단계를 알아봅니다.

이 작업을 완료하면 다음과 같은 이점을 얻을 수 있습니다.

다양한 하둡 서비스 및 UI의 인증 간소화
프록시 기능을 제공하여 서비스의 특정 URL/포트 숨기기
경계에서 SSL 종료 지원
여러 클러스터에 게시된 엔드포인트를 간편하게 관리

개요

Apache Knox

Apache Knox는 REST API 엔드포인트를 이용해서 하둡 클러스터에 액세스할 수 있는 게이트웨이를 제공합니다. 엔터프라이즈 자격 증명 관리 솔루션을 통합하고 클러스터 배포에 대한 세부 정보를 숨김으로써 클라이언트에서 하둡 클러스터의 서비스와 간편하게 상호 작용할 수 있도록 합니다.

이 게시물에서는 다음과 같은 단계를 실행합니다.

Amazon VPC를 기반으로 하는 VPC(가상 프라이빗 클라우드) 생성
Active Directory 도메인 컨트롤러에 대한 Amazon EC2 Windows 인스턴스 프로비저닝
Kerberos 및 교차 영역 신뢰에 대한 Amazon EMR 보안 구성 생성
EMR 마스터 노드에 Knox를 설정하고 LDAP 인증 활성화

다음은 생성할 리소스를 도식화한 것입니다.

그림 1: CloudFormation으로 프로비저닝된 인프라

사전 조건 및 가정

시작하기 전에 다음과 같은 사전 조건을 충족해야 합니다.

AWS 서비스에 대한 액세스를 제공하는 AWS 계정
AWS CLI 구성을 위한 액세스 키 및 보안 액세스 키가 있는 AWS Identity and Access Management(IAM) 사용자

중요: 템플릿에는 하드코딩된 사용자 이름 및 암호와 개방형 보안 그룹이 사용됩니다. 이러한 템플릿을 수정 없이 프로덕션 환경에서 사용해서는 안 됩니다.

참고:

네트워크를 간소화하기 위해 단일 VPC를 사용합니다.
CloudFormation 템플릿에는 단순하게 하드코딩된 사용자 이름 및 암호와 개방형 보안 그룹이 사용됩니다.

구현

원클릭 솔루션 배포

각 구성 요소를 개별적으로 설정하지 않으려는 경우 원스텝 AWS CloudFormation 템플릿을 사용할 수 있습니다. 이 원스텝 템플릿은 중첩된 스택(추가 템플릿)을 사용하여 솔루션에 필요한 모든 리소스를 단일 작업으로 시작하고 구성하는 마스터 템플릿입니다.

전체 솔루션을 시작하려면 아래의 [Launch Stack] 버튼을 클릭하여 콘솔로 이동하십시오. 이 템플릿은 US-EAST-1 리전에서만 작동하도록 설계되었으니 다른 리전으로 변경하지 마십시오.

이 템플릿을 사용하려면 여러 파라미터를 구성해야 합니다. 아래 표에서 *로 표시된 파라미터에 대한 값을 제공해야 합니다. 나머지 파라미터에는 기본값이 지정되어 있으며 수정할 수 없습니다.

	파라미터	사용할 값
1	도메인 컨트롤러 이름	DC1
2	Active Directory 도메인	awsknox.com
3	도메인 NetBIOS 이름	AWSKNOX(도메인의 NetBIOS 이름(최대 15자))
4	도메인 관리자	도메인 관리자로 추가할 계정의 사용자 이름(awsadmin)
5	도메인 관리자 암호 *	도메인 관리자의 암호 문자, 숫자 및 기호를 포함한 8자 이상(예: CheckSum123)
6	키 페어 이름 *	도메인 컨트롤러 인스턴스에 대한 액세스를 지원하는 기존 EC2 키 페어의 이름
7	인스턴스 유형	도메인 컨트롤러 EC2 인스턴스의 인스턴스 유형
8	LDAP Bind 사용자 이름	LDAP Bind 사용자 이름 기본값: CN=awsadmin,CN=Users,DC=awsknox,DC=com
9	EMR Kerberos 영역	EMR Kerberos 영역 이름. 일반적으로 대문자로 된 VPC의 도메인 이름(예: EC2.INTERNAL)
10	교차 영역 신뢰 암호 *	교차 영역 신뢰를 위한 암호(예: CheckSum123)
11	신뢰하는 Active Directory 도메인	신뢰하려는 Active Directory 도메인. Active Directory 이름과 동일하지만 대문자로 표기됩니다. 기본값: “AWSKNOX.COM”
12	인스턴스 유형	도메인 컨트롤러 EC2 인스턴스의 인스턴스 유형 기본값: m4.xlarge
13	인스턴스 개수	EMR 클러스터의 코어 인스턴스 수. 기본값: 2
14	허용되는 IP 주소	클러스터에 연결할 수 있는 클라이언트 IP 주소. IP 주소 범위를 CIDR 표기법으로 지정합니다(예: 203.0.113.5/32). 기본적으로 VPC CIDR(10.0.0.0/16)만 클러스터에 연결할 수 있습니다. SSH를 사용하여 클러스터에 연결할 수 있는 클라이언트 IP 범위를 추가하십시오.
15	EMR 애플리케이션	클러스터에 설치할 애플리케이션의 쉼표로 구분된 목록. 기본적으로 “하둡,” “Spark,” “Ganglia,” “Hive” 및 “HBase”가 선택됩니다.
16	LDAP 검색 기준	LDAP 검색 기준. 유일한 값: “CN=Users,DC=awshadoop,DC=com”
17	LDAP 검색 속성	LDAP 사용자 검색 속성을 제공합니다. 유일한 값: “sAMAccountName”
18	LDAP 사용자 객체 클래스	LDAP 사용자 객체 클래스 값을 제공합니다. 유일한 값: “person”
19	LDAP 그룹 검색 기준	LDAP 그룹 검색 기준 값을 제공합니다. 유일한 값: “dc=awshadoop, dc=com”
20	LDAP 그룹 객체 클래스	LDAP 그룹 객체 클래스를 제공합니다. 유일한 값: “group”
21	LDAP 멤버 속성	LDAP 멤버 속성을 제공합니다. 유일한 값: “member”
22	EMRLogDir *	EMRLogs가 저장되는 Amazon S3 버킷을 제공합니다. 또한 “s3://”를 접두사로 제공합니다.
23	S3 버킷	아티팩트가 저장되는 Amazon S3 버킷. 이 예에서 모든 아티팩트는 “aws-bigdata-blog” 퍼블릭 S3 버킷에 저장됩니다. 이 값을 변경하지 마십시오.

각 구성 요소를 개별적으로 배포

원스텝 솔루션의 CloudFormation 템플릿을 사용한 경우 이 섹션을 건너뛰고 클러스터 액세스 섹션으로 이동하십시오. 이 섹션에서는 AWS CloudFormation 템플릿을 사용하여 솔루션의 각 단계를 개별적으로 수행하는 방법을 설명합니다.

1. Amazon VPC 생성 및 구성

이 단계에서는 Amazon VPC, 퍼블릭 서브넷, 인터넷 게이트웨이, 라우팅 테이블 및 보안 그룹을 설정합니다.

Amazon EMR Kerberos 영역과 Active Directory 도메인 간에 교차 영역 신뢰를 설정하려면 Amazon VPC가 다음 요구 사항을 충족해야 합니다.

Amazon EMR 클러스터에 사용된 서브넷에 9자리수 미만의 CIDR 블록(예: 10.0.1.0/24)이 있어야 합니다.
DNS 확인 및 DNS 호스트 이름을 모두 활성화해야 합니다(“yes”로 설정).
Active Directory 도메인 컨트롤러는 Amazon VPC의 인스턴스에 대한 DNS 서버여야 합니다(다음 단계에서 구성함).

콘솔을 통해 직접 시작하려면 [Launch Stack]을 선택하십시오.

2. Active Directory 도메인 컨트롤러 시작 및 구성

이 단계에서는 AWS CloudFormation 템플릿을 사용하여 새 Active Directory 도메인 컨트롤러 및 교차 영역 신뢰를 자동으로 시작하고 구성합니다.

그런 다음 Windows EC2 인스턴스를 시작하고 Active Directory 도메인 컨트롤러를 설치 및 구성합니다. Active Directory 도메인 컨트롤러 및 교차 영역 신뢰를 시작하고 구성하는 것에 더해 이 AWS CloudFormation 템플릿은 도메인 컨트롤러를 Amazon VPC에 대한 DNS 서버(이름 서버)로 설정합니다.

콘솔을 통해 직접 시작하려면 [Launch Stack]을 선택하십시오.

3. Apache Knox를 사용하여 EMR 클러스터를 시작하고 구성

Kerberized Amazon EMR 클러스터를 시작하려면 먼저, 교차 영역 신뢰 구성이 포함된 보안 구성을 생성해야 합니다. 자세한 내용은 Kerberos 인증을 사용하여 Amazon EMR과 Microsoft Active Directory 통합 블로그 게시물을 참조하십시오.

위 블로그에 설명된 단계에 더해 여기서는 Knox에 대한 Kerberos 주체를 생성하는 추가 단계가 EMR 클러스터에 추가됩니다.

또한 CloudFormation 스크립트는 core-site.xml, hive-site.xml, hcatalog-webchat-site.xml 및 oozie-site.xml 파일에서 아래의 파라미터를 업데이트합니다. “create_emr.py” 스크립트에서 이러한 내용을 확인할 수 있습니다. EMR 클러스터가 생성되면 EMR 단계로 셸 스크립트가 실행됩니다. 이 셸 스크립트는 EMR 마스터 머신에 Knox 소프트웨어를 다운로드하고 설치합니다. 이름이 emr-cluster-top인 Knox 토폴로지 파일도 생성합니다.

콘솔을 통해 직접 시작하려면 [Launch Stack]을 선택하십시오.

클러스터 액세스

하둡 서비스에 대한 API 액세스

Apache Knox를 사용하는 주된 이유 중 하나는 사용자의 직접 연결에서 하둡 클러스터를 분리할 수 있기 때문입니다. 아래 데모에서는 Knox 엔드포인트를 통과하는 여러 하둡 서비스(예: WebHDFS, WebHCat, Oozie, HBase, Hive 및 Yarn 애플리케이션)와 REST API를 사용하여 상호 작용하는 방법을 보여줍니다. REST 호출은 EMR 클러스터에서 호출하거나 EMR 클러스터 외부에서 호출할 수 있습니다. 그러나 프로덕션 환경에서는 Knox 포트 번호에 대한 트래픽만 허용하도록 EMR 클러스터의 보안 그룹을 설정하여 다른 모든 애플리케이션에 대한 트래픽을 차단해야 합니다.

이 블로그에서는 LDAP 자격 증명을 사용하여 SSH로 EMR 클러스터의 마스터 노드에 연결하는 방법으로 EMR 클러스터에서 REST 호출을 수행합니다.

ssh awsadmin@<EMR-Master-Machine-Public-DNS>

<EMR-Master-Machine-Public-DNS>를 EMR 클러스터 마스터 노드에 대한 CloudFormation 출력 값으로 바꿉니다. 이 CloudFormation 출력 값은 위의 3단계에서 배포한 스택에서 확인할 수 있습니다.

‘awsadmin’ LDAP 암호를 입력하라는 메시지가 표시됩니다. CloudFormation 스택 생성 과정에서 입력한 암호를 사용하십시오.

참고: 연결하려면 클라이언트 머신의 IP가 CloudFormation 파라미터에서 [Allowed IP address]로 지정된 CIDR 범위에 포함되어야 합니다. 마스터 노드에 연결할 수 없는 경우 마스터 인스턴스의 보안 그룹을 검토하여 EMR 클러스터에 클라이언트의 트래픽을 허용하는 규칙이 있는지 확인하십시오. 그렇지 않은 경우 조직 방화벽에서 트래픽을 차단하는 것일 수 있습니다.

WebHDFS 서비스 API에 대한 액세스 데모:

여기서는 WebHDFS에서 Knox 게이트웨이를 통해 LISTSTATUS 작업을 호출합니다. 이 데모의 설정에서 Knox는 포트 번호 8449에서 실행됩니다. 아래의 명령은 HDFS 루트 디렉터리의 디렉터리 목록을 반환합니다.

curl -ku awsadmin 'https://localhost:8449/gateway/emr-cluster-top/webhdfs/v1/?op=LISTSTATUS'

EMR 마스터 노드의 “localhost” 또는 프라이빗 DNS를 사용할 수 있습니다.

암호를 입력하라는 메시지가 표시됩니다. 암호는 CloudFormation 스택에 매개 변수로 전달된 “도메인 관리자 암호”와 동일합니다.

Resource Manager 서비스 API 액세스 데모:

Resource manager REST API는 하둡 클러스터 상태와 클러스터에서 실행되는 애플리케이션에 대한 정보 등을 제공합니다. 아래의 명령을 사용하여 클러스터 정보를 가져올 수 있습니다.

curl -ikv -u awsadmin -X GET 'https://localhost:8449/gateway/emr-cluster-top/resourcemanager/v1/cluster'

암호를 입력하라는 메시지가 표시됩니다. 암호는 CloudFormation 스택에 매개 변수로 전달된 “도메인 관리자 암호”와 동일합니다.

Apache Knox를 통해 Beeline을 사용하여 Hive에 연결하는 데모:

JDBC 클라이언트 도구인 Beeline을 사용하여 HiveServer2에 연결할 수 있습니다. 여기서는 Knox를 통해 Beeline에 연결합니다.

다음 명령을 사용하여 Hive 셸에 연결합니다.

$hive

다음 구문을 사용하여 Beeline에서 Hive에 연결합니다.

!connect jdbc:hive2://<EMR-Master-Machine-Public-DNS>:8449/;transportMode=http;httpPath=gateway/emr-cluster-top/hive;ssl=true;sslTrustStore=/home/knox/knox/data/security/keystores/gateway.jks;trustStorePassword=CheckSum123

참고: <EMR-Master-Machine-Public-DNS>를 EMR 마스터 노드의 퍼블릭 DNS 이름으로 변경해야 합니다.

Apache Knox를 통해 Apache Livy를 사용하여 Spark 작업을 제출하는 데모

다음 명령을 사용하여 Spark 작업을 EMR 클러스터에 제출할 수 있습니다. 이 예에서는 spark-examples.jar로 제공되는 SparkPi 프로그램을 실행합니다.

curl -i -k -u awsadmin -X POST --data '{"file": "s3://aws-bigdata-blog/artifacts/aws-blog-emr-knox/spark-examples.jar", "className": "org.apache.spark.examples.SparkPi", "args": ["100"]}' -H "Content-Type: application/json" https://localhost:8449/gateway/emr-cluster-top/livy/v1/batches

EMR 마스터 노드의 “localhost” 또는 프라이빗 DNS를 사용할 수 있습니다.

하둡 웹 UI에 안전하게 액세스

Knox를 사용하면 API를 통해 하둡 클러스터에 안전하게 액세스하는 동시에 하둡 UI에 대한 프록시 서비스로 Knox를 사용할 수도 있습니다. 아래에 사용 가능한 UI에 대한 표가 나와 있습니다.

	애플리케이션 이름	애플리케이션 URL
1	Resource Manager	https://<EMRClusterURL>:8449/gateway/emr-cluster-top/yarn/
2	Ganglia	https://<EMRClusterURL>:8449/gateway/emr-cluster-top/ganglia/
3	Apache HBase	https://<EMRClusterURL>:8449/gateway/emr-cluster-top/hbase/webui/master-status
4	WebHDFS	https://<EMRClusterURL>:8449/gateway/emr-cluster-top/hdfs/
5	Spark History	https://<EMRClusterURL>:8449/gateway/emr-cluster-top/sparkhistory/

위의 UI를 처음으로 방문하면 로그인 자격 증명에 대한 드롭다운이 표시됩니다. 로그인 사용자 awsadmin과 CloudFormation 템플릿에 파라미터로 지정한 암호를 입력합니다.

이제 클러스터에 직접 연결된 것처럼 UI를 탐색할 수 있습니다. 다음은 Yarn UI의 예시 화면입니다.

Yarn UI의 스케줄러 정보는 다음과 같습니다.

Ganglia:

Spark History UI:

마지막으로 HBase UI입니다. “master-status” 페이지에 대한 전체 URL을 제공해야 합니다.

문제 해결

Apache Knox와의 상호 작용 중에 오류가 발생하는 경우는 대부분 정해져 있습니다. 아래에 몇 가지 문제에 대한 해결 과정을 설명합니다.

UI에 액세스할 수 없습니다. 오류 코드는 표시되지 않습니다.

Apache Knox가 실행되지 않았을 가능성이 있습니다. 클러스터의 마스터 노드에 로그인하고 “ps -ef | grep knox”를 실행하여 실행 중인지 확인하십시오. 실행 중인 프로세스가 있어야 합니다.

ps -ef | grep knox
Knox 114022 1 0 Aug24 ? 00:04:21 /usr/lib/jvm/java/bin/java -Djava.library.path=/home/knox/knox/ext/native -jar /home/knox/knox/bin/gateway.jar

실행 중인 프로세스가 없는 경우 Knox 사용자(sudo su – knox)로 “/home/knox/knox/bin/gateway.sh start”를 실행하여 프로세스를 시작합니다.

브라우저가 클러스터에 연결되지 않았을 수 있습니다. SSH로 클러스터에 연결할 수 있는 경우에도 방화벽 규칙 또는 보안 그룹 규칙에 의해 Knox가 실행되는 포트 번호에서 트래픽이 차단될 수 있습니다. SSH 터널을 구축하고 포트 전달을 활성화하여 SSH를 통해 트래픽을 라우팅할 수 있습니다.

UI에 액세스할 때 HTTP 400, 404 또는 503 코드가 표시됩니다.

입력한 URL이 올바른지 확인하십시오. 올바른 경로를 입력하지 않으면 Knox가 HTTP 404를 표시합니다.
Apache Knox 내에 라우팅 규칙과 관련된 문제가 있고 요청을 라우팅할 방법을 알지 못하는 경우입니다. Knox에 대한 로그는 기본적으로 INFO 수준에 있으며 /home/knox/knox/logs/에서 확인할 수 있습니다. 로깅 수준을 변경하려면 /home/knox/knox/conf/gateway-log4j.properties:log4j.logger.org.apache.knox.gateway=INFO에서 다음 줄을 변경하십시오.
#log4j.logger.org.apache.knox.gateway=DEBUGto#log4j.logger.org.apache.knox.gateway=INFO
log4j.logger.org.apache.knox.gateway=DEBUG 이 로그에서 Knox의 URL 재작성 방법을 비롯한 추가 정보를 확인할 수 있습니다. Knox가 URL을 올바르게 변환하는지 여부에 대한 정보를 얻을 수 있습니다. 아래의 “ldap”, “knoxcli” 및 “curl” 명령을 사용하여 설정이 올바른지 확인할 수 있습니다. “knox” 사용자로 이러한 명령을 실행하십시오.

검색 기준, 검색 속성 및 검색 클래스를 확인하려면 아래의 ldap 명령을 실행합니다.

ldapsearch -h <Active-Directory-Domain-Private-IP-Address> -p 389 -x -D 'CN=awsadmin,CN=Users,DC=awsknox,DC=com' -w 'CheckSum123' -b 'CN=Users,DC=awsknox,DC=com' -z 5 '(objectClass=person)' sAMAccountName

“<Active-Directory-Domain-Private-IP-Address>”를 Active Directory EC2 인스턴스의 프라이빗 IP 주소로 바꿉니다. 두 번째 CloudFormation 템플릿의 출력에서 이 IP 주소를 확인할 수 있습니다.

서버 호스트, 포트, 사용자 이름 및 암호에 대한 값을 확인하려면 아래의 ldap 명령을 실행합니다.

ldapwhoami -h <Active-Directory-Domain-Private-IP-Address> -p 389 -x -D 'CN=awsadmin,CN=Users,DC=awsknox,DC=com' -w 'CheckSum123'

“<Active-Directory-Domain-Private-IP-Address>”를 Active Directory EC2 인스턴스의 프라이빗 IP 주소로 바꿉니다. 두 번째 CloudFormation 템플릿의 출력에서 이 IP 주소를 확인할 수 있습니다.
아래의 출력이 표시됩니다.

시스템 LDAP 바인드 성공 여부를 확인하려면 다음 명령을 실행합니다.

/home/knox/knox/bin/knoxcli.sh user-auth-test --cluster emr-cluster-top --u awsadmin --p 'CheckSum123'

여기서 “emr-cluster-top”는 사용할 수 있는 애플리케이션과 애플리케이션에 서비스를 제공하기 위해 Knox가 연결해야 하는 엔드포인트를 정의하는 토포로지 파일입니다.
명령 출력에 아래의 출력이 반환되어야 합니다.

“System LDAP Bind successful!”

LDAP 인증 성공 여부를 확인하려면 아래의 명령을 실행합니다.

/home/knox/knox/bin/knoxcli.sh user-auth-test --cluster emr-cluster-top --u awsadmin --p 'CheckSum123'

여기서 “emr-cluster-top”는 생성된 토폴로지 파일 이름입니다.
명령 출력에 아래의 출력이 반환되어야 합니다.

“LDAP authentication successful!”

서비스를 사용하여 직접 WebHDFS에 연결할 수 있는지 여부를 확인합니다.

먼저, 유효한 Kerberos TGT를 받아야 합니다. 그러려면 아래와 같이 kinit 명령을 사용합니다.

kinit -kt /mnt/var/lib/bigtop_keytabs/knox.keytab knox/<EMR-Master-Machine-Private-DNS>@EC2.INTERNAL
curl --negotiate -u : http://<EMR-Master-Machine-Private-DNS>:50070/webhdfs/v1/?op=GETHOMEDIRECTORY

예: ip-xx-xx-xx-xx.ec2.internal 형식의 EMR-Master-Machine-Private-DNS
사용자 홈 디렉터리의 “Path” 변수가 포함된 JSON 객체가 반환되어야 합니다.

정리

CloudFormation 스택을 삭제하여 이 글에서 생성된 모든 리소스를 정리합니다. 중첩된 스택을 사용한 경우 CloudFormation이 단일 작업으로 모든 리소스를 삭제합니다. 템플릿을 개별적으로 배포한 경우 생성 순서와 반대되는 순서로 삭제하고 VPC 스택을 마지막으로 삭제합니다.

결론

이 게시물에서는 Apache Knox를 사용하여 EMR 클러스터에 대한 경계 보안을 설정, 구성 및 검증하는 단계를 살펴봤습니다. 이 단계를 수행하면 다양한 하둡 서비스의 인증이 간소화됩니다. 다음 게시물에서는 Apache Knox와 Apache Ranger를 통합하여 권한 부여 및 감사를 활성화하는 방법을 알아보도록 하겠습니다.

다음 게시물을 기대해 주십시오.

작성자 소개

Varun Rao 는 엔터프라이즈 솔루션스 아키텍트입니다. 클라우드로 전환하는 엔터프라이즈 고객의 데이터 전략 및 보안을 중점적으로 지원하며 여가 시간에는 4살 자녀와 시간을 보내려고 노력합니다.

Mert Hocanin 는 AWS의 빅 데이터 아키텍트로서, EMR, Athena 및 관리형 블록체인을 포함한 다수의 제품을 다룹니다. AWS에서 일하기 전에는 Amazon.com의 소매 비즈니스에서 선임 소프트웨어 개발 엔지니어로 일하면서 회사 전체에서 보고에 사용되는 방대한 양의 데이터를 처리하는 데이터 레이크를 구축했습니다. 데이터를 구축하고 설계하지 않는 여가 시간에는 여행과 맛집 탐방을 즐깁니다.

Srikanth Kodali 는 Amazon Web Services의 선임 IOT 데이터 분석 아키텍트입니다. AWS 고객에게 IoT 데이터 및 분석 솔루션의 구축에 필요한 지침과 기술 지원을 제공함으로써 AWS를 사용하여 이러한 솔루션의 가치를 개선할 수 있도록 합니다.