ある企業が AWS 上で Amazon EKS（Kubernetes）を使ってマイクロサービスを運用しており、セキュリティ強化のために以下を実装したいと考えています。⑤Pod が必要な AWS リソース（S3、DynamoDB）にアクセスする際に、IAM ロールを使用する（インスタンスプロファイルではなく Pod レベルで）、④ネットワークポリシーで Pod 間の通信を制御する。これらを実現するために使用するべき技術を2つ選択してください。
- A. Amazon VPC CNI プラグインのネットワークポリシー機能または Calico などのネットワークポリシーエンジンを EKS にデプロイし、Kubernetes NetworkPolicy リソースで Pod 間通信を制御する
- B. すべての Pod に同一の IAM ロールを付与し、S3 と DynamoDB への全権限を付与する
- C. セキュリティグループのみを使ってすべての Pod 間通信を制御する
- D. EC2 ノードの IAM インスタンスプロファイルに全 Pod が必要な権限をまとめて付与する
- E. EKS の IAM Roles for Service Accounts（IRSA）を設定し、Kubernetes ServiceAccount に IAM ロールをアノテーションで関連付ける。Pod は OIDC フェデレーション経由でそのロールの認証情報を自動取得する
解答と解説を見る
正解: A, E
IRSA（E）は Kubernetes ServiceAccount と IAM ロールを OIDC フェデレーションで紐付けることで、Pod レベルの最小権限 IAM アクセスを実現します。インスタンスプロファイルと異なり、同一ノード上の異なる Pod に異なる IAM 権限を付与できます。Amazon VPC CNI のネットワークポリシー機能または Calico（A）は Kubernetes の NetworkPolicy リソースを実装し、Pod 間通信のラベルセレクターベースの細かいアクセス制御を実現します。 D: インスタンスプロファイルに全権限をまとめることは最小権限原則に反し、全 Pod が全リソースにアクセスできてしまいます。 C: セキュリティグループは IP/ポートレベルの制御で、Kubernetes の Pod ラベルベースの動的なネットワークポリシーには対応していません（EKS の SG for Pods は使えますが、NetworkPolicy の代替には限定的）。 B: 全 Pod に同一の広い権限を付与することは最小権限原則に大きく反します。
📚 関連サービスの解説: Amazon VPC ・ Amazon EKS