

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# Amazon EMR を使用した Kerberos アーキテクチャオプション
<a name="emr-kerberos-options"></a>

Amazon EMR で Kerberos を使用する場合、このセクションに記載されているアーキテクチャから選択できます。選択したアーキテクチャに関係なく、同じ手順を使用して Kerberos を設定します。セキュリティ設定を作成し、セキュリティ設定を指定して、クラスターを作成する場合には互換性のあるクラスターに対応する Kerberos オプションを指定します。また、KDC のユーザープリンシパルに一致するクラスターで Linux 用の HDFS ディレクトリを作成します。設定オプションおよび各アーキテクチャの設定例については、「[Amazon EMR での Kerberos の設定](emr-kerberos-configure.md)」を参照してください。

## クラスター専用 KDC (プライマリノードでの KDC)
<a name="emr-kerberos-localkdc-summary"></a>

この設定は、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` 認証情報を使用する必要があります。

## クロス領域信頼
<a name="emr-kerberos-crossrealm-summary"></a>

この設定では、別の 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
<a name="emr-kerberos-extkdc-summary"></a>

外部の 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
<a name="emr-kerberos-extkdc-mit-summary"></a>

この設定によって、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 – 別のクラスターのプライマリノード
<a name="emr-kerberos-extkdc-cluster-summary"></a>

この設定は、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
<a name="emr-kerberos-extkdc-ad-trust-summary"></a>

この設定ではまず、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 で複数のクラスターを使用するための要件
<a name="emr-kerberos-multi-kdc"></a>

複数のクラスターは、同じ Kerberos 領域の同じ KDC を使用できます。ただし、複数のクラスターが同時に実行されている場合、それらのクラスターで競合する Kerberos ServicePrincipal 名が使用されていると、クラスターで問題が発生する可能性があります。

同じ外部 KDC を持つ複数の同時クラスターがある場合は、それらのクラスターで異なる Kerberos 領域が使用されていることを確認してください。これらのクラスターで同じ Kerberos 領域を使用する必要がある場合は、クラスターが異なるサブネット内にあり、CIDR 範囲が重複していないことを確認してください。