ある企業が、Amazon EKS クラスター上で動作するマイクロサービスに対して、Kubernetes Pod ごとに異なる AWS 権限を付与したい。特定の Pod は S3 にアクセスでき、別の Pod は DynamoDB にのみアクセスできるようにする。Pod に割り当てられた権限は最小限とし、IAM 認証情報を Pod 内の環境変数やファイルに直接保存したくない。最も適切な方法はどれか。
- A. EKS ノードグループの EC2 インスタンスに IAM ロールをアタッチし、ノード上のすべての Pod が同じ IAM ロールを使用する。
- B. AWS Fargate for EKS に移行し、Fargate プロファイルで IAM ロールをタスクに割り当てる。
- C. EKS の IAM Roles for Service Accounts（IRSA）を使用し、Kubernetes サービスアカウントに IAM ロールをアノテーションで紐付ける。Pod はサービスアカウントを通じて自動的に一時認証情報を取得する。
- D. 各 Pod の Kubernetes Secret に IAM アクセスキーを保存し、環境変数として Pod にマウントする。
解答と解説を見る
正解: C
IAM Roles for Service Accounts（IRSA）は EKS の標準機能で、Kubernetes サービスアカウントに IAM ロール ARN をアノテーションとして設定するだけで、Pod が OIDC フェデレーションを通じて一時的な IAM 認証情報を自動取得できる。Pod ごとに異なるサービスアカウント（と異なる IAM ロール）を割り当てることで最小権限を実現できる。選択肢Aはノードレベルの IAM ロールであり、ノード上のすべての Pod が同じ権限を持ってしまうため最小権限の原則を守れない。選択肢DはKubernetes Secret への IAM アクセスキー保存であり、認証情報を直接ファイルに保存することになり、要件に反する。また静的キーのローテーション運用も必要になる。選択肢BはFargate への移行を提案しており、現在の EKS 環境を維持するという要件から逸脱している。また Fargate にも Pod 単位の IRSA が適用可能であるため、EC2 ノードでも Fargate でも IRSA が正解となる。
📚 関連サービスの解説: Amazon EKS ・ AWS IAM