翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon EMR on EKS でのセキュリティのベストプラクティス
Amazon EMR on EKS には、独自のセキュリティポリシーを策定および実装する際に考慮すべき、さまざまなセキュリティ機能が用意されています。以下のベストプラクティスは一般的なガイドラインであり、完全なセキュリティソリューションを説明するものではありません。これらのベストプラクティスはお客様の環境に適切ではないか、十分ではない場合があるため、これらは指示ではなく、有用な考慮事項と見なしてください。
**注記**
その他のセキュリティのベストプラクティスについては、「[Amazon EMR on EKS でのセキュリティのベストプラクティス](#security-best-practices)」を参照してください。
## 最小特権の原則を適用する
Amazon EMR on EKS は、実行ロールなどの IAM ロールを使用して、アプリケーションに対してきめ細かいアクセスポリシーを提供します。これらの実行ロールは、IAM ロールの信頼ポリシーを使用して Kubernetes サービスアカウントにマッピングされます。Amazon EMR on EKS は、登録された Amazon EKS 名前空間内に、ユーザー提供のアプリケーションコードを実行するポッドを作成します。アプリケーションコードを実行するジョブポッドは、他の AWS サービスに接続するときに実行ロールを引き受けます。実行ロールには、アプリケーションのカバーやログ送信先へのアクセスなど、ジョブに必要な最小限の特権セットのみを付与することをお勧めします。また、定期的に、およびアプリケーションコードに変更があったときに、ジョブの許可を監査することをお勧めします。
## エンドポイントのアクセスコントロールリスト
マネージドエンドポイントは、VPC 内で少なくとも 1 つのプライベートサブネットを使用するように設定されている EKS クラスターに対してのみ作成できます。この設定では、VPC からのみアクセスできるように、マネージドエンドポイントによって作成されたロードバランサーへのアクセスが制限されます。セキュリティをさらに強化するには、これらのロードバランサーを使用してセキュリティグループを設定し、選択した一連の IP アドレスに受信トラフィックを制限できるようにすることをお勧めします。
## カスタムイメージの最新のセキュリティ更新プログラムを入手する
Amazon EMR on EKS でカスタムイメージを使用するために、イメージに任意のバイナリとライブラリをインストールできます。イメージに追加するバイナリのセキュリティパッチの適用は、お客様が行います。Amazon EMR on EKS のイメージに、最新のセキュリティパッチを定期的に適用します。最新のイメージを取得するために、Amazon EMR リリースの新しいベースイメージバージョンが存在する場合は常に、カスタムイメージを再構築する必要があります。詳細については、「[Amazon EMR on EKS リリース](emr-eks-releases.md)」および「[ベースイメージ URI の選択の詳細](docker-custom-images-tag.md)」を参照してください。
## ポッドの認証情報アクセスを制限する
Kubernetes は、ポッドに認証情報を割り当てるための方法をいくつかサポートしています。複数の認証情報プロバイダーをプロビジョニングすると、セキュリティモデルの複雑さが増す可能性があります。Amazon EMR on EKS では、[サービスアカウントの IAM ロール (IRSA)](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) の使用を、登録された EKS 名前空間内の標準の認証情報プロバイダーとして採用しています。[kube2iam](https://github.com/jtblin/kube2iam)、[kiam](https://github.com/uswitch/kiam)、クラスターで実行されているインスタンスの EC2 インスタンスプロファイルの使用など、他の方法はサポートされていません。
## 信頼できないアプリケーションコードを分離する
Amazon EMR on EKS では、システムのユーザーが送信したアプリケーションコードの整合性は検査されません。任意のコードを実行する信頼できないテナントがジョブの送信に使用できる、複数の実行ロールで設定されたマルチテナント仮想クラスターを実行している場合、悪意のあるアプリケーションがその特権をエスカレートするリスクがあります。このような状況では、同様の特権を持つ実行ロールを別の仮想クラスターに分離することを検討してください。
## ロールベースのアクセスコントロール (RBAC) の許可
管理者は、Amazon EMR on EKS 管理の名前空間に対するロールベースのアクセスコントロール (RBAC) の許可を厳密に制御する必要があります。少なくとも、Amazon EMR on EKS 管理の名前空間でのジョブ送信者に、次の許可を付与しないでください。
+ configmap を変更するための Kubernetes RBAC 許可 - Amazon EMR on EKS は、Kubernetes の configmaps を使用して、マネージドサービスアカウント名を持つマネージドポッドテンプレートを生成するためです。この属性は変更しないでください。
+ Amazon EMR on EKS ポッドに対して実行するための Kubernetes RBAC 許可 - マネージド SA 名を持つマネージドポッドテンプレートへのアクセス権を付与しないようにします。この属性は変更しないでください。また、この許可により、ポッドにマウントされた JWT トークンへのアクセス権が付与され、これを使用して実行ロールの認証情報が取得される可能性があります。
+ ポッドを作成する Kubernetes RBAC アクセス許可 - ユーザーよりも多くの AWS 権限を持つ IAM ロールにマッピングできる Kubernetes ServiceAccount を使用してユーザーがポッドを作成できないようにします。
+ 変更ウェブフックをデプロイするための Kubernetes RBAC 許可 – ユーザーが変更ウェブフックを使用して、Amazon EMR on EKS によって作成されたポッドの Kubernetes ServiceAccount 名を変更できないようにします。
+ Kubernetes シークレットを読み取るための Kubernetes RBAC 許可 - ユーザーがこれらのシークレットに保存されている機密データを読み取ることができないようにします。
## ノードグループの IAM ロールまたはインスタンスプロファイルの認証情報へのアクセスを制限する
+ ノードグループの IAM ロール (複数可) に最小限の AWS アクセス許可を割り当てることをお勧めします。これにより、EKS ワーカーノードのインスタンスプロファイル認証情報を使用して実行される可能性がある、コードによる特権エスカレーションを回避できます。
+ Amazon EMR on EKS マネージドの名前空間で実行されるすべてのポッドに対するインスタンスプロファイル認証情報へのアクセスを完全にブロックするには、EKS ノードで `iptables` コマンドを実行することをお勧めします。詳細については、「[Amazon EC2 インスタンスプロファイルの認証情報に対するアクセスの制限](https://docs.aws.amazon.com/eks/latest/userguide/restrict-ec2-credential-access.html)」を参照してください。ただし、ポッドが必要なすべての許可を持つように、サービスアカウントの IAM ロールを適切にスコープすることが重要です。例えば、ノードの IAM ロールには、Amazon ECR からコンテナイメージを取得するための許可が割り当てられます。ポッドにこれらの許可が割り当てられていない場合、ポッドは Amazon ECR からコンテナイメージを取得できません。VPC CNI プラグインも更新する必要があります。詳細については、「[演習: サービスアカウントの IAM ロールを使用するように VPC CNI プラグインを更新する](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts-cni-walkthrough.html)」を参照してください。