翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon EMR クラスターノードへのアクセス認証
SSH クライアントは、クラスターインスタンスへのアクセス認証に Amazon EC2 キーペアを使用します。または、Amazon EMR リリース 5.10.0 以降では、Kerberos を設定してユーザーおよびプライマリノードへの SSH 接続を認証することができます。また、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 ユーザーガイド*」の「[Converting your private key using PuTTYgen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/putty.html#putty-private-key)」を参照してください。
+ .pem ファイルのアクセス許可の設定と、Linux または macOS、Windows `ssh`の PuTTY、 AWS CLI サポートされているオペレーティングシステムの など、さまざまな方法を使用して EMR クラスターのプライマリノードに接続する方法の詳細については、「」を参照してください[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 を設定する前に、KDC で実行される Kerberos サービスの概念、および Kerberos サービスの管理ツールに慣れておくことをお勧めします。詳細については、[Kerberos Consortium](http://web.mit.edu/kerberos/krb5-latest/doc/) によって発行されている [MIT Kerberos ドキュメント](http://kerberos.org/)を参照してください。
**Topics**
+ [Amazon EMR でサポートされているアプリケーション](emr-kerberos-principals.md)
+ [Amazon EMR を使用した Kerberos アーキテクチャオプション](emr-kerberos-options.md)
+ [Amazon EMR での Kerberos の設定](emr-kerberos-configure.md)
+ [Amazon EMR で SSH を使用して 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) の認証が設定されていません。Hue UI には LDAP 認証を設定できます。
+ **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 は、必ず Kerberos と Spark インタプリタを一緒に使用することを目的として設定されています。他のインタプリタには設定されません。
+ Spark 以外の Kerberos 認証済み 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/ja_jp/emr/latest/ManagementGuide/images/kerb-cluster-dedicated-kdc.png)
**利点**
+ Amazon EMR には KDC の完全な所有権があります。
+ EMR クラスターの KDC は、 AWS Managed Microsoft ADの Microsoft Active Directory などの一元化された KDC 実装からは独立したものです。
+ KDC はクラスター内のローカルノードのみの認証を管理するため、パフォーマンスへの影響は最小限に抑えられます。
+ 必要に応じて、Kerberos 認証済みの他のクラスターは KDC を外部の KDC として参照できます。詳細については、「[外部 KDC – 別のクラスターのプライマリノード](#emr-kerberos-extkdc-cluster-summary)」を参照してください。
**考慮事項と制限事項**
+ Kerberos 認証済みクラスターは相互に認証できないため、アプリケーションを相互運用することはできません。クラスターのアプリケーションを相互運用する場合には、クラスター間でクロス領域信頼を確立するか、または 1 つのクラスターを他のクラスターの外部 KDC をして設定する必要があります。クロス領域信頼が確立された場合、KDC には 異なる Kerberos 領域がある必要があります。
+ KDC ユーザープリンシパルに対応するプライマリノードの EC2 インスタンス上で Linux ユーザーを作成し、各ユーザー用の HDFS ディレクトリを作成する必要があります。
+ ユーザープリンシパルは、SSH を使用してクラスターに接続するために、EC2 プライベートキーファイルおよび `kinit` 認証情報を使用する必要があります。
## クロス領域信頼
この設定では、別の 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/ja_jp/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
この設定によって、1 つ以上の EMR クラスターが MIT KDC サーバーで定義されて維持されるプリンシパルを使用することが許可されます。
![\[Amazon EMRクラスター architecture with Kerberos realm, showing master, core, and task nodes.\]](http://docs.aws.amazon.com/ja_jp/emr/latest/ManagementGuide/images/kerb-external-kdc.png)
**利点**
+ プリンシパルの管理は単一の KDC に統合されています。
+ 複数のクラスターは、同じ Kerberos 領域の同じ KDC を使用できます。詳細については、「[同じ KDC で複数のクラスターを使用するための要件](#emr-kerberos-multi-kdc)」を参照してください。
+ Kerberos 認証済みクラスターのプライマリノードには、KDC の維持に関連するパフォーマンスの負担はありません。
**考慮事項と制限事項**
+ 各 Kerberos 認証済みクラスターのプライマリノード (KDC ユーザープリンシパルに対応するもの) の EC2 インスタンス上で Linux ユーザーを作成し、各ユーザー用の HDFS ディレクトリを作成する必要があります。
+ ユーザープリンシパルは、SSH を使用して Kerberos 認証済みのクラスターに接続するために、EC2 プライベートキーファイルおよび `kinit` 認証情報を使用する必要があります。
+ 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/ja_jp/emr/latest/ManagementGuide/images/kerb-external-cluster-kdc.png)
**利点**
+ プリンシパルの管理は単一の KDC に統合されています。
+ 複数のクラスターは、同じ Kerberos 領域の同じ KDC を使用できます。詳細については、「[同じ KDC で複数のクラスターを使用するための要件](#emr-kerberos-multi-kdc)」を参照してください。
**考慮事項と制限事項**
+ 各 Kerberos 認証済みクラスターのプライマリノード (KDC ユーザープリンシパルに対応するもの) の EC2 インスタンス上で Linux ユーザーを作成し、各ユーザー用の HDFS ディレクトリを作成する必要があります。
+ ユーザープリンシパルは、SSH を使用して Kerberos 認証済みのクラスターに接続するために、EC2 プライベートキーファイルおよび `kinit` 認証情報を使用する必要があります。
+ 各 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/ja_jp/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 認証済みクラスターにアクセスできます。これにより、クラスターユーザー間でプライベートキーを共有する必要がなくなります。
+ KDC の維持を負担するのは 1 つの Amazon EMR プライマリノードだけであり、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 を使用する、あるいはクロス領域信頼を設定する場合には、クラスターのすべてのノードに外部の KDC へのネットワークルートがあること (インバウンドおよびアウトバウンドの Kerberos トラフィックを許可する適用されるセキュリティグループの設定など) を確認する必要があります。
## ステップ 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 認証済みのユーザーからの接続を許可するように、SSH は GSSAPI を有効にして設定する必要があります。GSSAPI がプライマリノードで有効にされている必要があり、クライアントの SSH アプリケーションが GSSAPI を使用するように設定されている必要があります。詳細については、「[Kerberos 認証済み HDFS ユーザーと SSH 接続向け Amazon EMR クラスターの設定](emr-kerberos-configuration-users.md)」を参照してください。
# Amazon EMR 上の Kerberos のセキュリティ設定およびクラスター設定
Kerberos 認証済みのクラスターを作成する場合、セキュリティ設定と合わせて、クラスター固有の Kerberos 属性を指定します。必ず、他の属性と一緒に指定します。それ以外の場合はエラーが発生します。
このトピックでは、セキュリティ設定およびクラスターを作成するときに、Kerberos で利用できる設定パラメータの概要を示します。また、互換性のあるセキュリティ設定およびクラスター作成用の CLI 例は、一般的なアーキテクチャ向けに提供されています。
## セキュリティ設定における Kerberos セキュリティ
Amazon EMR コンソール、、または EMR API を使用して AWS CLI、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/ja_jp/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)」を参照してください。
| パラメータ | 説明 |
| --- | --- |
| 領域 | クラスターの Kerberos 領域名。Kerberos の規則では、ドメイン名と同じ名前に設定する必要がありますが、大文字にします。たとえば、ドメイン (`ec2.internal`) の場合は、領域名に `EC2.INTERNAL` を使用します。 |
| KDC 管理者パスワード | `kadmin` または `kadmin.local` 向けにクラスター内で使用されるパスワード。以下は、Kerberos V5 管理システムのコマンドラインインターフェイスです。Kerberos プリンシパル、パスワードポリシー、クラスターのキータブを管理できます。 |
| クロス領域信頼プリンシパルのパスワード (オプション) | クロス領域信頼の確立時に必要。クロス領域プリンシパルのパスワード。領域内では同一である必要があります。強力なパスワードを選択します。 |
| Active Directory ドメイン結合ユーザー (オプション) | クロス領域信頼で Active Directory を使用するときに必要です。これは、コンピュータをドメインに結合するアクセス許可がある Active Directory アカウントのユーザーログオン名です。Amazon EMR は、この識別子を使用して、クラスターをドメインに結合します。詳細については、「[ステップ 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)」を参照してください。 |
# 設定例
以下の例は、一般的なシナリオのセキュリティ設定とクラスター設定を示しています。簡潔にするために AWS CLI 、 コマンドを示しています。
## ローカル 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 を使用してクロス領域信頼を確立することをお勧めします。または、Linux アカウントを使用して SSH 接続用のユーザーを作成する場合は、ブートストラップアクションとスクリプトを使用してアカウント作成プロセスを自動化して、新しいクラスターを作成するときに繰り返すことができるようにします。
ユーザーおよび 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
```
# Amazon EMR で SSH を使用して Kerberos 認証済みのクラスターに接続する
このセクションでは、Kerberos 認証済みユーザーが EMR クラスターのプライマリノードに接続するためのステップを示しています。
SSH 接続のために使用する各コンピューターには、SSH クライアントおよび Kerberos クライアントアプリケーションがインストールされている必要があります。ほとんどの Linux コンピューターにはデフォルトでこれがあります。たとえば、ほとんどの Linux、Unix、および Mac OS オペレーティングシステムには OpenSSH がインストールされています。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 は GSSAPI を使用して Kerberos クライアントを認証するため、クラスターのプライマリノードで 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. `ssh` クライアントをクラスター専用 KDC で作成したプリンシパルあるいは Active Directory ユーザー名と共に使用します。次の例に示すように、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/ja_jp/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`) が参照されます。また、ブートストラップアクションとして、クラスターを作成する前に作成し、Amazon S3 にアップロードしたシンプルなスクリプト (`createlinuxusers.sh`) も参照されます。
```
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 ディレクトリを作成します。同様に、SSH サービスを設定し、GSSAPI 認証を有効にします。Kerberos で必要になります。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 を使用してクラスターに接続できるようになります。詳細については、「[Amazon EMR で SSH を使用して Kerberos 認証済みのクラスターに接続する](emr-kerberos-connect-ssh.md)」を参照してください。
# チュートリアル: Active Directory ドメインを使用したクロス領域信頼の設定
クロス領域信頼をセットアップする際、別の Kerberos 領域のプリンシパル (通常はユーザー) が、EMR クラスターのアプリケーションコンポーネントを認証できるようにします。クラスター専用 *KDC (キー配布センター)* は、両方の KDC に存在する*クロス領域のプリンシパル*を使用して、他の KDC で信頼関係を確立します。プリンシパル名とパスワードが正確に一致しています。
クロス領域信頼では、KDC がネットワーク経由で相互に到達し、相互のドメイン名を解決できる必要があります。以下に、必要な接続とドメイン名の解決を行うネットワークステップの例と合わせて、EC2 インスタンスとして実行されている Microsoft AD ドメインコントローラーを使用してクロス領域の信頼関係を確立するステップを示します。KDC 間の必要なネットワークトラフィックを許可するすべてのネットワークのセットアップは許容範囲内です。
必要に応じて、1 つのクラスター上で 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 オプションセットを使用して VPC DNS サーバーとして Active Directory ドメインコントローラーを指定する](#emr-kerberos-ad-DHCP)
[ステップ 6: Kerberos 認証済みの EMR クラスターを起動する](#emr-kerberos-ad-cluster)
[ステップ 7: HDFS ユーザーを作成して、Active Directory アカウントのクラスターに対するアクセス許可を設定する](#emr-kerberos-ad-hadoopuser)
## ステップ 1: VPC とサブネットをセットアップする
クラスター専用 KDC が Active Directory ドメインコントローラーに到達し、ドメイン名を解決できるように、VPC およびサブネットの作成手順を以下に示します。これらのステップでは、DHCP オプションセットのドメイン名サーバーとして Active Directory ドメインコントローラーを参照し、ドメイン名を解決します。詳細については、「[ステップ 5: DHCP オプションセットを使用して VPC DNS サーバーとして Active Directory ドメインコントローラーを指定する](#emr-kerberos-ad-DHCP)」を参照してください。
KDC と Active Directory ドメインコントローラーは、相互のドメイン名を解決できる必要があります。これにより、Amazon EMR はコンピュータをドメインに参加させ、クラスターインスタンス上で対応する Linux アカウントおよび SSH パラメータを自動的に設定することができます。
Amazon EMR でドメイン名を解決できない場合は、Active Directory ドメインコントローラーの IP アドレスを使用して信頼を参照できます。ただし、Linux アカウントの追加、クラスター専用 KDC への対応するプリンシパルの追加、SSH の設定は手動で行う必要があります。
**VPC とサブネットをセットアップするには**
1. 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 名が使用されるためです。 は IPv4 アドレスに基づいて [DNS ホスト名](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-hostnames)を AWS 割り当てます。これにより、IP アドレスが長くなると、DNS 名が 15 文字を超える可能性があります。Active Directory には、結合されるコンピュータ名の登録に 15 文字の制限があるため、長い場合は切り捨てられます。これが原因で、予測できないエラーが発生することがあります。
1. VPC に割り当てられているデフォルトの DHCP オプションセットを削除します。詳細については、「[DHCP オプションを使用しないように VPC を変更する](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html#DHCP_Use_No_Options)」を参照してください。Active Directory ドメインコントローラーを DNS サーバーとして指定する新しい設定を後で追加します。
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 インスタンスを起動する場合は、静的なパブリック IPv4 アドレスを使用して RDP で接続する必要があります。これを行う最も簡単な方法は、サブネットを自動割り当てパブリック IPv4 アドレスに設定することです。サブネットを作成する際、これはデフォルトで設定されていません。詳細については、「[サブネットのパブリック IPv4 アドレス属性を変更する](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 Base の 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 ユーザーガイド*」の「[EC2 インスタンスの 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 ドメインサービスの役割をインストールして設定するには、**[Server Manager]** (サーバー マネージャ) を起動します。サーバーをドメインコントローラーに昇格させ、ドメイン名 (ここでは `ad.domain.com`) を割り当てます。後に EMR セキュリティ設定およびクラスターを作成する際に必要になるため、ドメイン名を書きとめておきます。Active Directory を初めてセットアップする場合は、「[How to set up Active Directory (AD) in Windows Server 2016](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)」を参照してください。各ユーザーの [**User logon name (ユーザーのログオン名)**] を書きとめておきます。これらは、後にクラスターを構成する際に必要になります。
さらに、コンピュータをドメインに参加させるのに十分な権限を持つユーザーアカウントを作成します。クラスターを作成する際、このアカウントを指定します。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` パラメータでは、[**cross-realm principal password (クロス領域プリンシパルのパスワード)**] を指定します。このパスワードは、クラスター作成時に、クラスターの [**realm (領域)**] と合わせて指定したものです。この領域名は、クラスターの `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 オプションセットを使用して VPC DNS サーバーとして Active Directory ドメインコントローラーを指定する
これで、Active Directory ドメインコントローラーが設定されたため、VPC 内で名前解決できるように、VPC を設定してドメイン名サーバーとして使用する必要があります。これを行うには、DHCP オプションセットをアタッチします。**[Domain name]** (ドメイン名) をクラスターのドメイン名に指定します (例: クラスターが us-east-1 にある場合は `ec2.internal`、他のリージョンにある場合は `region.compute.internal`)。[**Domain name servers (ドメインネームサーバー)**] で、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` オプションを使用して、作成したセキュリティ設定を指定します。この例では *MyKerberos Config* を使用します。
+ `--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 ドメインコントローラーの設定時に指定したクラスターの領域。
+ 「[ステップ 4: Active Directory ドメインコントローラーで受信の信頼を設定する](#emr-kerberos-ad-configure-trust)」で `passwordt` として指定したクロス領域信頼プリンシパルのパスワード。
+ `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: HDFS ユーザーを作成して、Active Directory アカウントのクラスターに対するアクセス許可を設定する
Active Directory で信頼関係を設定すると、Amazon EMR は各 Active Directory アカウントのクラスターで Linux ユーザーを作成します。例えば、Active Directory のユーザーログオン名が `LiJuan` の場合、Linux アカウントは `lijuan` になります。Active Directory のユーザー名には、大文字を含めることができますが、Linux では Active Directory のこの区別は採用されません。
ユーザーがクラスターにログインして Hadoop ジョブを実行できるようにするには、Linux アカウント向けに HDFS ユーザーディレクトリを追加し、そのディレクトリの所有権を各ユーザーに付与します。そのためには、Amazon S3 に保存されているスクリプトをクラスターのステップとして実行することをお勧めします。あるいは、以下のスクリプトのコマンドをプライマリノードのコマンドラインから実行することもできます。Hadoop ユーザーとして SSH 経由でプライマリノードに接続するには、クラスターの作成時に指定した EC2 キーペアを使用します。詳細については、「[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 では、System Security Services Daemon (SSD) を使用して、Active Directory グループを Hadoop グループにマッピングします。グループマッピングを確認するには、「[Amazon EMR で SSH を使用して Kerberos 認証済みのクラスターに接続する](emr-kerberos-connect-ssh.md)」の説明に従ってプライマリノードにログインした後、`hdfs groups` コマンドを使用して、Active Directory アカウントが属する Active Directory グループが、クラスター上の対応する Hadoop ユーザーの Hadoop グループにマッピングされていることを確認します。また、他のユーザーのグループマッピングを確認するには、同コマンドを使用してユーザー名を 1 つ以上指定します (例: `hdfs groups lijuan`)。詳細については、「[Apache HDFS コマンドガイド](https://hadoop.apache.org/docs/r2.7.1/hadoop-project-dist/hadoop-hdfs/HDFSCommands.html#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 サーバーとネイティブに統合されるクラスターを起動できます。LDAP (Lightweight Directory Access Protocol) は、データにアクセスして管理する、ベンダーに依存しないオープンなアプリケーションプロトコルです。LDAP は一般的に、Active Directory (AD) や OpenLDAP などのアプリケーションでホストされている企業 ID サーバーに対するユーザー認証に使用されます。このネイティブ統合により、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** という 2 つの主要な実装があります。他の実装も可能ですが、ほとんどが 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 コンポーネント
以下のコンポーネントを通じて、Amazon EMR およびユーザーが EMR クラスターで直接使用する任意のアプリケーションでの認証に LDAP サーバーを使用することができます。
**シークレットエージェント**
*シークレットエージェント*は、すべてのユーザーリクエストを認証するクラスター上のプロセスです。シークレットエージェントは、EMR クラスター上のサポート対象のアプリケーションに代わって、LDAP サーバーへのユーザーバインドを作成します。シークレットエージェントは `emrsecretagent` ユーザーとして実行され、`/emr/secretagent/log` ディレクトリにログを書き込みます。これらのログには、各ユーザーの認証リクエストの状態や、ユーザー認証中に発生する可能性のあるエラーに関する詳細が記録されます。
**System Security Services Daemon (SSSD)**
*SSSD* は LDAP 対応 EMR クラスターの各ノードで実行されるデーモンです。SSSD は UNIX ユーザーを作成して管理し、リモートの企業 ID を各ノードに同期させます。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 でサポートされている機能
LDAP 統合では、次の Amazon EMR 機能を使用できます。
**注記**
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)」を参照してください。
次のステートメントをデフォルトの EC2 インスタンスプロファイルに追加して、Amazon EMR がセッションにタグを付け、LDAP 証明書 AWS Secrets Manager を保存する にアクセスできるようにします。
```
{
"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 セキュリティ設定を作成します。`AuthenticationConfiguration` の下の `LDAPConfiguration` ブロック、または Amazon EMR コンソールの **[セキュリティ設定]** セクションの対応するフィールドで、以下の設定を完了します。
**`EnableLDAPAuthentication`**
コンソールオプション: **認証プロトコル: LDAP**
LDAP 統合を使用するには、このオプションを `true` に設定するか、コンソールでクラスターを作成するときに認証プロトコルとして選択します。Amazon EMR コンソールでセキュリティ設定を作成する場合、デフォルトでは `EnableLDAPAuthentication` は `true` です。
**`LDAPServerURL`**
コンソールオプション: **LDAP サーバーの場所**
LDAP サーバーの場所 (プレフィックスを含む): `ldaps://location_of_server`
**`BindCertificateARN`**
コンソールオプション: **LDAP SSL 証明書**
LDAP サーバーが使用する SSL 証明書に署名するための証明書を含む AWS Secrets Manager ARN。LDAP サーバーがパブリック認証局 (CA) によって署名されている場合は、ARN AWS Secrets Manager に空のファイルを提供できます。Secrets Manager に証明書を保存する方法の詳細については、「[に TLS 証明書を保存する AWS Secrets Manager](emr-ranger-tls-certificates.md)」を参照してください。
**`BindCredentialsARN`**
コンソールオプション: **LDAP サーバーバインド認証情報**
LDAP 管理者ユーザーのバインド認証情報を含む AWS Secrets Manager ARN。認証情報は JSON オブジェクトとして保存されます。このシークレットにはキーと値のペアが 1 つしかありません。ペアのキーはユーザー名で、値はパスワードです。例えば、`{"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 の管理者パスワードを管理します。ユーザーはこの管理者パスワードにアクセスできません。
+ IAM ランタイムロール と を同じセキュリティ設定 AWS Lake Formation で定義することはできません。
+ `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 認証の使用
**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 はユーザーをログインさせ、サポート対象のすべてのアプリケーションで ID を使用してユーザーを認証します。
## パスワード認証には SSH を使用し、他のアプリケーションには Kerberos チケットを使用する
**重要**
EMR クラスターへの SSH 接続でパスワード認証を使用することは推奨されません。
LDAP 認証情報を使用して EMR クラスターに SSH 接続できます。これを行うには、クラスターの起動に使用する Amazon EMR セキュリティ設定で `EnableSSHLogin` 設定を `true` に設定します。次に、起動したら次のコマンドを使用して、クラスターに SSH 接続します。
```
ssh username@EMR_PRIMARY_DNS_NAME
```
このコマンドを実行した後、プロンプトに LDAP パスワードを入力します。
Amazon EMR には、LDAP 認証情報を直接受け付けないサポート対象のアプリケーションで使用する Kerberos キータブファイルとチケットをユーザーが生成できる、クラスター上で使用するスクリプトが含まれています。これらのアプリケーションには、`spark-submit`、Spark SQL、PySpark などがあります。
「`ldap-kinit`」と入力し、プロンプトに従います。認証が成功すると、Kerberos キータブファイルと有効な Kerberos チケットがホームディレクトリに表示されます。Kerberos チケットを使用すると、他の Kerberos 環境と同様にアプリケーションを実行できます。