기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# Amazon EMR 클러스터 노드에 대한 인증
SSH 클라이언트는 Amazon EC2 키 페어를 사용해 클러스터 인스턴스에 대한 인증을 수행할 수 있습니다. 또는 Amazon EMR 릴리스 버전 5.10.0 이상에서는 프라이머리 노드에 대한 사용자 및 SSH 연결을 인증하도록 Kerberos를 구성할 수 있습니다. 또한 Amazon EMR 릴리스 5.12.0 이상에서는 LDAP로 인증할 수 있습니다.
**Topics**
+ [Amazon EMR에서 SSH 자격 증명에 대해 EC2 키 페어 사용](emr-plan-access-ssh.md)
+ [Amazon EMR을 통한 인증에 Kerberos 사용](emr-kerberos.md)
+ [Amazon EMR을 통한 인증에 Active Directory 또는 LDAP 서버 사용](ldap.md)
# Amazon EMR에서 SSH 자격 증명에 대해 EC2 키 페어 사용
Amazon EMR 클러스터 노드는 Amazon EC2 인스턴스에서 실행됩니다. Amazon EC2 인스턴스에 연결할 때와 동일한 방식으로 클러스터 노드에 연결할 수 있습니다. Amazon EC2를 사용하여 키 페어를 생성하거나 키 페어를 가져올 수 있습니다. 클러스터 생성 시 모든 클러스터 인스턴스에 대한 SSH 연결에 사용할 Amazon EC2 키 페어를 지정할 수 있습니다. 키 페어 없이 클러스터를 생성할 수도 있습니다. 대개 이 작업은 시작한 후 단계를 실행하고, 이어서 자동으로 종료되는 임시 클러스터를 이용해 이루어집니다.
클러스터에 연결할 때 사용하는 SSH 클라이언트의 경우, 이 키 페어와 연결된 프라이빗 키 파일을 사용해야 합니다. 이 파일은 Linux, Unix 및 macOS를 사용하는 SSH 클라이언트를 위한 .pem 파일입니다. 키 소유자만 파일에 액세스할 수 있는 권한이 있도록 권한을 설정해야 합니다. 이것은 Windows를 사용하는 SSH 클라이언트에 대한 .ppk 파일이며, .ppk 파일은 보통 .pem 파일에서 생성됩니다.
+ Amazon EC2 키 페어 생성에 대한 자세한 내용은 **Amazon EC2 사용 설명서의 [Amazon EC2 키 페어](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)를 참조하세요.
+ PuTTYgen을 사용하여 .pem 파일에서 .ppk 파일을 생성하는 방법에 대한 지침은 **Amazon EC2 사용 설명서에서 [PuTTYgen을 사용하여 프라이빗 키 변환](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/putty.html#putty-private-key)을 참조하세요.
+ .pem 파일 권한 설정 및 Linux 또는 macOS, Windows`ssh`의 PuTTY 또는 지원되는 운영 체제의를 비롯한 다양한 방법을 사용하여 EMR 클러스터의 프라이머리 노드 AWS CLI 에 연결하는 방법에 대한 자세한 내용은 섹션을 참조하세요[SSH를 사용하여 Amazon EMR 클러스터 프라이머리 노드에 연결](emr-connect-master-node-ssh.md).
# Amazon EMR을 통한 인증에 Kerberos 사용
Amazon EMR 릴리스 5.10.0 이상에서는 Kerberos를 지원합니다. Kerberos는 네트워크에서 암호화되지 않은 형식으로 암호나 다른 보안 인증이 전송되지 않도록 비밀 키 암호화를 사용하여 강력한 인증을 제공하는 네트워크 인증 프로토콜입니다.
Kerberos에서는 인증이 필요한 서비스 및 사용자를 *보안 주체*라고 합니다. 보안 주체는 Kerberos *영역* 내에 존재합니다. 영역 내에서 *KDC(키 배포 센터)*라는 Kerberos 서버는 보안 주체가 인증을 수행할 수 있는 수단을 제공합니다. KDC는 보안 주체 인증을 위해 *티켓*을 발급합니다. KDC는 영역 내의 보안 주체, 그들의 암호 및 각 보안 주체에 대한 기타 관리자 정보가 저장된 데이터베이스를 유지합니다. 또한 KDC는 다른 영역의 보안 주체로부터 인증 자격 증명을 수락할 수 있는데, 이를 *교차 영역 신뢰*라고 합니다. 또한 EMR 클러스터는 외부 KDC를 사용하여 보안 주체를 인증할 수 있습니다.
교차 영역 신뢰를 구축하거나 외부 KDC를 사용하는 일반적인 시나리오는 Active Directory 도메인에서 사용자를 인증하는 것입니다. 이를 통해 사용자는 SSH를 사용하여 클러스터에 연결하거나 빅 데이터 애플리케이션으로 작업할 때 도메인 계정으로 EMR 클러스터에 액세스할 수 있습니다.
Kerberos 인증을 사용할 때 Amazon EMR은 상호 인증이 가능하도록 클러스터의 애플리케이션, 구성 요소 및 서브시스템에 대해 Kerberos를 구성합니다.
**중요**
Amazon EMR은 AWS Directory Service for Microsoft Active Directory 교차 영역 신뢰 또는 외부 KDC로를 지원하지 않습니다.
Amazon EMR을 사용해 Kerberos를 구성하기 앞서 Kerberos 개념과 KDC에서 실행되는 서비스 및 Kerberos 서비스를 관리하는 도구에 대해 숙지하는 것이 좋습니다. 자세한 내용은 [Kerberos 컨소시엄](http://kerberos.org/)에 게시된 [MIT Kerberos 설명서](http://web.mit.edu/kerberos/krb5-latest/doc/)를 참조하세요.
**Topics**
+ [Amazon EMR에서 지원되는 애플리케이션](emr-kerberos-principals.md)
+ [Amazon EMR에서 Kerberos 아키텍처 옵션](emr-kerberos-options.md)
+ [Amazon EMR에서 Kerberos 구성](emr-kerberos-configure.md)
+ [SSH를 사용하여 Amazon EMR에서 Kerberos 클러스터에 연결](emr-kerberos-connect-ssh.md)
+ [자습서: Amazon EMR을 사용하여 클러스터 전용 KDC 구성](emr-kerberos-cluster-kdc.md)
+ [자습서: Active Directory 도메인과 교차 영역 신뢰 구성](emr-kerberos-cross-realm.md)
# Amazon EMR에서 지원되는 애플리케이션
EMR 클러스터 내에서 Kerberos 보안 주체는 모든 클러스터 노드에서 실행되는 빅 데이터 애플리케이션 서비스 및 서브시스템입니다. Amazon EMR은 Kerberos를 사용하도록 아래 나열된 애플리케이션 및 구성 요소를 구성할 수 있습니다. 각 애플리케이션에 Kerberos 사용자 보안 주체가 연결이 됩니다.
Amazon EMR은 AWS Directory Service for Microsoft Active Directory를 사용하는 교차 영역 신뢰를 지원하지 않습니다.
Amazon EMR은 아래 나열된 애플리케이션 및 구성 요소에 대해 오픈 소스 Kerberos 인증 기능만 구성합니다. 설치된 다른 애플리케이션들은 Kerberos 인증을 사용하지 않기 때문에 Kerberos 인증을 사용하는 구성 요소와 통신을 할 수 없으며 애플리케이션 오류를 유발할 수 있습니다. Kerberos 인증을 사용하지 않는 애플리케이션 및 구성 요소는 인증을 활성화하지 않습니다. 지원되는 애플리케이션 및 구성 요소는 Amazon EMR 릴리스에 따라 다를 수 있습니다.
Livy 사용자 인터페이스는 클러스터에 호스팅되는 유일한 Kerberos 지원 웹 사용자 인터페이스입니다.
+ **Hadoop MapReduce**
+ **Hbase**
+ **HCatalog**
+ **HDFS**
+ **Hive**
+ LDAP 인증에서 Hive를 활성화하지 마세요. 활성화를 할 경우 Kerberos 인증을 사용하는 YARN과의 통신에 문제가 발생할 수 있기 때문입니다.
+ **Hue**
+ Hue 사용자 인증은 자동으로 설정되지 않으며 구성 API를 사용하여 구성할 수 있습니다.
+ Hue 서버는 Kerberos 인증을 사용합니다. Hue 프런트 엔드(UI)는 인증을 위해 구성되지 않습니다. LDAP 인증은 Hue UI에서 구성할 수 있습니다.
+ **Livy**
+ Kerberos 지원 클러스터를 사용한 Livy 위장 기능은 Amazon EMR 릴리스 5.22.0 이상에서 지원됩니다.
+ **Oozie**
+ **피닉스**
+ **Presto**
+ Presto는 Amazon EMR 릴리스 6.9.0 이상에서 Kerberos 인증을 지원합니다.
+ Presto에 Kerberos 인증을 사용하려면 [전송 중 암호화](emr-data-encryption-options.md#emr-encryption-intransit)를 활성화해야 합니다.
+ **Spark**
+ **Tez**
+ **Trino**
+ Trino는 Amazon EMR 릴리스 6.11.0 이상에서 Kerberos 인증을 지원합니다.
+ Trino에 Kerberos 인증을 사용하려면 [전송 중 암호화](emr-data-encryption-options.md#emr-encryption-intransit)를 활성화해야 합니다.
+ **YARN**
+ **Zeppelin**
+ Zeppelin은 오직 Spark 인터프리터에서만 Kerberos를 사용하도록 구성됩니다. 다른 인터프리터에 대해서는 구성되지 않습니다.
+ Spark 이외의 Kerberized Zeppelin 인터프리터에서는 사용자 위장이 지원되지 않습니다.
+ **Zookeeper**
+ Zookeeper 클라이언트는 지원되지 않습니다.
# Amazon EMR에서 Kerberos 아키텍처 옵션
Amazon EMR과 함께 Kerberos를 사용할 때 이 섹션에 나열된 아키텍처 중에서 선택할 수 있습니다. 선택하는 아키텍처에 관계없이 동일한 단계를 사용하여 Kerberos를 구성합니다. 보안 구성을 생성하고, 클러스터를 생성할 때 보안 구성 및 호환 가능한 클러스터별 Kerberos 옵션을 지정하며, KDC의 사용자 보안 주체와 일치하는 클러스터의 Linux 사용자를 위한 HDFS 디렉터리를 생성합니다. 각 아키텍처의 구성 옵션 및 예제 구성에 대한 설명은 [Amazon EMR에서 Kerberos 구성](emr-kerberos-configure.md) 섹션을 참조하세요.
## 클러스터 전용 KDC(프라이머리 노드의 KDC)
이 구성은 Amazon EMR 릴리스 5.10.0 이상에서 사용할 수 있습니다.
![\[Amazon EMR클러스터 architecture with master node, core nodes, and task node within a Kerberos realm.\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/images/kerb-cluster-dedicated-kdc.png)
**장점**
+ Amazon EMR은 KDC의 완전한 소유권을 가집니다.
+ EMR 클러스터의 KDC는 Microsoft Active Directory 또는 AWS Managed Microsoft AD와 같은 중앙 집중식 KDC 구현으로부터 독립적입니다.
+ KDC는 클러스터 내의 로컬 노드에 대해서만 인증을 관리하기 때문에 성능에 미치는 영향은 최소화됩니다.
+ 선택적으로 다른 Kerberos 인증을 사용하는 클러스터는 KDC를 외부 KDC로 참조할 수 있습니다. 자세한 내용은 [외부 KDC - 서로 다른 클러스터의 프라이머리 노드](#emr-kerberos-extkdc-cluster-summary) 단원을 참조하십시오.
**고려 사항 및 제한 사항**
+ Kerberos 인증을 사용하는 클러스터는 서로 인증할 수 없으므로 애플리케이션은 상호 작용할 수 없습니다. 클러스터 애플리케이션이 상호 작용해야 하는 경우 클러스터 간에 교차 영역 신뢰를 구축하거나 하나의 클러스터를 다른 클러스터의 외부 KDC로 구축해야 합니다. 교차 영역 신뢰가 구축된 경우 KDC에는 다른 Kerberos 영역이 있어야 합니다.
+ 각 사용자에 대한 HDFS 디렉터리와 함께 KDC 사용자 보안 주체에 해당하는 프라이머리 노드의 EC2 인스턴스에서 Linux 사용자를 생성해야 합니다.
+ 사용자 보안 주체는 EC2 프라이빗 키 파일 및 `kinit` 자격 증명을 사용하여 SSH를 사용하는 클러스터에 연결해야 합니다.
## 교차 영역 신뢰
교차 영역 신뢰에서 다른 Kerberos 영역의 보안 주체(주로 사용자들)는 자체 KDC를 소유한 Kerberos 기반 EMR 클러스터의 애플리케이션 구성 요소를 인증합니다. 프라이머리 노드의 KDC는 두 KDC에 모두 존재하는 *교차 영역 보안 주체*를 사용하여 다른 KDC와 신뢰 관계를 구축합니다. 보안 주체의 이름과 암호가 각 KDC에서 정확하게 일치합니다. 다음 다이어그램과 같이 교차 영역 신뢰는 Active Directory 구현에 가장 일반적입니다. 외부 MIT KDC 또는 다른 Amazon EMR 클러스터의 KDC에 대한 교차 영역 신뢰도 지원됩니다.
![\[Amazon EMR clusters in different Kerberos realms with cross-realm trust to Active Directory.\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/images/kerb-cross-realm-trust.png)
**장점**
+ KDC가 설치된 EMR 클러스터는 KDC의 완전한 소유권을 유지합니다.
+ Active Directory를 통해 Amazon EMR은 KDC의 사용자 보안 주체에 해당하는 Linux 사용자를 자동으로 생성합니다. 각 사용자에 대해 HDFS 디렉터리를 여전히 생성해야 합니다. 또한 Active Directory 도메인의 사용자 보안 주체는 EC2 프라이빗 키 파일 없이 `kinit` 자격 증명을 사용하여 Kerberos 인증을 사용하는 클러스터에 액세스할 수 있습니다. 따라서 클러스터 사용자 간에 프라이빗 키 파일을 공유할 필요가 없습니다.
+ 각 클러스터 KDC는 클러스터의 노드에 대한 인증을 관리하기 때문에 클러스터 전반에서 많은 수의 노드에 대한 네트워크 지연 시간 및 처리 오버헤드의 영향이 최소화됩니다.
**고려 사항 및 제한 사항**
+ Active Directory 영역을 통해 신뢰를 구축하는 경우 클러스터를 생성할 때 도메인에 보안 주체를 조인할 수 있는 권한이 있는 Active Directory 사용자 이름과 암호를 제공해야 합니다.
+ 동일한 이름의 Kerberos 영역 간에는 교차 영역 신뢰를 구축할 수 없습니다.
+ 교차 영역 신뢰는 명시적으로 구축되어야 합니다. 예를 들어, 클러스터 A와 클러스터 B가 모두 KDC와의 교차 영역 신뢰를 구축하는 경우 본질적으로는 서로를 신뢰하지 않으며 각자의 애플리케이션이 서로 인증하여 상호 작용할 수 없습니다.
+ 사용자 보안 주체의 자격 증명이 정확하게 일치하도록 KDC를 독립적으로 유지 관리하고 조정해야 합니다.
## 외부 KDC
외부 KDC가 있는 구성은 Amazon EMR 5.20.0 이상에서 지원됩니다.
+ [외부 KDC - MIT KDC](#emr-kerberos-extkdc-mit-summary)
+ [외부 KDC - 서로 다른 클러스터의 프라이머리 노드](#emr-kerberos-extkdc-cluster-summary)
+ [외부 KDC 클러스터 - Active Directory 교차 영역 신뢰가 있는 다른 클러스터의 KDC](#emr-kerberos-extkdc-ad-trust-summary)
### 외부 KDC - MIT KDC
이 구성은 하나 이상의 EMR 클러스터가 MIT KDC 서버에서 정의되고 유지 관리되는 보안 주체를 사용할 수 있도록 허용합니다.
![\[Amazon EMR클러스터 architecture with Kerberos realm, showing master, core, and task nodes.\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/images/kerb-external-kdc.png)
**장점**
+ 보안 주체 관리는 단일 KDC로 통합됩니다.
+ 여러 클러스터가 동일한 Kerberos 영역에서 동일한 KDC를 사용할 수 있습니다. 자세한 내용은 [동일한 KDC에서 여러 클러스터를 사용하기 위한 요구 사항](#emr-kerberos-multi-kdc) 단원을 참조하십시오.
+ Kerberos 인증을 사용하는 클러스터의 프라이머리 노드에는 KDC 유지 관리와 관련된 성능 부담이 없습니다.
**고려 사항 및 제한 사항**
+ 각 사용자에 대한 HDFS 디렉터리와 함께 KDC 사용자 보안 주체에 해당하는 Kerberos 인증을 사용하는 클러스터 프라이머리 노드의 EC2 인스턴스에서 Linux 사용자를 생성해야 합니다.
+ 사용자 보안 주체는 EC2 프라이빗 키 파일 및 `kinit` 자격 증명을 사용하여 SSH를 사용하는 Kerberos 인증을 사용하는 클러스터에 연결해야 합니다.
+ Kerberos 기반 EMR 클러스터의 각 노드에는 KDC에 대한 네트워크 경로가 있어야 합니다.
+ Kerberos 인증을 사용하는 클러스터의 각 노드는 외부 KDC에게 인증에 대한 책임을 부여하므로 KDC 구성은 클러스터 성능에 영향을 미칩니다. KDC 서버의 하드웨어를 구성할 때 동시에 지원할 최대 Amazon EMR 노드 수를 고려합니다.
+ 클러스터 성능은 Kerberos 클러스터의 노드와 KDC 간의 네트워크 지연 시간에 따라 다릅니다.
+ 상호 의존성으로 인해 문제 해결이 더 어려울 수 있습니다.
### 외부 KDC - 서로 다른 클러스터의 프라이머리 노드
이 구성은 KDC가 EMR 클러스터의 프라이머리 노드에 있다는 점을 제외하고는 위의 외부 MIT KDC 구현과 거의 동일합니다. 자세한 내용은 [클러스터 전용 KDC(프라이머리 노드의 KDC)](#emr-kerberos-localkdc-summary) 및 [자습서: Active Directory 도메인과 교차 영역 신뢰 구성](emr-kerberos-cross-realm.md) 섹션을 참조하세요.
![\[Diagram of Amazon EMR clusters with Kerberos realm, showing master and core nodes.\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/images/kerb-external-cluster-kdc.png)
**장점**
+ 보안 주체 관리는 단일 KDC로 통합됩니다.
+ 여러 클러스터가 동일한 Kerberos 영역에서 동일한 KDC를 사용할 수 있습니다. 자세한 내용은 [동일한 KDC에서 여러 클러스터를 사용하기 위한 요구 사항](#emr-kerberos-multi-kdc) 단원을 참조하십시오.
**고려 사항 및 제한 사항**
+ 각 사용자에 대한 HDFS 디렉터리와 함께 KDC 사용자 보안 주체에 해당하는 Kerberos 인증을 사용하는 클러스터 프라이머리 노드의 EC2 인스턴스에서 Linux 사용자를 생성해야 합니다.
+ 사용자 보안 주체는 EC2 프라이빗 키 파일 및 `kinit` 자격 증명을 사용하여 SSH를 사용하는 Kerberos 인증을 사용하는 클러스터에 연결해야 합니다.
+ 각 EMR 클러스터의 각 노드에는 KDC에 대한 네트워크 경로가 있어야 합니다.
+ Kerberos 인증을 사용하는 클러스터의 각 Amazon EMR 노드는 외부 KDC에게 인증에 대한 책임을 부여하므로 KDC 구성은 클러스터 성능에 영향을 미칩니다. KDC 서버의 하드웨어를 구성할 때 동시에 지원할 최대 Amazon EMR 노드 수를 고려합니다.
+ 클러스터 성능은 클러스터의 노드와 KDC 간의 네트워크 지연 시간에 따라 다릅니다.
+ 상호 의존성으로 인해 문제 해결이 더 어려울 수 있습니다.
### 외부 KDC 클러스터 - Active Directory 교차 영역 신뢰가 있는 다른 클러스터의 KDC
이 구성에서는 먼저 Active Directory와의 단방향 교차 영역 신뢰가 있는 클러스터 전용 KDC를 통해 클러스터를 생성합니다. 자세한 자습서는 [자습서: Active Directory 도메인과 교차 영역 신뢰 구성](emr-kerberos-cross-realm.md)를 참조하세요. 그런 다음 추가 클러스터를 시작하고 외부 KDC의 신뢰를 가진 클러스터 KDC를 참조합니다. 예제는 [Active Directory 교차 영역 신뢰가 있는 외부 클러스터 KDC](emr-kerberos-config-examples.md#emr-kerberos-example-extkdc-ad-trust) 섹션을 참조하세요. 이를 통해 외부 KDC를 사용하는 각 Amazon EMR 클러스터가 Microsoft Active Directory 도메인에서 정의되고 유지 관리되는 보안 주체를 인증할 수 있습니다.
![\[Amazon EMR clusters with Kerberos authentication and Active Directory integration diagram.\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/images/kerb-external-ad-trust-kdc.png)
**장점**
+ 보안 주체 관리는 Active Directory 도메인에 통합됩니다.
+ Amazon EMR은 Active Directory 영역에 조인하므로 Active Directory 사용자에 해당하는 Linux 사용자를 생성할 필요가 없습니다. 각 사용자에 대해 HDFS 디렉터리를 여전히 생성해야 합니다.
+ 여러 클러스터가 동일한 Kerberos 영역에서 동일한 KDC를 사용할 수 있습니다. 자세한 내용은 [동일한 KDC에서 여러 클러스터를 사용하기 위한 요구 사항](#emr-kerberos-multi-kdc) 단원을 참조하십시오.
+ Active Directory 도메인의 사용자 보안 주체는 EC2 프라이빗 키 파일 없이 `kinit` 자격 증명을 사용하여 Kerberos 인증을 사용하는 클러스터에 액세스할 수 있습니다. 따라서 클러스터 사용자 간에 프라이빗 키 파일을 공유할 필요가 없습니다.
+ 하나의 Amazon EMR 프라이머리 노드만 KDC를 유지 관리할 책임이 있으므로 KDC와 Active Directory 간의 교차 영역 신뢰에 대한 Active Directory 보안 인증을 통해 해당 클러스터만 생성해야 합니다.
**고려 사항 및 제한 사항**
+ 각 EMR 클러스터의 각 노드에는 KDC 및 Active Directory 도메인 컨트롤러에 대한 네트워크 경로가 있어야 합니다.
+ 각 Amazon EMR 노드는 외부 KDC에게 인증에 대한 책임을 부여하므로 KDC 구성은 클러스터 성능에 영향을 미칩니다. KDC 서버의 하드웨어를 구성할 때 동시에 지원할 최대 Amazon EMR 노드 수를 고려합니다.
+ 클러스터 성능은 클러스터의 노드와 KDC 서버 간의 네트워크 지연 시간에 따라 다릅니다.
+ 상호 의존성으로 인해 문제 해결이 더 어려울 수 있습니다.
## 동일한 KDC에서 여러 클러스터를 사용하기 위한 요구 사항
여러 클러스터가 동일한 Kerberos 영역에서 동일한 KDC를 사용할 수 있습니다. 그러나 클러스터가 동시에 실행되는 경우 충돌하는 Kerberos ServicePrincipal 이름을 사용하면 클러스터가 실패할 수 있습니다.
동일한 외부 KDC를 사용하는 동시 클러스터가 여러 개 있는 경우 클러스터가 서로 다른 Kerberos 영역을 사용하는지 확인합니다. 클러스터가 동일한 Kerberos 영역을 사용해야 하는 경우 클러스터가 서로 다른 서브넷에 있고 CIDR 범위가 겹치지 않는지 확인합니다.
# Amazon EMR에서 Kerberos 구성
이 섹션에서는 일반적인 아키텍처로 Kerberos를 설정하기 위한 구성 세부 정보와 예제를 제공합니다. 선택하는 아키텍처에 관계없이 구성 기본 사항은 동일하며 3단계로 수행됩니다. 외부 KDC를 사용하거나 교차 영역 신뢰를 설정하는 경우 인바운드 및 아웃바운드 Kerberos 트래픽을 허용하는 관련 보안 그룹의 구성을 포함하여 클러스터의 모든 노드에 외부 KDC에 대한 네트워크 경로가 있는지 확인해야 합니다.
## 1단계: Kerberos 속성을 통한 보안 구성 생성
보안 구성에서는 Kerberos KDC에 대한 세부 정보를 지정하며, 클러스터를 생성할 때마다 Kerberos 구성을 다시 사용하도록 허용합니다. Amazon EMR 콘솔 AWS CLI, 또는 EMR API를 사용하여 보안 구성을 생성할 수 있습니다. 보안 구성에는 암호화 같은 기타 보안 옵션들도 포함될 수 있습니다. 클러스터를 생성할 때 보안 구성을 생성하고 지정하는 방법에 대한 자세한 내용은 [보안 구성을 사용하여 Amazon EMR 클러스터 보안 설정](emr-security-configurations.md) 섹션을 참조하세요. 보안 구성의 Kerberos 속성에 대한 자세한 내용은 [보안 구성에 대한 Kerberos 설정](emr-kerberos-configure-settings.md#emr-kerberos-security-configuration) 섹션을 참조하세요.
## 2단계: 클러스터 생성 및 클러스터별 Kerberos 속성 지정
클러스터를 생성할 때 클러스터별 Kerberos 옵션과 함께 Kerberos 보안 구성을 지정합니다. Amazon EMR 콘솔을 사용할 때 지정된 보안 구성과 호환되는 Kerberos 옵션만 사용할 수 있습니다. AWS CLI 또는 Amazon EMR API를 사용하는 경우 지정된 보안 구성과 호환되는 Kerberos 옵션을 지정해야 합니다. 예를 들어, CLI를 사용하여 클러스터를 생성할 때 교차 영역 신뢰에 대한 보안 주체 암호를 지정하고 지정된 보안 구성이 교차 영역 신뢰 파라미터로 구성되지 않은 경우, 오류가 발생합니다. 자세한 내용은 [클러스터에 대한 Kerberos 설정](emr-kerberos-configure-settings.md#emr-kerberos-cluster-configuration) 단원을 참조하십시오.
## 3단계: 클러스터 프라이머리 노드 구성
아키텍처 및 구현 요구 사항에 따라 클러스터에 추가적인 설정이 필요할 수 있습니다. 생성 후 또는 생성 프로세스 중에 단계 또는 부트스트랩 작업을 통해 설정할 수 있습니다.
SSH를 사용하여 클러스터에 연결하는 각 Kerberos 인증 사용자의 경우 해당 Kerberos 사용자에 해당하는 Linux 계정이 생성되어 있는지 확인해야 합니다. 사용자 보안 주체가 외부 KDC 또는 교차 영역 신뢰를 통해 Active Directory 도메인 컨트롤러에서 제공되면 Amazon EMR은 Linux 계정을 자동으로 생성합니다. Active Directory를 사용하지 않는 경우 Linux 사용자에 해당하는 각 사용자의 보안 주체를 생성해야 합니다. 자세한 내용은 [Kerberos 인증 HDFS 사용자 및 SSH 연결을 위한 Amazon EMR 클러스터 구성](emr-kerberos-configuration-users.md) 단원을 참조하십시오.
또한 각 사용자에게는 자체적으로 소유한 HDFS 사용자 디렉터리가 있어야 합니다. 또한 Kerberos 인증 사용자의 연결을 허용하려면 GSSAPI를 통해 SSH를 구성해야 합니다. GSSAPI는 프라이머리 노드에서 활성화되어야 하며 클라이언트 SSH 애플리케이션은 GSSAPI를 사용하도록 구성되어야 합니다. 자세한 내용은 [Kerberos 인증 HDFS 사용자 및 SSH 연결을 위한 Amazon EMR 클러스터 구성](emr-kerberos-configuration-users.md) 단원을 참조하십시오.
# Amazon EMR에서 Kerberos 보안 구성 및 클러스터 설정
Kerberos 인증을 사용하는 클러스터를 생성할 때 클러스터 고유의 Kerberos 속성과 함께 보안 구성을 지정합니다. 반드시 둘을 함께 구성해야 하며, 그렇지 않을 경우 오류가 발생합니다.
이 주제에서는 보안 구성 및 클러스터를 생성할 때 Kerberos에 사용할 수 있는 구성 파라미터의 개요를 제공합니다. 또한 범용 아키텍처에 호환 가능한 보안 구성 및 클러스터를 생성하기 위한 CLI 예제가 제공됩니다.
## 보안 구성에 대한 Kerberos 설정
Amazon EMR 콘솔 AWS CLI, 또는 EMR API를 사용하여 Kerberos 속성을 지정하는 보안 구성을 생성할 수 있습니다. 보안 구성에는 암호화 같은 기타 보안 옵션들도 포함될 수 있습니다. 자세한 내용은 [Amazon EMR 콘솔 또는를 사용하여 보안 구성 생성 AWS CLI](emr-create-security-configuration.md) 단원을 참조하십시오.
다음 참조를 사용하여 선택하는 Kerberos 아키텍처의 사용 가능한 보안 구성 설정을 파악합니다. Amazon EMR 콘솔 설정이 표시됩니다. 해당되는 CLI 옵션은 [를 사용하여 Kerberos 설정 지정 AWS CLI](emr-create-security-configuration.md#emr-kerberos-cli-parameters) 또는 [구성 예제](emr-kerberos-config-examples.md) 섹션을 참조하세요.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/emr-kerberos-configure-settings.html)
## 클러스터에 대한 Kerberos 설정
Amazon EMR 콘솔 AWS CLI, 또는 EMR API를 사용하여 클러스터를 생성할 때 Kerberos 설정을 지정할 수 있습니다.
다음 참조를 사용하여 선택하는 Kerberos 아키텍처의 사용 가능한 클러스터 구성 설정을 파악합니다. Amazon EMR 콘솔 설정이 표시됩니다. 해당되는 CLI 옵션은 [구성 예제](emr-kerberos-config-examples.md) 섹션을 참조하세요.
| 파라미터 | 설명 |
| --- | --- |
| Realm | 클러스터의 Kerberos 영역 이름. Kerberos 명명 규칙에 따르면 이 이름은 도메인 이름과 동일하되, 대문자로 설정됩니다. 예를 들어, 도메인 `ec2.internal`에서는 영역 이름으로 `EC2.INTERNAL`을 사용합니다. |
| KDC 관리자 암호 | `kadmin` 또는 `kadmin.local`에서 클러스터 내에서 사용되는 암호. 이들은 Kerberos 보안 주체, 암호 정책 및 클러스터의 키 탭이 포함된 Kerberos V5 관리 시스템에 대한 명령줄 인터페이스입니다. |
| 교차 영역 신뢰 보안 주체 암호(옵션) | 교차 영역 신뢰를 구축할 때 필요합니다. 교차 영역 보안 주체 암호는 영역 전반에서 동일해야 합니다. 강력한 암호를 사용하세요. |
| Active Directory 도메인 조인 사용자(선택 사항) | 교차 영역 신뢰에서 Active Directory를 사용할 때 필요합니다. 컴퓨터를 도메인에 조인할 수 있는 권한을 가진 Active Directory 계정의 사용자 로그인 이름입니다. Amazon EMR은 이 ID를 사용하여 클러스터를 도메인에 조인합니다. 자세한 내용은 [3단계: EMR 클러스터에서 도메인에 사용자 계정 추가](emr-kerberos-cross-realm.md#emr-kerberos-ad-users) 단원을 참조하십시오. |
| Active Directory 도메인 조인 암호(선택 사항) | Active Directory 도메인 조인 사용자용 암호입니다. 자세한 내용은 [3단계: EMR 클러스터에서 도메인에 사용자 계정 추가](emr-kerberos-cross-realm.md#emr-kerberos-ad-users) 단원을 참조하십시오. |
# 구성 예제
다음 예제에서는 일반적인 scenarios. AWS CLI commands에 대한 보안 구성 및 클러스터 구성을 간결하게 보여줍니다.
## 로컬 KDC
다음 명령은 프라이머리 노드에서 실행 중인 클러스터 전용 KDC를 통해 클러스터를 생성합니다. 클러스터의 추가 구성이 필요합니다. 자세한 내용은 [Kerberos 인증 HDFS 사용자 및 SSH 연결을 위한 Amazon EMR 클러스터 구성](emr-kerberos-configuration-users.md) 단원을 참조하십시오.
**보안 구성 생성**
```
aws emr create-security-configuration --name LocalKDCSecurityConfig \
--security-configuration '{"AuthenticationConfiguration": \
{"KerberosConfiguration": {"Provider": "ClusterDedicatedKdc",\
"ClusterDedicatedKdcConfiguration": {"TicketLifetimeInHours": 24 }}}}'
```
**클러스터 생성**
```
aws emr create-cluster --release-label emr-7.12.0 \
--instance-count 3 --instance-type m5.xlarge \
--applications Name=Hadoop Name=Hive --ec2-attributes InstanceProfile=EMR_EC2_DefaultRole,KeyName=MyEC2Key \
--service-role EMR_DefaultRole \
--security-configuration LocalKDCSecurityConfig \
--kerberos-attributes Realm=EC2.INTERNAL,KdcAdminPassword=MyPassword
```
## Active Directory 교차 영역 신뢰가 있는 클러스터 전용 KDC
다음 명령은 Active Directory 도메인에 대한 교차 영역 신뢰를 포함한 프라이머리 노드에서 실행 중인 클러스터 전용 KDC를 통해 클러스터를 생성합니다. 클러스터 및 Active Directory의 추가 구성이 필요합니다. 자세한 내용은 [자습서: Active Directory 도메인과 교차 영역 신뢰 구성](emr-kerberos-cross-realm.md) 단원을 참조하십시오.
**보안 구성 생성**
```
aws emr create-security-configuration --name LocalKDCWithADTrustSecurityConfig \
--security-configuration '{"AuthenticationConfiguration": \
{"KerberosConfiguration": {"Provider": "ClusterDedicatedKdc", \
"ClusterDedicatedKdcConfiguration": {"TicketLifetimeInHours": 24, \
"CrossRealmTrustConfiguration": {"Realm":"AD.DOMAIN.COM", \
"Domain":"ad.domain.com", "AdminServer":"ad.domain.com", \
"KdcServer":"ad.domain.com"}}}}}'
```
**클러스터 생성**
```
aws emr create-cluster --release-label emr-7.12.0 \
--instance-count 3 --instance-type m5.xlarge --applications Name=Hadoop Name=Hive \
--ec2-attributes InstanceProfile=EMR_EC2_DefaultRole,KeyName=MyEC2Key \
--service-role EMR_DefaultRole --security-configuration KDCWithADTrustSecurityConfig \
--kerberos-attributes Realm=EC2.INTERNAL,KdcAdminPassword=MyClusterKDCAdminPassword,\
ADDomainJoinUser=ADUserLogonName,ADDomainJoinPassword=ADUserPassword,\
CrossRealmTrustPrincipalPassword=MatchADTrustPassword
```
## 다른 클러스터의 외부 KDC
다음 명령은 다른 클러스터의 프라이머리 노드에 있는 클러스터 전용 KDC를 참조하여 보안 주체를 인증하는 클러스터를 생성합니다. 클러스터의 추가 구성이 필요합니다. 자세한 내용은 [Kerberos 인증 HDFS 사용자 및 SSH 연결을 위한 Amazon EMR 클러스터 구성](emr-kerberos-configuration-users.md) 단원을 참조하십시오.
**보안 구성 생성**
```
aws emr create-security-configuration --name ExtKDCOnDifferentCluster \
--security-configuration '{"AuthenticationConfiguration": \
{"KerberosConfiguration": {"Provider": "ExternalKdc", \
"ExternalKdcConfiguration": {"KdcServerType": "Single", \
"AdminServer": "MasterDNSOfKDCMaster:749", \
"KdcServer": "MasterDNSOfKDCMaster:88"}}}}'
```
**클러스터 생성**
```
aws emr create-cluster --release-label emr-7.12.0 \
--instance-count 3 --instance-type m5.xlarge \
--applications Name=Hadoop Name=Hive \
--ec2-attributes InstanceProfile=EMR_EC2_DefaultRole,KeyName=MyEC2Key \
--service-role EMR_DefaultRole --security-configuration ExtKDCOnDifferentCluster \
--kerberos-attributes Realm=EC2.INTERNAL,KdcAdminPassword=KDCOnMasterPassword
```
## Active Directory 교차 영역 신뢰가 있는 외부 클러스터 KDC
다음 명령은 KDC가 없는 클러스터를 생성합니다. 해당 클러스터는 다른 클러스터의 프라이머리 노드에서 실행 중인 클러스터 전용 KDC를 참조하여 보안 주체를 인증합니다. 해당 KDC에는 Active Directory 도메인 컨트롤러와의 교차 영역 신뢰가 있습니다. KDC가 있는 프라이머리 노드에 추가 구성이 필요합니다. 자세한 내용은 [자습서: Active Directory 도메인과 교차 영역 신뢰 구성](emr-kerberos-cross-realm.md) 단원을 참조하십시오.
**보안 구성 생성**
```
aws emr create-security-configuration --name ExtKDCWithADIntegration \
--security-configuration '{"AuthenticationConfiguration": \
{"KerberosConfiguration": {"Provider": "ExternalKdc", \
"ExternalKdcConfiguration": {"KdcServerType": "Single", \
"AdminServer": "MasterDNSofClusterKDC:749", \
"KdcServer": "MasterDNSofClusterKDC.com:88", \
"AdIntegrationConfiguration": {"AdRealm":"AD.DOMAIN.COM", \
"AdDomain":"ad.domain.com", \
"AdServer":"ad.domain.com"}}}}}'
```
**클러스터 생성**
```
aws emr create-cluster --release-label emr-7.12.0 \
--instance-count 3 --instance-type m5.xlarge --applications Name=Hadoop Name=Hive \
--ec2-attributes InstanceProfile=EMR_EC2_DefaultRole,KeyName=MyEC2Key \
--service-role EMR_DefaultRole --security-configuration ExtKDCWithADIntegration \
--kerberos-attributes Realm=EC2.INTERNAL,KdcAdminPassword=KDCOnMasterPassword,\
ADDomainJoinUser=MyPrivilegedADUserName,ADDomainJoinPassword=PasswordForADDomainJoinUser
```
# Kerberos 인증 HDFS 사용자 및 SSH 연결을 위한 Amazon EMR 클러스터 구성
Amazon EMR은 클러스터에서 실행되는 애플리케이션에 대해 Kerberos 인증 클라이언트를 생성합니다(예: `hadoop` 사용자, `spark` 사용자 등). Kerberos를 사용하여 클러스터 프로세스에 대해 인증을 받은 사용자를 추가할 수도 있습니다. 인증된 사용자는 Kerberos 자격 증명을 사용하여 클러스터를 연결한 다음 애플리케이션으로 작업할 수 있습니다. 사용자가 클러스터에 대해 인증하려면 다음 구성이 필요합니다.
+ KDC의 Kerberos 보안 주체와 일치하는 Linux 계정이 클러스터에 있어야 합니다. Amazon EMR은 Active Directory와 통합되는 아키텍처에서 이 작업을 자동으로 수행합니다.
+ 각 사용자에 대해 프라이머리 노드에 HDFS 사용자 디렉터리를 생성하고 사용자에게 디렉터리에 대한 권한을 부여해야 합니다.
+ 프라이머리 노드에서 GSSAPI가 활성화되도록 SSH 서비스를 구성해야 합니다. 또한 사용자에게 GSSAPI가 활성화된 SSH 클라이언트가 있어야 합니다.
## 프라이머리 노드에 Linux 사용자 및 Kerberos 보안 주체 추가
Active Directory를 사용하지 않는 경우 클러스터 프라이머리 노드에서 Linux 계정을 만들고 이러한 Linux 사용자의 보안 주체를 KDC에 추가해야 합니다. 여기에는 프라이머리 노드의 KDC에 보안 주체가 포함되어 있습니다. 사용자 보안 주체 외에도 프라이머리 노드에서 실행 중인 KDC에는 로컬 호스트에 대한 보안 주체가 있어야 합니다.
아키텍처에 Active Directory 통합이 포함되어 있으면 로컬 KDC의 Linux 사용자 및 보안 주체(해당되는 경우)가 자동으로 생성됩니다. 이 단계를 건너뛸 수 있습니다. 자세한 내용은 [교차 영역 신뢰](emr-kerberos-options.md#emr-kerberos-crossrealm-summary) 및 [외부 KDC 클러스터 - Active Directory 교차 영역 신뢰가 있는 다른 클러스터의 KDC](emr-kerberos-options.md#emr-kerberos-extkdc-ad-trust-summary) 섹션을 참조하세요.
**중요**
KDC는 프라이머리 노드가 종료되면 보안 주체 데이터베이스와 함께 손실되는데, 이는 프라이머리 노드에서 휘발성 스토리지를 사용하기 때문입니다. SSH 연결을 위해 사용자를 생성하는 경우 고가용성을 위해 구성된 외부 KDC로 교차 영역 신뢰를 구축하는 것이 좋습니다. 또는 SSH 연결을 위해 Linux 계정을 사용하여 사용자를 생성하는 경우 부트스트랩 작업 및 스크립트를 사용하여 계정 생성 과정을 자동화함으로써 새 클러스터 생성 시 이 과정이 반복될 수 있게 합니다.
클러스터를 생성한 후 또는 클러스터를 생성할 때 클러스터에 대한 단계를 제출하는 것이 사용자와 KDC 보안 주체를 추가할 수 있는 가장 쉬운 방법입니다. 또는 기본 `hadoop` 사용자로 EC2 키 페어를 사용하여 프라이머리 노드를 연결하고 명령을 실행할 수 있습니다. 자세한 내용은 [SSH를 사용하여 Amazon EMR 클러스터 프라이머리 노드에 연결](emr-connect-master-node-ssh.md) 단원을 참조하십시오.
다음 예제는 이미 존재하는 클러스터에 bash 스크립트 `configureCluster.sh`를 제출하여 클러스터 ID를 참조합니다. 스크립트는 Amazon S3에 저장됩니다.
```
aws emr add-steps --cluster-id \
--steps Type=CUSTOM_JAR,Name=CustomJAR,ActionOnFailure=CONTINUE,\
Jar=s3://region.elasticmapreduce/libs/script-runner/script-runner.jar,\
Args=["s3://amzn-s3-demo-bucket/configureCluster.sh"]
```
다음 예제는 `configureCluster.sh` 스크립트의 내용을 보여줍니다. 또한 이 스크립트는 다음 섹션에서 설명하는 HDFS 사용자 디렉터리 생성 및 SSH용 GSSAPI 활성화를 처리합니다.
```
#!/bin/bash
#Add a principal to the KDC for the primary node, using the primary node's returned host name
sudo kadmin.local -q "ktadd -k /etc/krb5.keytab host/`hostname -f`"
#Declare an associative array of user names and passwords to add
declare -A arr
arr=([lijuan]=pwd1 [marymajor]=pwd2 [richardroe]=pwd3)
for i in ${!arr[@]}; do
#Assign plain language variables for clarity
name=${i}
password=${arr[${i}]}
# Create a principal for each user in the primary node and require a new password on first logon
sudo kadmin.local -q "addprinc -pw $password +needchange $name"
#Add hdfs directory for each user
hdfs dfs -mkdir /user/$name
#Change owner of each user's hdfs directory to that user
hdfs dfs -chown $name:$name /user/$name
done
# Enable GSSAPI authentication for SSH and restart SSH service
sudo sed -i 's/^.*GSSAPIAuthentication.*$/GSSAPIAuthentication yes/' /etc/ssh/sshd_config
sudo sed -i 's/^.*GSSAPICleanupCredentials.*$/GSSAPICleanupCredentials yes/' /etc/ssh/sshd_config
sudo systemctl restart sshd
```
## 사용자 HDFS 디렉터리 추가
사용자가 클러스터에 로그인하여 Hadoop 작업을 실행할 수 있도록 하려면 Linux 계정에서 HDFS 사용자 디렉터리를 추가하고 각 사용자에게 디렉터리에 대한 소유권을 부여해야 합니다.
클러스터를 생성한 후 또는 클러스터를 생성할 때 클러스터에 대한 단계를 제출하는 것이 HDFS 디렉터리를 생성할 수 있는 가장 쉬운 방법입니다. 또는 기본 `hadoop` 사용자로 EC2 키 페어를 사용하여 프라이머리 노드를 연결하고 명령을 실행할 수 있습니다. 자세한 내용은 [SSH를 사용하여 Amazon EMR 클러스터 프라이머리 노드에 연결](emr-connect-master-node-ssh.md) 단원을 참조하십시오.
다음 예제는 이미 존재하는 클러스터에 bash 스크립트 `AddHDFSUsers.sh`를 제출하여 클러스터 ID를 참조합니다. 스크립트는 Amazon S3에 저장됩니다.
```
aws emr add-steps --cluster-id \
--steps Type=CUSTOM_JAR,Name=CustomJAR,ActionOnFailure=CONTINUE,\
Jar=s3://region.elasticmapreduce/libs/script-runner/script-runner.jar,Args=["s3://amzn-s3-demo-bucket/AddHDFSUsers.sh"]
```
다음 예제는 `AddHDFSUsers.sh` 스크립트의 내용을 보여줍니다.
```
#!/bin/bash
# AddHDFSUsers.sh script
# Initialize an array of user names from AD, or Linux users created manually on the cluster
ADUSERS=("lijuan" "marymajor" "richardroe" "myusername")
# For each user listed, create an HDFS user directory
# and change ownership to the user
for username in ${ADUSERS[@]}; do
hdfs dfs -mkdir /user/$username
hdfs dfs -chown $username:$username /user/$username
done
```
## SSH용 GSSAPI 활성화
Kerberos 인증 사용자가 SSH를 사용하여 프라이머리 노드에 연결하려면 SSH 서비스에 활성화된 GSSAPI 인증이 있어야 합니다. GSSAPI를 활성화하려면 프라이머리 노드 명령줄에서 다음 명령을 실행하거나 단계를 사용하여 스크립트로 실행합니다. SSH를 재구성한 후에는 서비스를 다시 시작해야 합니다.
```
sudo sed -i 's/^.*GSSAPIAuthentication.*$/GSSAPIAuthentication yes/' /etc/ssh/sshd_config
sudo sed -i 's/^.*GSSAPICleanupCredentials.*$/GSSAPICleanupCredentials yes/' /etc/ssh/sshd_config
sudo systemctl restart sshd
```
# SSH를 사용하여 Amazon EMR에서 Kerberos 클러스터에 연결
이 섹션에서는 Kerberos 인증 사용자가 EMR 클러스터의 프라이머리 노드에 연결하는 단계를 보여줍니다.
SSH 연결에 사용되는 각 컴퓨터에는 SSH 클라이언트 및 Kerberos 클라이언트 애플리케이션이 설치되어 있어야 합니다. Linux 컴퓨터에는 기본적으로 포함되어 있을 가능성이 높습니다. 예를 들어, OpenSSH는 대부분의 Linux, Unix 및 macOS 운영 체제에 설치되어 있습니다. 명령줄에 **ssh**를 입력하여 SSH 클라이언트가 있는지 확인할 수 있습니다. 컴퓨터가 명령을 인식하지 못하는 경우 SSH 클라이언트를 설치하여 프라이머리 노드에 연결합니다. OpenSSH 프로젝트는 전체 SSH 도구 스위트의 무료 구현을 제공합니다. 자세한 내용은 [OpenSSH](http://www.openssh.org/) 웹 사이트를 참조하세요. Windows 사용자는 [PuTTY](http://www.chiark.greenend.org.uk/~sgtatham/putty/)와 같은 SSH 애플리케이션을 사용할 수 있습니다.
SSH 연결에 대한 자세한 내용은 [Amazon EMR 클러스터에 연결하기](emr-connect-master-node.md) 섹션을 참조하세요.
SSH는 Kerberos 클라이언트 인증에 GSSAPI를 사용하며, 클러스터 프라이머리 노드에서 SSH 서비스에 대해 GSSAPI 인증을 활성화해야 합니다. 자세한 내용은 [SSH용 GSSAPI 활성화](emr-kerberos-configuration-users.md#emr-kerberos-ssh-config) 단원을 참조하십시오. 또한 SSH 클라이언트는 GSSAPI도 사용해야 합니다.
다음 예제에서 *MasterPublicDNS*에는 클러스터 세부 정보 창에서 **요약** 탭의 **마스터 퍼블릭 DNS**에 나타나는 값을 사용합니다(예: *ec2-11-222-33-44.compute-1.amazonaws.com*).
## krb5.conf의 필수 조건(Active Directory 외)
Active Directory 통합 없이 구성을 사용할 때 SSH 클라이언트 및 Kerberos 클라이언트 애플리케이션 외에도 각 클라이언트 컴퓨터에는 클러스터 프라이머리 노드의 `/etc/krb5.conf` 파일과 일치하는 `/etc/krb5.conf` 파일의 복사본이 있어야 합니다.
**krb5.conf 파일을 복사하려면**
1. SSH를 사용하여 EC2 키 페어와 기본 `hadoop` 사용자(예:`hadoop@MasterPublicDNS`)를 사용하여 프라이머리 노드에 연결합니다. 자세한 지침은 [Amazon EMR 클러스터에 연결하기](emr-connect-master-node.md) 섹션을 참조하세요.
1. 프라이머리 노드에서 `/etc/krb5.conf` 파일의 콘텐츠를 복사합니다. 자세한 내용은 [Amazon EMR 클러스터에 연결하기](emr-connect-master-node.md) 단원을 참조하십시오.
1. 클러스터에 연결하는 각 클라이언트 컴퓨터에서 이전 단계에서 만든 사본을 기반으로 동일한 `/etc/krb5.conf` 파일을 생성합니다.
## Kinit 및 SSH 사용
사용자가 Kerberos 자격 증명을 사용하여 클라이언트 컴퓨터에서 연결할 때마다 먼저 사용자가 클라이언트 컴퓨터에서 사용자용 Kerberos 티켓을 갱신해야 합니다. 또한 SSH 클라이언트는 GSSAPI 인증을 사용하도록 구성되어야 합니다.
**SSH를 사용하여 Kerberos 기반 EMR 클러스터에 연결하려면**
1. 다음 예와 같이 `kinit`를 사용하여 Kerberos 티켓을 갱신합니다.
```
kinit user1
```
1. 클러스터 전용 KDC 또는 Active Directory 사용자 이름으로 생성한 보안 주체와 함께 `ssh` 클라이언트를 사용합니다. 다음 예와 같이 GSSAPI 인증이 활성화되어 있는지 확인합니다.
**예: Linux 사용자**
`-K `옵션은 GSSAPI 인증을 지정합니다.
```
ssh -K user1@MasterPublicDNS
```
**예: Windows 사용자(PuTTY)**
다음과 같이 세션에 대한 GSSAPI 인증 옵션이 활성화되어 있는지 확인합니다.
![\[PuTTY Configuration window showing GSSAPI authentication options and library preferences.\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/images/kerb-gssapi-putty.png)
# 자습서: Amazon EMR을 사용하여 클러스터 전용 KDC 구성
이 주제에서는 클러스터 전용 *키 배포 센터(KDC)*를 사용하여 클러스터를 생성하고, 모든 클러스터 노드에서 수동으로 Linux 사용자 계정을 추가하며, 프라이머리 노드의 KDC에 Kerberos 보안 주체를 추가하고, 클라이언트 컴퓨터에 Kerberos 클라이언트를 설치하도록 보장하는 과정을 안내합니다.
Kerberos 및 KDC에 대한 Amazon EMR 지원에 대한 자세한 내용과 MIT Kerberos 설명서 링크는 [Amazon EMR을 통한 인증에 Kerberos 사용](emr-kerberos.md) 섹션을 참조하세요.
## 1단계: Kerberos 인증을 사용하는 클러스터 생성
1. Kerberos 인증을 사용하는 보안 구성을 생성합니다. 다음 예제에서는 보안 구성을 인라인 JSON 구조로 AWS CLI 지정하는를 사용하는 `create-security-configuration` 명령을 보여줍니다. 또한 로컬에 저장된 파일을 참조할 수 있습니다.
```
aws emr create-security-configuration --name MyKerberosConfig \
--security-configuration '{"AuthenticationConfiguration": {"KerberosConfiguration":
{"Provider": "ClusterDedicatedKdc", "ClusterDedicatedKdcConfiguration": {"TicketLifetimeInHours": 24}}}}'
```
1. 보안 구성을 참조하고 클러스터에 대해 Kerberos 속성을 설정하며 부트스트랩 작업을 사용하여 Linux 계정을 추가하는 클러스터를 생성합니다. 다음 예제는 AWS CLI를 사용하는 `create-cluster `명령을 보여줍니다. 이 명령은 위에서 생성한 보안 구성인 `MyKerberosConfig`를 참조합니다. 또한 부트스트랩 작업으로 간단한 스크립트 `createlinuxusers.sh`를 참조합니다. 클러스터 생성 전에 만들어 Amazon S3에 업로드합니다.
```
aws emr create-cluster --name "MyKerberosCluster" \
--release-label emr-7.12.0 \
--instance-type m5.xlarge \
--instance-count 3 \
--ec2-attributes InstanceProfile=EMR_EC2_DefaultRole,KeyName=MyEC2KeyPair \
--service-role EMR_DefaultRole \
--security-configuration MyKerberosConfig \
--applications Name=Hadoop Name=Hive Name=Oozie Name=Hue Name=HCatalog Name=Spark \
--kerberos-attributes Realm=EC2.INTERNAL,\
KdcAdminPassword=MyClusterKDCAdminPwd \
--bootstrap-actions Path=s3://amzn-s3-demo-bucket/createlinuxusers.sh
```
다음 코드는 `createlinuxusers.sh` 스크립트의 내용을 보여줍니다(클러스터의 각 노드에 user1, user2 및 user3 추가). 다음 단계에서는 이들 사용자를 KDC 보안 주체로 추가합니다.
```
#!/bin/bash
sudo adduser user1
sudo adduser user2
sudo adduser user3
```
## 2단계: KDC에 보안 주체 추가, HDFS 사용자 디렉터리 생성 및 SSH 구성
프라이머리 노드에서 실행 중인 KDC는 로컬 호스트와 클러스터에서 생성한 각 사용자에 대해 보안 주체를 추가해야 합니다. 또한 클러스터를 연결하고 Hadoop 작업을 실행하기 위해 필요할 경우 각 사용자에 대해 HDFS 디렉터리를 생성할 수도 있습니다. 마찬가지로 Kerberos에서 필요한 GSSAPI 인증을 활성화하도록 SSH 서비스를 구성합니다. GSSAPI를 활성화한 후에는 SSH 서비스를 다시 시작합니다.
이러한 작업을 가장 간단하게 수행할 수 있는 방법은 클러스터에 하나의 단계를 제출하는 것입니다. 다음 예제는 이전 단계에서 생성한 클러스터에 bash 스크립트 `configurekdc.sh`를 제출하여 클러스터 ID를 참조합니다. 스크립트는 Amazon S3에 저장됩니다. 또는 EC2 키 페어를 사용해 프라이머리 노드를 연결하여 명령을 실행하거나 클러스터가 생성되는 동안 단계를 제출할 수도 있습니다.
```
aws emr add-steps --cluster-id --steps Type=CUSTOM_JAR,Name=CustomJAR,ActionOnFailure=CONTINUE,Jar=s3://myregion.elasticmapreduce/libs/script-runner/script-runner.jar,Args=["s3://amzn-s3-demo-bucket/configurekdc.sh"]
```
다음 코드는 `configurekdc.sh` 스크립트의 내용을 보여줍니다.
```
#!/bin/bash
#Add a principal to the KDC for the primary node, using the primary node's returned host name
sudo kadmin.local -q "ktadd -k /etc/krb5.keytab host/`hostname -f`"
#Declare an associative array of user names and passwords to add
declare -A arr
arr=([user1]=pwd1 [user2]=pwd2 [user3]=pwd3)
for i in ${!arr[@]}; do
#Assign plain language variables for clarity
name=${i}
password=${arr[${i}]}
# Create principal for sshuser in the primary node and require a new password on first logon
sudo kadmin.local -q "addprinc -pw $password +needchange $name"
#Add user hdfs directory
hdfs dfs -mkdir /user/$name
#Change owner of user's hdfs directory to user
hdfs dfs -chown $name:$name /user/$name
done
# Enable GSSAPI authentication for SSH and restart SSH service
sudo sed -i 's/^.*GSSAPIAuthentication.*$/GSSAPIAuthentication yes/' /etc/ssh/sshd_config
sudo sed -i 's/^.*GSSAPICleanupCredentials.*$/GSSAPICleanupCredentials yes/' /etc/ssh/sshd_config
sudo systemctl restart sshd
```
추가한 사용자는 이제 SSH를 사용하여 클러스터에 연결할 수 있습니다. 자세한 내용은 [SSH를 사용하여 Amazon EMR에서 Kerberos 클러스터에 연결](emr-kerberos-connect-ssh.md) 단원을 참조하십시오.
# 자습서: Active Directory 도메인과 교차 영역 신뢰 구성
교차 영역 신뢰를 설정할 때 다른 Kerberos 영역의 보안 주체들(주로 사용자들)이 EMR 클러스터의 애플리케이션 구성 요소에 대해 인증을 할 수 있도록 허용합니다. 클러스터 전용 *키 배포 센터(KDC)*는 두 KDC에 모두 존재하는 *교차 영역 보안 주체*를 사용하여 다른 KDC와 신뢰 관계를 구축합니다. 보안 주체의 이름과 암호가 정확하게 일치합니다.
교차 영역 신뢰를 위해서는 두 KDC가 네트워크를 통해 상호 연결되고 상대의 도메인 이름을 확인할 수 있어야 합니다. 아래에는 EC2 인스턴스로 실행 중인 Microsoft AD 도메인 컨트롤러와 교차 영역 신뢰 관계를 구축하기 위한 단계와 함께 필요한 연결 및 도메인 이름 확인을 제공하는 네트워크 설정의 예가 나와 있습니다. KDC 간에 필요한 네트워크 트래픽을 허용하는 모든 네트워크 설정이 허용됩니다.
선택적으로, 한 클러스터에서 KDC를 사용하여 Active Directory와의 교차 영역 신뢰를 구축한 후 다른 보안 구성을 사용하여 첫 번째 클러스터의 KDC를 외부 KDC로 참조하는 다른 클러스터를 생성할 수 있습니다. 보안 그룹 및 클러스터 설정의 예는 [Active Directory 교차 영역 신뢰가 있는 외부 클러스터 KDC](emr-kerberos-config-examples.md#emr-kerberos-example-extkdc-ad-trust) 섹션을 참조하세요.
Kerberos 및 KDC에 대한 Amazon EMR 지원에 대한 자세한 내용과 MIT Kerberos 설명서 링크는 [Amazon EMR을 통한 인증에 Kerberos 사용](emr-kerberos.md) 섹션을 참조하세요.
**중요**
Amazon EMR은 와의 교차 영역 신뢰를 지원하지 않습니다 AWS Directory Service for Microsoft Active Directory.
[1단계: VPC 및 서브넷 설정](#emr-kerberos-ad-network)
[2단계: Active Directory 도메인 컨트롤러 시작 및 설치](#emr-kerberos-ad-dc)
[3단계: EMR 클러스터에서 도메인에 사용자 계정 추가](#emr-kerberos-ad-users)
[4단계: Active Directory 도메인 컨트롤러에서 인바운드 신뢰 구성](#emr-kerberos-ad-configure-trust)
[5단계: DHCP 옵션 세트를 사용하여 Active Directory 도메인 컨트롤러를 VPC DNS 서버로 지정](#emr-kerberos-ad-DHCP)
[6단계: Kerberos 인증을 사용하는 EMR 클러스터 시작](#emr-kerberos-ad-cluster)
[7단계: Active Directory 계정에 대해 HDFS 사용자 생성 및 클러스터에서 설정](#emr-kerberos-ad-hadoopuser)
## 1단계: VPC 및 서브넷 설정
다음 단계는 클러스터 전용 KDC가 Active Directory 도메인 컨트롤러에 연결되고 도메인 이름을 확인할 수 있도록 VPC 및 서브넷을 생성하는 방법을 보여줍니다. 이러한 단계에서는 DHCP 옵션 세트의 도메인 이름 서버로 Active Directory 도메인 컨트롤러를 참조하여 도메인 이름을 확인합니다. 자세한 내용은 [5단계: DHCP 옵션 세트를 사용하여 Active Directory 도메인 컨트롤러를 VPC DNS 서버로 지정](#emr-kerberos-ad-DHCP) 단원을 참조하십시오.
KDC와 Active Directory 도메인 컨트롤러는 서로의 도메인 이름을 확인할 수 있어야 합니다. 그래야만 Amazon EMR이 컴퓨터를 도메인에 조인하고 클러스터 인스턴스에서 해당되는 Linux 계정 및 SSH 파라미터를 자동으로 구성할 수 있습니다.
Amazon EMR이 도메인 이름을 확인할 수 없으면 Active Directory 도메인 컨트롤러의 IP 주소를 사용하여 신뢰 관계를 참조할 수 있습니다. 한편, Linux 계정을 수동으로 추가하고 클러스터 전용 KDC에 해당되는 보안 주체를 추가하고 SSH를 구성해야 합니다.
**VPC 및 서브넷을 설정하려면**
1. 단일 퍼블릭 서브넷이 포함된 Amazon VPC를 생성합니다. 자세한 내용은 *Amazon VPC 시작하기 안내서*에서 [1단계: VPC 생성](https://docs.aws.amazon.com/AmazonVPC/latest/GettingStartedGuide/getting-started-ipv4.html#getting-started-create-vpc)을 참조하세요.
**중요**
Microsoft Active Directory 도메인 컨트롤러를 사용할 때는 모든 IPv4 주소의 길이가 9자 미만이 되도록(예: 10.0.0.0/16) EMR 클러스터용 CIDR 블록을 선택합니다. 이는 컴퓨터가 Active Directory 디렉터리에 조인할 때 클러스터 컴퓨터의 DNS 이름이 사용되기 때문입니다.는 더 긴 IP 주소로 인해 [DNS 이름이 15자를 초과할 수 있는 방식으로 IPv4 주소를 기반으로 DNS 호스트](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-hostnames) 이름을 AWS 할당합니다. IPv4 Active Directory는 조인된 컴퓨터 이름을 15자로 제한하고 예상하지 못한 오류가 발생하지 않도록 긴 이름은 끝을 자릅니다.
1. VPC에 할당된 기본 DHCP 옵션 세트를 제거합니다. 자세한 내용은 [VPC가 아무런 DHCP 옵션도 사용하지 못하도록 변경](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html#DHCP_Use_No_Options)을 참조하세요. 그런 다음, DNS 서버로 Active Directory 도메인 컨트롤러를 지정하는 이름을 새로 추가합니다.
1. VPC에서 DNS 지원이 활성화되었는지, 즉 DNS 호스트 이름과 DNS 확인이 모두 활성화되었는지 확인합니다. 전환은 기본적으로 활성화되어 있습니다. 자세한 내용은 [VPC에 대한 DNS 지원 업데이트](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating)를 참조하세요.
1. 기본 설정대로 VPC에 인터넷 게이트웨이가 연결되어 있는지 확인합니다. 자세한 내용은 [인터넷 게이트웨이 생성 및 연결](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html#Add_IGW_Attach_Gateway)을 참조하세요.
**참고**
이 예제에서는 VPC에 대해 새로운 도메인 컨트롤러를 설정하고 있기 때문에 인터넷 게이트웨이가 사용됩니다. 인터넷 게이트웨이가 애플리케이션에서 필요하지 않을 수 있습니다. 유일한 조건은 클러스터 전용 KDC가 Active Directory 도메인 컨트롤러에 액세스할 수 있어야 한다는 것입니다.
1. 사용자 지정 라우팅 테이블을 생성하고 인터넷 게이트웨이를 목표로 하는 루트를 추가한 다음, 서브넷에 이를 연결합니다. 자세한 내용은 [사용자 지정 라우팅 테이블 생성](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html#Add_IGW_Routing)을 참조하세요.
1. 도메인 컨트롤러에서 EC2 인스턴스를 시작할 때는 RDP를 사용하여 연결할 수 있도록 정적 퍼블릭 IPv4 주소가 있어야 합니다. 가장 간단한 방법은 퍼블릭 IPv4 주소를 자동 할당하도록 서브넷을 구성하는 것입니다. 이는 서브넷이 생성될 때 기본 설정이 아닙니다. 자세한 내용은 [서브넷의 퍼블릭 IP 주소 지정 속성 수정](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip)을 참조하세요. 선택에 따라 인스턴스를 시작할 때 이 주소를 할당할 수 있습니다. 자세한 내용은 [인스턴스 시작 중 퍼블릭 IPv4 주소 할당](https://docs.aws.amazon.com/vpc/latest/userguide/using-instance-addressing.html#public-ip-addresses)을 참조하세요.
1. 할당을 완료하면 VPC 및 서브넷 ID를 기록해뒀다가 나중에 Active Directory 도메인 컨트롤러와 클러스터를 시작할 때 사용합니다.
## 2단계: Active Directory 도메인 컨트롤러 시작 및 설치
1. Microsoft Windows Server 2016 기반 AMI를 토대로 EC2 인스턴스를 시작합니다. m4.xlarge나 더 나은 인스턴스 유형을 사용하는 것이 좋습니다. 자세한 내용은 **Amazon EC2 사용 설명서의 [AWS Marketplace 인스턴스 시작](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/launch-marketplace-console.html)을 참조하세요.
1. EC2 인스턴스와 연관된 보안 그룹의 그룹 ID를 기록해 두세요. 나중에 [6단계: Kerberos 인증을 사용하는 EMR 클러스터 시작](#emr-kerberos-ad-cluster)에서 필요합니다. 여기서는 *sg-012xrlmdomain345*를 사용합니다. 또는 EMR 클러스터와, 이들 간에 트래픽을 허용하는 이 인스턴스에 대해 서로 다른 보안 그룹을 지정할 수 있습니다. 자세한 내용은 *Amazon EC2 사용 설명서*의 [Linux 인스턴스용 Amazon EC2 보안 그룹](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html)을 참조하세요.
1. RDP를 사용해 EC2 인스턴스에 연결합니다. 자세한 내용은 **Amazon EC2 사용 설명서의 [Windows 인스턴스에 연결](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/connecting_to_windows_instance.html)을 참조하세요.
1. **서버 관리자**를 열고 해당 서버에서 Active Directory 도메인 서비스 역할을 설치 및 구성합니다. 서버를 도메인 컨트롤러로 승격하고 도메인 이름(이 예제에서는 `ad.domain.com`)을 할당합니다. 나중에 EMR 보안 구성 및 클러스터를 생성할 때 필요하기 때문에 도메인 이름을 적어둡니다. Active Directory를 처음 설정하는 경우 [Windows Server 2016에서 Active Directory(AD)를 설정하는 방법](https://ittutorials.net/microsoft/windows-server-2016/setting-up-active-directory-ad-in-windows-server-2016/)의 지침을 따를 수 있습니다.
설정이 완료되면 인스턴스가 다시 시작됩니다.
## 3단계: EMR 클러스터에서 도메인에 사용자 계정 추가
각 클러스터 사용자에 대해 Active Directory 사용자 및 컴퓨터에서 계정을 생성할 수 있도록 RDP를 Active Directory 도메인 컨트롤러에 추가합니다. 자세한 내용은 *Microsoft Learn* 사이트에서 [Create a User Account in Active Directory Users and Computers](https://technet.microsoft.com/en-us/library/dd894463(v=ws.10).aspx)를 참조하세요. 각 사용자의 **사용자 로그온 이름**을 적어둡니다. 나중에 클러스터를 구성할 때 필요하기 때문입니다.
뿐만 아니라, 컴퓨터를 도메인에 조인할 수 있는 충분한 권한을 가진 계정을 생성해야 합니다. 이 계정은 클러스터를 생성할 때 지정합니다. Amazon EMR은 이를 사용하여 클러스터 인스턴스를 도메인에 조인합니다. [6단계: Kerberos 인증을 사용하는 EMR 클러스터 시작](#emr-kerberos-ad-cluster)에서 이 계정과 암호를 지정합니다. 컴퓨터 조인 권한을 이 계정에 위임하려면 조인 권한을 가진 그룹을 생성한 다음, 이 그룹에 사용자를 할당하는 것이 좋습니다. 관련 지침은 *AWS Directory Service 관리 안내서*에서 [디렉터리 조인 권한 위임](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_join_privileges.html)을 참조하세요.
## 4단계: Active Directory 도메인 컨트롤러에서 인바운드 신뢰 구성
아래의 명령 예제는 Active Directory에서 클러스터 전용 KDC와 단방향 및 비-전이 인바운드 영역 신뢰를 구축합니다. 이 예제에서는 클러스터의 영역은 `EC2.INTERNAL`입니다. *KDC-FQDN*을 KDC를 호스팅하는 Amazon EMR 프라이머리 노드에 대해 나열된 **퍼블릭 DNS** 이름으로 바꿉니다. `passwordt` 파라미터는 클러스터를 생성할 때 클러스터 **영역**과 함께 지정하는 **교차 영역 보안 주체 암호**를 지정합니다. 영역 이름은 해당 클러스터에 대한 `us-east-1`의 기본 도메인 이름에서 파생됩니다. `Domain`은 신뢰를 생성하고 있는 Active Directory 도메인으로, 일반적으로 소문자를 많이 사용합니다. 이 예에서는 `ad.domain.com`을 사용합니다.
관리자 권한으로 Windows 명령 프롬프트를 열고 다음 명령을 입력하여 Active Directory 도메인 컨트롤러에서 신뢰 관계를 생성합니다.
```
C:\Users\Administrator> ksetup /addkdc EC2.INTERNAL KDC-FQDN
C:\Users\Administrator> netdom trust EC2.INTERNAL /Domain:ad.domain.com /add /realm /passwordt:MyVeryStrongPassword
C:\Users\Administrator> ksetup /SetEncTypeAttr EC2.INTERNAL AES256-CTS-HMAC-SHA1-96
```
## 5단계: DHCP 옵션 세트를 사용하여 Active Directory 도메인 컨트롤러를 VPC DNS 서버로 지정
Active Directory 도메인 컨트롤러가 구성되면 VPC 내에서 이름 확인 시 도메인 이름 서버로 사용할 수 있도록 VPC를 구성해야 합니다. 이를 위해서 DHCP 옵션 세트를 연결합니다. **도메인 이름**을 클러스터의 도메인 이름으로 지정합니다. 예를 들어, 클러스터가 us-east-1에 있는 경우에는 `ec2.internal`, 다른 리전의 경우에는 `region.compute.internal`입니다. **도메인 이름 서버**에서 첫 번째 항목으로 Active Directory 도메인 컨트롤러(클러스터에서 연결이 가능해야 함)의 IP 주소를 지정한 다음 **AmazonProvidedDNS**(예를 들면 ***xx.xx.xx.xx*,AmazonProvidedDNS**)를 지정해야 합니다. 자세한 내용은 [DHCP 옵션 세트 변경](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html#DHCPOptions)을 참조하세요.
## 6단계: Kerberos 인증을 사용하는 EMR 클러스터 시작
1. Amazon EMR에서 이전 단계에서 생성한 Active Directory 도메인 컨트롤러를 지정하는 보안 구성을 생성합니다. 아래에 명령 예제가 나와 있습니다. 도메인 `ad.domain.com`을 [2단계: Active Directory 도메인 컨트롤러 시작 및 설치](#emr-kerberos-ad-dc)에서 지정한 도메인 이름으로 대체합니다.
```
aws emr create-security-configuration --name MyKerberosConfig \
--security-configuration '{
"AuthenticationConfiguration": {
"KerberosConfiguration": {
"Provider": "ClusterDedicatedKdc",
"ClusterDedicatedKdcConfiguration": {
"TicketLifetimeInHours": 24,
"CrossRealmTrustConfiguration": {
"Realm": "AD.DOMAIN.COM",
"Domain": "ad.domain.com",
"AdminServer": "ad.domain.com",
"KdcServer": "ad.domain.com"
}
}
}
}
}'
```
1. 다음 속성을 사용하여 클러스터를 생성합니다.
+ `--security-configuration` 옵션을 사용하여 생성한 보안 구성을 지정합니다. 이 예제에서는 *MyKerberosConfig*를 사용합니다.
+ `--ec2-attributes option`의 `SubnetId` 속성을 사용하여 [1단계: VPC 및 서브넷 설정](#emr-kerberos-ad-network)에서 생성한 서브넷을 지정합니다. 이 예제에서는 *step1-subnet*을 사용합니다.
+ `--ec2-attributes` 옵션의 `AdditionalMasterSecurityGroups` 및 `AdditionalSlaveSecurityGroups`를 사용하여 [2단계: Active Directory 도메인 컨트롤러 시작 및 설치](#emr-kerberos-ad-dc)의 AD 도메인 컨트롤러와 연결된 보안 그룹이 코어 및 태스크 노드뿐만 아니라 클러스터 프라이머리 노드와 연결되도록 지정합니다. 이 예제에서는 *sg-012xrlmdomain345*를 사용합니다.
또한 `--kerberos-attributes`를 사용하여 다음과 같은 클러스터 고유의 Kerberos 속성을 지정합니다.
+ Active Directory 도메인 컨트롤러를 설정할 때 지정한 클러스터 영역
+ `passwordt`에서 [4단계: Active Directory 도메인 컨트롤러에서 인바운드 신뢰 구성](#emr-kerberos-ad-configure-trust)로 지정한 교차 영역 신뢰 보안 주체의 암호.
+ `KdcAdminPassword`는 클러스터 전용 KDC를 관리하는 데 사용할 수 있습니다.
+ [3단계: EMR 클러스터에서 도메인에 사용자 계정 추가](#emr-kerberos-ad-users)에서 생성한 컴퓨터 조인 권한을 가진 Active Directory 계정의 사용자 로그인 이름 및 암호.
다음 예제는 Kerberos 인증을 사용하는 클러스터를 시작합니다.
```
aws emr create-cluster --name "MyKerberosCluster" \
--release-label emr-5.10.0 \
--instance-type m5.xlarge \
--instance-count 3 \
--ec2-attributes InstanceProfile=EMR_EC2_DefaultRole,KeyName=MyEC2KeyPair,\
SubnetId=step1-subnet, AdditionalMasterSecurityGroups=sg-012xrlmdomain345,
AdditionalSlaveSecurityGroups=sg-012xrlmdomain345\
--service-role EMR_DefaultRole \
--security-configuration MyKerberosConfig \
--applications Name=Hadoop Name=Hive Name=Oozie Name=Hue Name=HCatalog Name=Spark \
--kerberos-attributes Realm=EC2.INTERNAL,\
KdcAdminPassword=MyClusterKDCAdminPwd,\
ADDomainJoinUser=ADUserLogonName,ADDomainJoinPassword=ADUserPassword,\
CrossRealmTrustPrincipalPassword=MatchADTrustPwd
```
## 7단계: Active Directory 계정에 대해 HDFS 사용자 생성 및 클러스터에서 설정
Active Directory와 신뢰 관계를 설정할 때 Amazon EMR은 각 Active Directory 계정에 대해 클러스터에서 Linux 사용자를 생성합니다. 예를 들어, Active Directory의 사용자 로그인 이름 `LiJuan`은 `lijuan`이라는 Linux 계정을 갖습니다. Active Directory 사용자 이름에는 대문자가 포함될 수 있지만 Linux는 Active Directory 대소문자를 인식하지 못합니다.
사용자가 클러스터에 로그인하여 Hadoop 작업을 실행할 수 있도록 하려면 Linux 계정에서 HDFS 사용자 디렉터리를 추가하고 각 사용자에게 디렉터리에 대한 소유권을 부여해야 합니다. 이를 위해서는 클러스터 단계로 Amazon S3에 저장된 스크립트를 실행하는 것이 좋습니다. 또는 프라이머리 노드의 명령줄에서 아래 스크립트의 명령을 실행할 수도 있습니다. 클러스터를 생성할 때 지정했던 EC2 키 페어를 사용하여 Hadoop 사용자로 SSH를 통해 프라이머리 노드를 연결합니다. 자세한 내용은 [Amazon EMR에서 SSH 자격 증명에 대해 EC2 키 페어 사용](emr-plan-access-ssh.md) 단원을 참조하십시오.
다음 명령을 실행하여 스크립트 *AddHDFSUsers.sh*를 실행하는 클러스터에 단계를 하나 추가합니다.
```
aws emr add-steps --cluster-id \
--steps Type=CUSTOM_JAR,Name=CustomJAR,ActionOnFailure=CONTINUE,\
Jar=s3://region.elasticmapreduce/libs/script-runner/script-runner.jar,Args=["s3://amzn-s3-demo-bucket/AddHDFSUsers.sh"]
```
파일 *AddHDFSUsers.sh*의 내용은 다음과 같습니다.
```
#!/bin/bash
# AddHDFSUsers.sh script
# Initialize an array of user names from AD or Linux users and KDC principals created manually on the cluster
ADUSERS=("lijuan" "marymajor" "richardroe" "myusername")
# For each user listed, create an HDFS user directory
# and change ownership to the user
for username in ${ADUSERS[@]}; do
hdfs dfs -mkdir /user/$username
hdfs dfs -chown $username:$username /user/$username
done
```
### Hadoop 그룹에 매핑된 Active Directory 그룹
Amazon EMR은 시스템 보안 서비스 대몬(daemon)(SSD)을 사용하여 Hadoop 그룹에 Active Directory 그룹을 매핑합니다. [SSH를 사용하여 Amazon EMR에서 Kerberos 클러스터에 연결](emr-kerberos-connect-ssh.md)에 설명된 대로 프라이머리 노드에 로그인한 후에 그룹 매핑을 확인하기 위해 `hdfs groups` 명령을 사용하여 클러스터에서 해당 Hadoop 사용자의 Hadoop 그룹에 Active Directory 계정이 속한 Active Directory 그룹이 매핑되었는지 확인할 수 있습니다. 또한 명령(예를 들면 `hdfs groups lijuan`)을 사용하여 하나 이상의 사용자 이름을 지정하는 방법으로 다른 사용자의 그룹 매핑을 확인할 수도 있습니다. 자세한 내용은 [Apache HDFS Commands Guide](https://hadoop.apache.org/docs/r2.7.1/hadoop-project-dist/hadoop-hdfs/HDFSCommands.html#groups)의 [groups](https://hadoop.apache.org/docs/r2.7.1/hadoop-project-dist/hadoop-hdfs/HDFSCommands.html)를 참조하세요.
# Amazon EMR을 통한 인증에 Active Directory 또는 LDAP 서버 사용
Amazon EMR 릴리스 6.12.0 이상에서는 LDAP over SSL(LDAPS) 프로토콜을 사용하여 엔터프라이즈 ID 서버와 기본적으로 통합되는 클러스터를 시작할 수 있습니다. Lightweight Directory Access Protocol(LDAP)은 데이터에 액세스하고 데이터를 유지 관리하는 벤더 중립적인 개방형 애플리케이션 프로토콜입니다. LDAP는 일반적으로 Active Directory(AD) 및 OpenLDAP와 같은 애플리케이션에 호스팅되는 기업 자격 증명 서버에 대한 사용자 인증에 사용됩니다. 이 기본 통합을 통해 LDAP 서버를 사용하여 Amazon EMR에서 사용자를 인증할 수 있습니다.
Amazon EMR LDAP 통합의 주요 내용은 다음과 같습니다.
+ Amazon EMR은 지원되는 애플리케이션이 사용자를 대신하여 LDAP 인증을 통해 인증하도록 구성합니다.
+ Amazon EMR은 Kerberos 프로토콜을 사용하여 지원되는 애플리케이션의 보안을 구성하고 유지합니다. 명령이나 스크립트를 입력할 필요가 없습니다.
+ Hive 메타스토어 데이터베이스 및 테이블에 대한 Apache Ranger 인증을 통해 세분화된 액세스 제어(FGAC)가 지원됩니다. 자세한 정보는 [Amazon EMR과 Apache Ranger 통합](emr-ranger.md)을 참조하세요.
+ 클러스터에 액세스하는 데 LDAP 보안 인증이 필요한 경우 SSH를 통해 EMR 클러스터에 액세스할 수 있는 사용자에 대한 세분화된 액세스 제어(FGAC)가 지원됩니다.
다음 페이지에서는 Amazon EMR LDAP 통합을 사용하여 EMR 클러스터를 시작하기 위한 개념적 개요, 필수 조건 및 해당 단계를 제공합니다.
**Topics**
+ [Amazon EMR에서 LDAP 개요](ldap-overview.md)
+ [Amazon EMR의 LDAP 구성 요소](ldap-components.md)
+ [Amazon EMR용 LDAP의 애플리케이션 지원 및 고려 사항](ldap-considerations.md)
+ [LDAP를 사용하여 EMR 클러스터 구성 및 시작](ldap-setup.md)
+ [Amazon EMR과 함께 LDAP를 사용하는 예제](ldap-examples.md)
# Amazon EMR에서 LDAP 개요
Lightweight Directory Access Protocol(LDAP)은 네트워크 관리자가 회사 네트워크 내에서 사용자를 인증하여 데이터에 대한 액세스를 관리하고 제어하는 데 사용하는 소프트웨어 프로토콜입니다. LDAP 프로토콜은 정보를 계층적 트리 디렉터리 구조로 저장합니다. 자세한 내용은 *LDAP.com*에서 [Basic LDAP Concepts](https://ldap.com/basic-ldap-concepts/)를 참조하세요.
회사 네트워크 내에서 많은 애플리케이션이 LDAP 프로토콜을 사용하여 사용자를 인증할 수 있습니다. Amazon EMR LDAP 통합을 통해 EMR 클러스터는 기본적으로 보안 구성이 추가된 동일한 LDAP 프로토콜을 사용할 수 있습니다.
Amazon EMR이 지원하는 LDAP 프로토콜에는 **Active Directory** 및 **OpenLDAP**라는 두 가지 주요 구현이 있습니다. 다른 구현도 가능하지만 대부분은 Active Directory 또는 OpenLDAP와 동일한 인증 프로토콜에 적합합니다.
## Active Directory(AD)
Active Directory(AD)는 Windows 도메인 네트워크를 위한 Microsoft의 디렉터리 서비스입니다. AD는 대부분의 Windows Server 운영 체제에 포함되어 있으며 LDAP 및 LDAPS 프로토콜을 통해 클라이언트와 통신할 수 있습니다. 인증을 위해 Amazon EMR은 고유 이름 및 암호로 사용자 보안 주체 이름(UPN)을 사용하여 AD 인스턴스와의 사용자 바인드를 시도합니다. UPN은 표준 형식 `username@domain_name`을 사용합니다.
## OpenLDAP
OpenLDAP는 LDAP 프로토콜의 무료 오픈 소스 구현입니다. 인증을 위해 Amazon EMR은 정규화된 도메인 이름(FQDN)을 고유 이름 및 암호로 사용하여 OpenLDAP 인스턴스에 대한 사용자 바인드를 시도합니다. FQDN은 표준 형식 `username_attribute=username,LDAP_user_search_base`를 사용합니다. 일반적으로 `username_attribute` 값은`uid`이며, `LDAP_user_search_base` 값에는 사용자에게 연결되는 트리의 속성이 포함됩니다. 예를 들어 `ou=People,dc=example,dc=com`입니다.
LDAP 프로토콜의 다른 무료 및 오픈 소스 구현은 일반적으로 사용자의 고유 이름에 대해 OpenLDAP와 유사한 FQDN을 따릅니다.
# Amazon EMR의 LDAP 구성 요소
LDAP 서버를 사용하여 Amazon EMR 및 사용자가 다음 구성 요소를 통해 EMR 클러스터에서 직접 사용하는 모든 애플리케이션을 인증할 수 있습니다.
**Secret Agent**
*Secret Agent*는 모든 사용자 요청을 인증하는 클러스터 내 프로세스입니다. Secret Agent는 EMR 클러스터에서 지원되는 애플리케이션을 대신하여 LDAP 서버에 대한 사용자 바인드를 생성합니다. Secret Agent는 `emrsecretagent` 사용자로 실행되고 `/emr/secretagent/log` 디렉터리에 로그를 씁니다. 이러한 로그는 각 사용자의 인증 요청 상태와 사용자 인증 중에 나타날 수 있는 오류에 대한 세부 정보를 제공합니다.
**시스템 보안 서비스 대몬(daemon)(SSSD)**
*SSSD*는 LDAP 지원 EMR 클러스터의 각 노드에서 실행되는 대몬(daemon)입니다. SSSD는 UNIX 사용자를 생성하고 관리하여 원격 기업 자격 증명을 각 노드에 동기화합니다. Hive 및 Spark와 같은 YARN 기반 애플리케이션에서는 사용자에 대한 쿼리를 실행하는 모든 노드에 로컬 UNIX 사용자가 있어야 합니다.
# Amazon EMR용 LDAP의 애플리케이션 지원 및 고려 사항
이 주제에서는 지원되는 애플리케이션, 지원되는 기능 및 지원되지 않는 기능을 나열합니다.
## Amazon EMR용 LDAP에서 지원되는 애플리케이션
**중요**
이 페이지에 나열된 애플리케이션은 Amazon EMR에서 LDAP에 대해 지원하는 유일한 애플리케이션입니다. 클러스터 보안을 위해 LDAP가 활성화된 EMR 클러스터를 생성할 때 LDAP 호환 애플리케이션만 포함할 수 있습니다. 지원되지 않는 다른 애플리케이션을 설치하려고 하면 Amazon EMR은 새 클러스터에 대한 요청을 거부합니다.
Amazon EMR 릴리스 6.12 이상에서는 다음 애플리케이션과의 LDAP 통합을 지원합니다.
+ Apache Livy
+ HiveServer2(HS2)를 통해 Apache Hive에서
+ Trino
+ Presto
+ Hue
EMR 클러스터에 다음 애플리케이션을 설치하고 보안 요구 사항에 맞게 구성할 수도 있습니다.
+ Apache Spark
+ Apache Hadoop
## Amazon EMR용 LDAP에서 지원되는 기능
다음 Amazon EMR 기능을 LDAP 통합과 함께 사용할 수 있습니다.
**참고**
LDAP 보안 인증을 보안하려면 전송 중 암호화를 사용하여 클러스터 내외부의 데이터 흐름을 보호해야 합니다. 전송 중 암호화에 대한 자세한 내용은 [Amazon EMR에서 저장 데이터 및 전송 중 데이터 암호화](emr-data-encryption.md) 섹션을 참조하세요.
+ 전송 중 데이터 암호화(필수) 및 저장 데이터 암호화
+ 인스턴스 그룹, 인스턴스 플릿, 스팟 인스턴스
+ 실행 중인 클러스터에서 애플리케이션 재구성
+ EMRFS 서버 측 암호화(SSE)
## 지원되지 않는 기능
Amazon EMR LDAP 통합을 사용할 경우 다음과 같은 제한 사항을 고려합니다.
+ Amazon EMR은 LDAP가 활성화된 클러스터에 대해 단계를 비활성화합니다.
+ Amazon EMR은 LDAP가 활성화된 클러스터에 대한 런타임 역할 및 AWS Lake Formation 통합을 지원하지 않습니다.
+ Amazon EMR은 StartTLS를 통한 LDAP를 지원하지 않습니다.
+ Amazon EMR은 LDAP가 활성화된 클러스터에서 고가용성 모드(여러 프라이머리 노드가 있는 클러스터)를 지원하지 않습니다.
+ LDAP가 활성화된 클러스터의 바인드 보안 인증 또는 인증서를 로테이션할 수 없습니다. 이러한 필드 중 하나라도 로테이션된 경우 업데이트된 바인드 보안 인증 또는 인증서를 사용하여 새 클러스터를 시작하는 것이 좋습니다.
+ LDAP에서는 정확한 검색 기반을 사용해야 합니다. LDAP 사용자 및 그룹 검색 기반은 LDAP 검색 필터를 지원하지 않습니다.
# LDAP를 사용하여 EMR 클러스터 구성 및 시작
이 섹션에서는 LDAP 인증에 사용할 수 있도록 Amazon EMR을 구성하는 방법을 설명합니다.
**Topics**
+ [Amazon EMR 인스턴스 역할에 AWS Secrets Manager 권한 추가](ldap-setup-asm.md)
+ [LDAP 통합을 위한 Amazon EMR 보안 구성 생성](ldap-setup-security.md)
+ [LDAP로 인증하는 EMR 클러스터 시작](ldap-setup-launch.md)
# Amazon EMR 인스턴스 역할에 AWS Secrets Manager 권한 추가
Amazon EMR은 IAM 서비스 역할을 사용하여 클러스터 프로비저닝 및 관리하는 작업을 자동으로 수행합니다. 클러스터 EC2 인스턴스의 서비스 역할(*Amazon EMR에 대한 EC2 인스턴스 프로파일*이라고도 함)은 시작할 때 Amazon EMR에서 클러스터의 모든 EC2 인스턴스에 할당하는 특별한 유형의 서비스 역할입니다.
EMR 클러스터가 Amazon S3 데이터 및 기타 AWS 서비스와 상호 작용할 수 있는 권한을 정의하려면 클러스터를 시작할 때 `EMR_EC2_DefaultRole` 대신, 사용자 지정 Amazon EC2 인스턴스 프로파일을 정의합니다. 자세한 내용은 [클러스터 EC2 인스턴스에 대한 서비스 역할(EC2 인스턴스 프로파일)](emr-iam-role-for-ec2.md) 및 [Amazon EMR을 사용하여 IAM 역할 사용자 지정](emr-iam-roles-custom.md) 섹션을 참조하세요.
Amazon EMR이 세션에 태그를 지정하고 LDAP 인증서를 AWS Secrets Manager 저장하는에 액세스할 수 있도록 기본 EC2 인스턴스 프로파일에 다음 문을 추가합니다.
```
{
"Sid": "AllowAssumeOfRolesAndTagging",
"Effect": "Allow",
"Action": ["sts:TagSession", "sts:AssumeRole"],
"Resource": [
"arn:aws:iam::111122223333:role/LDAP_DATA_ACCESS_ROLE_NAME",
"arn:aws:iam::111122223333:role/LDAP_USER_ACCESS_ROLE_NAME"
]
},
{
"Sid": "AllowSecretsRetrieval",
"Effect": "Allow",
"Action": "secretsmanager:GetSecretValue",
"Resource": [
"arn:aws:secretsmanager:us-east-1:111122223333:secret:LDAP_SECRET_NAME*",
"arn:aws:secretsmanager:us-east-1:111122223333:secret:ADMIN_LDAP_SECRET_NAME*"
]
}
```
**참고**
Secrets Manager 권한을 설정할 때 보안 암호 이름 끝에 있는 와일드카드 `*` 문자를 입력하지 않으면 클러스터 요청이 실패합니다. 와일드카드는 보안 암호 버전을 나타냅니다.
AWS Secrets Manager 정책의 범위를 클러스터가 인스턴스를 프로비저닝하는 데 필요한 인증서로만 제한해야 합니다.
# LDAP 통합을 위한 Amazon EMR 보안 구성 생성
LDAP 통합을 사용하여 EMR 클러스터를 시작하기 전에 [Amazon EMR 콘솔 또는를 사용하여 보안 구성 생성 AWS CLI](emr-create-security-configuration.md)의 단계를 사용하여 클러스터에 대한 Amazon EMR 보안 구성을 생성합니다. Amazon EMR 콘솔 **보안 구성** 섹션의 `AuthenticationConfiguration` 아래 `LDAPConfiguration` 블록 또는 해당 필드에서 다음 구성을 완료합니다.
**`EnableLDAPAuthentication`**
콘솔 옵션: **인증 프로토콜: LDAP**
LDAP 통합을 사용하려면 콘솔에서 클러스터를 생성할 때 이 옵션을 `true`로 설정하거나 인증 프로토콜로 선택합니다. 기본적으로 Amazon EMR 콘솔에서 보안 구성을 생성할 때 `EnableLDAPAuthentication`은 `true`입니다.
**`LDAPServerURL`**
콘솔 옵션: **LDAP 서버 위치**
접두사 `ldaps://location_of_server`를 포함한 LDAP 서버의 위치.
**`BindCertificateARN`**
콘솔 옵션: **LDAP SSL 인증서**
LDAP 서버에서 사용하는 SSL 인증서에 서명하기 위한 인증서가 포함된 AWS Secrets Manager ARN입니다. LDAP 서버에 퍼블릭 인증 기관(CA)이 서명한 경우 빈 파일이 있는 AWS Secrets Manager ARN을 제공할 수 있습니다. Secrets Manager에서 인증서를 저장하는 방법에 대한 자세한 내용은 [에 TLS 인증서 저장 AWS Secrets Manager](emr-ranger-tls-certificates.md) 섹션을 참조하세요.
**`BindCredentialsARN`**
콘솔 옵션: **LDAP 서버 바인드 보안 인증**
LDAP 관리자 바인드 자격 증명이 포함된 AWS Secrets Manager ARN입니다. 보안 인증은 JSON 객체로 저장됩니다. 이 보안 암호에는 하나의 키-값 페어만 있으며, 이 페어에서 키는 사용자 이름, 값은 암호입니다. 예를 들어 `{"uid=admin,cn=People,dc=example,dc=com": "AdminPassword1"}`입니다. EMR 클러스터에 SSH 로그인을 활성화하지 않은 경우 이 필드는 선택 사항입니다. 많은 구성에서 Active Directory 인스턴스에는 SSSD가 사용자를 동기화할 수 있도록 바인드 보안 인증이 필요합니다.
**`LDAPAccessFilter`**
콘솔 옵션: **LDAP 액세스 필터**
LDAP 서버 내에서 인증할 수 있는 객체의 하위 세트를 지정합니다. 예를 들어, LDAP 서버의 `posixAccount` 객체 클래스를 사용하는 모든 사용자에게 액세스 권한을 부여하려는 경우 액세스 필터를 `(objectClass=posixAccount)`로 정의합니다.
**`LDAPUserSearchBase`**
콘솔 옵션: **LDAP 사용자 검색 기반**
LDAP 서버 내에서 사용자가 속해 있는 검색 기반. 예를 들어 `cn=People,dc=example,dc=com`입니다.
**`LDAPGroupSearchBase`**
콘솔 옵션: **LDAP 그룹 검색 기반**
LDAP 서버 내에서 그룹이 속하는 검색 기반. 예를 들어 `cn=Groups,dc=example,dc=com`입니다.
**`EnableSSHLogin`**
콘솔 옵션: **SSH 로그인**
LDAP 보안 인증에서 암호 인증의 허용 여부를 지정합니다. 이 옵션을 활성화하지 않는 것이 좋습니다. 키 페어가 EMR 클러스터에 대한 액세스를 허용하는 보다 안전한 경로입니다. 이 필드는 선택 사항으로, 기본값은 `false`입니다.
**`LDAPServerType`**
콘솔 옵션: **LDAP 서버 유형**
Amazon EMR이 연결하는 LDAP 서버의 유형을 지정합니다. 지원되는 옵션은 Active Directory 및 OpenLDAP입니다. 다른 LDAP 서버 유형도 작동할 수 있지만 Amazon EMR은 다른 서버 유형을 공식적으로 지원하지 않습니다. 자세한 내용은 [Amazon EMR의 LDAP 구성 요소](ldap-components.md) 단원을 참조하십시오.
**`ActiveDirectoryConfigurations`**
Active Directory 서버 유형을 사용하는 보안 구성에 필요한 하위 블록.
**`ADDomain`**
콘솔 옵션: **Active Directory 도메인**
Active Directory 서버 유형을 사용하는 보안 구성의 사용자 인증을 위한 사용자 보안 주체 이름(UPN)을 생성하는 데 사용되는 도메인 이름.
## LDAP 및 Amazon EMR에서 보안 구성에 대한 고려 사항
+ Amazon EMR LDAP 통합을 사용하여 보안 구성을 생성하려면 전송 중 암호화를 사용해야 합니다. 전송 중 암호화에 대한 자세한 내용은 [Amazon EMR에서 저장 데이터 및 전송 중 데이터 암호화](emr-data-encryption.md) 섹션을 참조하세요.
+ 동일한 보안 구성에서 Kerberos 구성을 정의할 수 없습니다. Amazon EMR은 자동으로 전용 KDC를 프로비저닝하고 이 KDC에 대한 관리 암호를 관리합니다. 사용자는 이 관리 암호에 액세스할 수 없습니다.
+ 동일한 보안 구성 AWS Lake Formation 에서 IAM 런타임 역할 및를 정의할 수 없습니다.
+ `LDAPServerURL`의 값에 `ldaps://` 프로토콜이 있어야 합니다.
+ `LDAPAccessFilter`는 비워둘 수 없습니다.
## Amazon EMR용 Apache Ranger 통합을 통해 LDAP 사용
Amazon EMR용 LDAP 통합을 통해 Apache Ranger와 추가로 통합할 수 있습니다. LDAP 사용자를 Ranger로 가져오면 해당 사용자를 Apache Ranger 정책 서버와 연결하여 Amazon EMR 및 기타 애플리케이션과 통합할 수 있습니다. 이렇게 하려면 LDAP 클러스터와 함께 사용하는 보안 구성의 `AuthorizationConfiguration` 내에서 `RangerConfiguration` 필드를 정의합니다. 보안 구성을 설정하는 방법에 대한 자세한 내용은 [EMR 보안 구성 생성](emr-ranger-security-config.md) 섹션을 참조하세요.
Amazon EMR과 함께 LDAP를 사용하는 경우, Apache Ranger에 대한 Amazon EMR 통합에 `KerberosConfiguration`을 제공할 필요가 없습니다.
# LDAP로 인증하는 EMR 클러스터 시작
다음 단계에 따라 LDAP 또는 Active Directory를 사용하여 EMR 클러스터를 시작합니다.
1. 환경을 설정합니다.
+ EMR 클러스터의 노드가 Amazon S3 및와 통신할 수 있는지 확인합니다 AWS Secrets Manager. 이러한 서비스와 통신하도록 EC2 인스턴스 프로파일 역할을 수정하는 방법에 대한 자세한 내용은 [Amazon EMR 인스턴스 역할에 AWS Secrets Manager 권한 추가](ldap-setup-asm.md) 섹션을 참조하세요.
+ 프라이빗 서브넷에서 EMR 클러스터를 실행하려는 경우 AWS PrivateLink 및 Amazon VPC 엔드포인트를 사용하거나 네트워크 주소 변환(NAT)을 사용하여 S3 및 Secrets Manager와 통신하도록 VPC를 구성해야 합니다. 자세한 내용은 *Amazon VPC 시작 안내서*에서 [AWS PrivateLink 및 VPC 엔드포인트](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html) 및 [NAT 인스턴스](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_NAT_Instance.html)를 참조하세요.
+ EMR 클러스터와 LDAP 서버 사이에 네트워크 연결이 있는지 확인합니다. EMR 클러스터는 네트워크를 통해 LDAP 서버에 액세스해야 합니다. 클러스터의 프라이머리, 코어 및 태스크 노드는 LDAP 서버와 통신하여 사용자 데이터를 동기화합니다. LDAP 서버가 Amazon EC2에서 실행되는 경우 EMR 클러스터의 트래픽을 수락하도록 EC2 보안 그룹을 업데이트합니다. 자세한 내용은 [Amazon EMR 인스턴스 역할에 AWS Secrets Manager 권한 추가](ldap-setup-asm.md) 단원을 참조하십시오.
1. LDAP 통합을 위한 Amazon EMR 보안 구성을 생성합니다. 자세한 내용은 [LDAP 통합을 위한 Amazon EMR 보안 구성 생성](ldap-setup-security.md) 단원을 참조하십시오.
1. 설정이 완료되었으니, [Amazon EMR 클러스터 시작](emr-gs.md#emr-getting-started-launch-sample-cluster)의 단계를 사용하여 다음 구성으로 클러스터를 시작합니다.
+ Amazon EMR 릴리스 6.12 이상을 선택합니다. 최신 Amazon EMR 릴리스를 사용하는 것이 좋습니다.
+ LDAP를 지원하는 클러스터 애플리케이션만 지정하거나 선택합니다. Amazon EMR을 사용하는 LDAP 지원 애플리케이션 목록은 [Amazon EMR용 LDAP의 애플리케이션 지원 및 고려 사항](ldap-considerations.md) 섹션을 참조하세요.
+ 이전 단계에서 생성한 보안 구성을 적용합니다.
# Amazon EMR과 함께 LDAP를 사용하는 예제
[LDAP 통합을 사용하는 EMR 클러스터를 프로비저닝](ldap-setup-launch.md)한 후에는 기본 제공 사용자 이름 및 암호 인증 메커니즘을 통해 [지원되는 애플리케이션](ldap-considerations.md#ldap-considerations-apps)에 LDAP 보안 인증을 제공할 수 있습니다. 이 페이지에는 몇 가지 예제가 나와 있습니다.
## Apache Hive에서 LDAP 인증 사용
**Example - Apache Hive**
다음 예제 명령은 HiveServer2와 Beeline을 통해 Apache Hive 세션을 시작합니다.
```
beeline -u "jdbc:hive2://$HOSTNAME:10000/default;ssl=true;sslTrustStore=$TRUSTSTORE_PATH;trustStorePassword=$TRUSTSTORE_PASS" -n LDAP_USERNAME -p LDAP_PASSWORD
```
## Apache Livy에서 LDAP 인증 사용
**Example - Apache Livy**
다음 예제 명령은 cURL을 통해 Livy 세션을 시작합니다. `ENCODED-KEYPAIR`를 `username:password`의 Base64로 인코딩된 문자열로 바꿉니다.
```
curl -X POST --data '{"proxyUser":"LDAP_USERNAME","kind": "pyspark"}' -H "Content-Type: application/json" -H "Authorization: Basic ENCODED-KEYPAIR" DNS_OF_PRIMARY_NODE:8998/sessions
```
## Presto에서 LDAP 인증을 Presto에 사용
**Example - Presto**
다음 예제 명령은 Presto CLI를 통해 Presto 세션을 시작합니다.
```
presto-cli --user "LDAP_USERNAME" --password --catalog hive
```
이 명령을 실행한 후 프롬프트에 LDAP 암호를 입력합니다.
## Trino에서 LDAP 인증 사용
**Example - Trino**
다음 예제 명령은 Trino CLI를 통해 Trino 세션을 시작합니다.
```
trino-cli --user "LDAP_USERNAME" --password --catalog hive
```
이 명령을 실행한 후 프롬프트에 LDAP 암호를 입력합니다.
## Hue에서 LDAP 인증 사용
클러스터에서 생성한 SSH 터널을 통해 Hue UI에 액세스하거나 Hue에 대한 연결을 퍼블릭 브로드캐스트하도록 프록시 서버를 설정할 수 있습니다. Hue는 기본적으로 HTTPS 모드에서 실행되지 않으므로 추가 암호화 계층을 사용하여 클라이언트와 Hue UI 간 통신이 HTTPS로 암호화되도록 하는 것이 좋습니다. 이렇게 하면 실수로 사용자 보안 인증이 일반 텍스트로 노출될 가능성이 줄어듭니다.
Hue UI를 사용하려면 브라우저에서 Hue UI를 열고 LDAP 사용자 이름 암호를 입력하여 로그인합니다. 보안 인증이 올바르면 Hue는 사용자를 로그인하고 사용자 자격 증명을 사용하여 지원되는 모든 애플리케이션에서 사용자를 인증합니다.
## 다른 애플리케이션의 경우 Kerberos 티켓 및 암호 인증에 SSH 사용
**중요**
암호 인증을 사용하여 EMR 클러스터에 SSH로 연결하는 것은 권장되지 않습니다.
LDAP 보안 인증을 사용하여 EMR 클러스터에 SSH로 연결할 수 있습니다. 이렇게 하려면 클러스터를 시작하는 데 사용하는 Amazon EMR 보안 구성에서 `EnableSSHLogin` 구성을 `true`로 설정합니다. 그런 다음 클러스터가 시작된 후 다음 명령을 사용하여 클러스터에 SSH로 연결합니다.
```
ssh username@EMR_PRIMARY_DNS_NAME
```
이 명령을 실행한 후 프롬프트에 LDAP 암호를 입력합니다.
Amazon EMR에는 사용자가 Kerberos keytab 파일 및 티켓을 생성하여 LDAP 보안 인증을 직접 수락하지 않는 지원되는 애플리케이션에 사용할 수 있는 클러스터 내 스크립트가 포함되어 있습니다. 이러한 애플리케이션 중에는 `spark-submit`, Spark SQL 및 PySpark가 포함됩니다.
`ldap-kinit`를 실행하고 프롬프트를 따릅니다. 인증에 성공하면 Kerberos keytab 파일이 유효한 Kerberos 티켓과 함께 홈 디렉터리에 나타납니다. Kerberos 티켓을 사용하면 다른 Kerberos 지원 환경에서처럼 애플리케이션을 실행할 수 있습니다.