Kerberos アーキテクチャオプション

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

クラスター専用 KDC (KDCプライマリノード）

この設定は、Amazon EMRリリース 5.10.0 以降で使用できます。

利点

• Amazon EMRは の完全な所有権を持っていますKDC。

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

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

• オプションで、他の Kerberized クラスターは を外部 KDCとして参照できますKDC。詳細については、「外部 KDC— 別のクラスターのプライマリノード」を参照してください。

考慮事項と制約事項

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

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

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

クロス領域信頼

この設定では、別の Kerberos 領域からのプリンシパル (通常はユーザー) が、独自の を持つ Kerberized EMRクラスター上のアプリケーションコンポーネントに対して認証しますKDC。プライマリノードKDCの は、両方の に存在するクロス領域プリンシパルKDCを使用して、別の との信頼関係を確立しますKDCs。プリンシパル名とパスワードは、各 で正確に一致しますKDC。次の図で示すように、クロス領域信頼は最も一般的な Active Directory の実装です。外部MITKDCまたは別の Amazon EMRクラスターKDC上の とのクロス領域信頼もサポートされています。

利点

• がインストールされているEMRクラスターKDCは、 の完全な所有権を維持しますKDC。

• Active Directory を使用すると、Amazon は からユーザープリンシパルに対応する Linux ユーザーEMRを自動的に作成しますKDC。それでも、ユーザーごとにHDFSディレクトリを作成する必要があります。さらに、Active Directory ドメインのユーザープリンシパルは、EC2プライベートキーファイルを使用せずに、kinit認証情報を使用して Kerberized クラスターにアクセスできます。これにより、クラスターユーザー間でプライベートキーを共有する必要がなくなります。

• 各クラスターはクラスター内のノードの認証KDCを管理するため、クラスター全体の多数のノードに対するネットワークレイテンシーと処理オーバーヘッドの影響は最小限に抑えられます。

考慮事項と制約事項

• Active Directory 領域を使用して信頼性を確立する場合、クラスター作成時に、ドメインにプリンシパルを結合する許可がある Active Directory のユーザー名とパスワードを提供する必要があります。

• クロス領域信頼を同名の Kerberos 領域間に確立することはできません。

• クロス領域信頼は明示的に確立する必要があります。例えば、クラスター A とクラスター B の両方が とのクロス領域信頼を確立した場合KDC、それらは本質的に相互に信頼せず、それらのアプリケーションは相互運用のために相互に認証できません。

• KDCs は、ユーザープリンシパルの認証情報が正確に一致するように、個別に維持し、調整する必要があります。

外部 KDC

External を使用した設定KDCは、Amazon 5.20.0 EMR 以降でサポートされています。

• 外部 KDC—MIT KDC

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

• 外部 KDC— Active Directory クロス領域信頼を持つ別のクラスターKDC上のクラスター

外部 KDC—MIT KDC

この設定により、1 つ以上のEMRクラスターで、 MITKDCサーバーで定義および保守されているプリンシパルを使用できます。

利点

• プリンシパルの管理は 1 つの に統合されますKDC。

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

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

考慮事項と制約事項

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

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

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

• Kerberized クラスターの各ノードは、外部 に認証の負担をかけるためKDC、 の設定はクラスターのパフォーマンスKDCに影響します。KDC サーバーのハードウェアを設定するときは、同時にサポートされる Amazon EMRノードの最大数を考慮してください。

• クラスターのパフォーマンスは、Kerberized クラスター内のノードと 間のネットワークレイテンシーによって異なりますKDC。

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

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

この設定は、 が EMRクラスターのプライマリノードにあることを除いて、上記の外部MITKDC実装とほぼ同じKDCです。詳細については、「クラスター専用 KDC (KDCプライマリノード）」および「チュートリアル: Active Directory ドメインを使用したクロス領域信頼の設定」を参照してください。

利点

• プリンシパルの管理は 1 つの に統合されますKDC。

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

考慮事項と制約事項

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

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

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

• Kerberized クラスターの各 Amazon EMRノードは、外部 に認証の負担をかけるためKDC、 の設定はクラスターのパフォーマンスKDCに影響します。KDC サーバーのハードウェアを設定するときは、同時にサポートされる Amazon EMRノードの最大数を考慮してください。

• クラスターのパフォーマンスは、クラスター内のノードと 間のネットワークレイテンシーによって異なりますKDC。

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

外部 KDC— Active Directory クロス領域信頼を持つ別のクラスターKDC上のクラスター

この設定では、まず、Active Directory との双方向のクロス領域信頼KDCを持つクラスター専用クラスターを作成します。詳細なチュートリアルについては、「チュートリアル: Active Directory ドメインを使用したクロス領域信頼の設定」を参照してください。次に、信頼KDCを持つクラスターを外部 として参照して、追加のクラスターを起動しますKDC。例については、Active Directory クロス領域信頼KDCを使用する外部クラスターを参照してください。これにより、外部 を使用する各 Amazon EMRクラスターはKDC、Microsoft Active Directory ドメインで定義および維持されているプリンシパルを認証できます。

利点

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

• Amazon は Active Directory 領域EMRに参加するため、Active Directory ユーザーに対応する Linux ユーザーを作成する必要がなくなります。それでも、ユーザーごとにHDFSディレクトリを作成する必要があります。

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

• Active Directory ドメインのユーザープリンシパルは、EC2プライベートキーファイルを使用せずに、kinit認証情報を使用して Kerberized クラスターにアクセスできます。これにより、クラスターユーザー間でプライベートキーを共有する必要がなくなります。

• を維持するのは 1 つの Amazon EMRプライマリノードのみでKDC、 KDCと Active Directory 間のクロス領域信頼のために Active Directory 認証情報を使用してクラスターを作成する必要があります。

考慮事項と制約事項

• 各EMRクラスターの各ノードには、 KDCと Active Directory ドメインコントローラーへのネットワークルートが必要です。

• 各 Amazon EMRノードは外部 に認証の負担をかけるためKDC、 の設定はクラスターのパフォーマンスKDCに影響します。KDC サーバーのハードウェアを設定するときは、同時にサポートされる Amazon EMRノードの最大数を考慮してください。

• クラスターのパフォーマンスは、クラスター内のノードとKDCサーバー間のネットワークレイテンシーによって異なります。

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

同じ で複数のクラスターを使用するための要件 KDC

複数のクラスターが同じ Kerberos 領域KDCで同じ を使用できます。ただし、クラスターが同時に実行されると、競合する Kerberos ServicePrincipal 名を使用するとクラスターが失敗する可能性があります。

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