Amazon EMR on EKS でのセキュリティのベストプラクティス
Amazon EMR on EKS には、独自のセキュリティポリシーを策定および実装する際に考慮すべき、さまざまなセキュリティ機能が用意されています。以下のベストプラクティスは一般的なガイドラインであり、完全なセキュリティソリューションを説明するものではありません。これらのベストプラクティスはお客様の環境に必ずしも適切または十分でない可能性があるので、処方箋ではなく、あくまで有用な考慮事項とお考えください。
注記
その他のセキュリティのベストプラクティスについては、「Amazon EMR on EKS でのセキュリティのベストプラクティス」を参照してください。
最小特権の原則を適用する
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 リリースおよびベースイメージ URI の選択の詳細を参照してください。
ポッドの認証情報アクセスを制限する
Kubernetes は、ポッドに認証情報を割り当てるための方法をいくつかサポートしています。複数の認証情報プロバイダーをプロビジョニングすると、セキュリティモデルの複雑さが増す可能性があります。Amazon EMR on EKS では、サービスアカウントの IAM ロール (IRSA) の使用を、登録された EKS 名前空間内の標準の認証情報プロバイダーとして採用しています。kube2iam
信頼できないアプリケーションコードを分離する
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 インスタンスプロファイルの認証情報に対するアクセスの制限」を参照してください。ただし、ポッドが必要なすべての許可を持つように、サービスアカウントの IAM ロールを適切にスコープすることが重要です。例えば、ノードの IAM ロールには、Amazon ECR からコンテナイメージを取得するための許可が割り当てられます。ポッドにこれらの許可が割り当てられていない場合、ポッドは Amazon ECR からコンテナイメージを取得できません。VPC CNI プラグインも更新する必要があります。詳細については、「演習: サービスアカウントの IAM ロールを使用するように VPC CNI プラグインを更新する」を参照してください。
