翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 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)」を参照してください。