Amazon EMR を使用した Kerberos アーキテクチャオプション

利点

• Amazon EMR には KDC の完全な所有権があります。

• EMR クラスターの KDC は、AWS Managed Microsoft AD の Microsoft Active Directory などの一元化された KDC 実装からは独立したものです。

• KDC はクラスター内のローカルノードのみの認証を管理するため、パフォーマンスへの影響は最小限に抑えられます。

• 必要に応じて、Kerberos 認証済みの他のクラスターは KDC を外部の KDC として参照できます。詳細については、「外部 KDC – 別のクラスターのプライマリノード」を参照してください。

考慮事項と制限事項

• Kerberos 認証済みクラスターは相互に認証できないため、アプリケーションを相互運用することはできません。クラスターのアプリケーションを相互運用する場合には、クラスター間でクロス領域信頼を確立するか、または 1 つのクラスターを他のクラスターの外部 KDC をして設定する必要があります。クロス領域信頼が確立された場合、KDC には 異なる Kerberos 領域がある必要があります。

• KDC ユーザープリンシパルに対応するプライマリノードの EC2 インスタンス上で Linux ユーザーを作成し、各ユーザー用の HDFS ディレクトリを作成する必要があります。

• ユーザープリンシパルは、SSH を使用してクラスターに接続するために、EC2 プライベートキーファイルおよび kinit 認証情報を使用する必要があります。

利点

• 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 - MIT KDC

• 外部 KDC – 別のクラスターのプライマリノード

• 外部 KDC - Active Directory クロス領域信頼を使用した別のクラスター上のクラスター KDC

利点

• プリンシパルの管理は単一の KDC に統合されています。

• 複数のクラスターは、同じ Kerberos 領域の同じ KDC を使用できます。詳細については、「同じ KDC で複数のクラスターを使用するための要件」を参照してください。

• Kerberos 認証済みクラスターのプライマリノードには、KDC の維持に関連するパフォーマンスの負担はありません。

考慮事項と制限事項

• 各 Kerberos 認証済みクラスターのプライマリノード (KDC ユーザープリンシパルに対応するもの) の EC2 インスタンス上で Linux ユーザーを作成し、各ユーザー用の HDFS ディレクトリを作成する必要があります。

• ユーザープリンシパルは、SSH を使用して Kerberos 認証済みのクラスターに接続するために、EC2 プライベートキーファイルおよび kinit 認証情報を使用する必要があります。

• Kerberos 認証済みの EMR クラスター内の各ノードには、KDC へのネットワークルートがあることが必要です。

• Kerberos 認証済みのクラスターの各ノードは、KDC の設定がクラスターのパフォーマンスに影響を及ぼすように、外部 KDC に認証情報の負担を設置します。KDC サーバーのハードウェアを設定する際に、同時にサポートする Amazon EMR ノードの最大数を考慮してください。

• クラスターのパフォーマンスは、Kerberos 認証済みのクラスターと KDC のノード間のネットワークにおけるレイテンシーに応じます。

• 相互依存関係のため、トラブルシューティングはより困難になることがあります。

利点

• プリンシパルの管理は単一の KDC に統合されています。

• 複数のクラスターは、同じ Kerberos 領域の同じ KDC を使用できます。詳細については、「同じ KDC で複数のクラスターを使用するための要件」を参照してください。

考慮事項と制限事項

• 各 Kerberos 認証済みクラスターのプライマリノード (KDC ユーザープリンシパルに対応するもの) の EC2 インスタンス上で Linux ユーザーを作成し、各ユーザー用の HDFS ディレクトリを作成する必要があります。

• ユーザープリンシパルは、SSH を使用して Kerberos 認証済みのクラスターに接続するために、EC2 プライベートキーファイルおよび kinit 認証情報を使用する必要があります。

• 各 EMR クラスター内の各ノードには、KDC へのネットワークルートがあることが必要です。

• Kerberos 認証済みのクラスターの各 Amazon EMR ノードは、KDC の設定がクラスターのパフォーマンスに影響を及ぼすように、外部 KDC に認証情報の負担を設置します。KDC サーバーのハードウェアを設定する際に、同時にサポートする Amazon EMR ノードの最大数を考慮してください。

• クラスターのパフォーマンスは、クラスターと KDC のノード間のネットワークにおけるレイテンシーに応じます。

• 相互依存関係のため、トラブルシューティングはより困難になることがあります。

利点

• プリンシパルの管理は Active Directory ドメインに統合されています。

• Amazon EMR は Active Directory 領域を結合するため、Active Directory ユーザーに対応する Linux ユーザーを作成する必要がなくなります。ただし、各ユーザーに HDFS ディレクトリも作成する必要があります。

• 複数のクラスターは、同じ Kerberos 領域の同じ KDC を使用できます。詳細については、「同じ 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 サーバーのノード間のネットワークにおけるレイテンシーに応じます。

• 相互依存関係のため、トラブルシューティングはより困難になることがあります。