無限ノック › SCS 練習問題一覧 › 問題
SCSアイデンティティとアクセス管理

ある企業は、共有のAmazon EKSクラスター上で複数のマイクロサービスを稼働させています。各Podはそれぞれ異なるS3バケットとDynamoDBテーブルにアクセスする必要があります。現在は全Podがノードグループのインスタンスロールを共用しており、過剰な権限が付与されている状態です。セキュリティチームは、Podごとに最小権限を付与し、かつ静的な認証情報をクラスター内に保持しない構成を求めています。最も適切な方法はどれですか。

A
クラスターのOIDCプロバイダーを登録し、Kubernetesのサービスアカウントに紐づくIAMロールを作成して信頼ポリシーで対象サービスアカウントに限定し、Podにそのロールを引き受けさせる
✓ 正解
OIDCプロバイダーを介したIRSAにより、サービスアカウント単位でIAMロールを関連付けられ、信頼ポリシーで対象を限定し短期STS認証情報を取得する。Podごとの最小権限と静的認証情報の排除という両要件を同時に満たす。
B
各Podに必要な最小権限のIAMポリシーをノードグループのインスタンスロールに集約して付与し、Kubernetes RBACでPod間のアクセス範囲を制御して権限を分離する
ノードのインスタンスロールはそのノード上で動く全Podに共有されるため、ポリシーを集約してもPod単位での権限分離は不可能。Kubernetes RBACはAPI操作の認可でありIAM権限の分離手段にはならない。
C
サービスアカウントごとにIAMアクセスキーを発行してKubernetes Secretsに保存し、Podの環境変数としてマウントして個別の権限を割り当てる
IAMアクセスキーをKubernetes Secretsに保存する方式は長期の静的認証情報を保持することになり、漏えいやローテーションの課題が残る。静的認証情報を持たないという要件に明確に反する。
D
全権限を含む単一のIAMロールを作成し、各Podがノードの認証情報を用いてSTSのAssumeRoleでそのロールを引き受けて必要な操作を実行する
単一ロールに全権限を集約して各Podが引き受ける構成では、引き受けるロール自体が過剰権限を持つため最小権限の原則を満たせない。Pod単位の権限分離にもならない。

解説

IAM Roles for Service Accounts(IRSA)は、EKSクラスターのOIDCプロバイダーを介してKubernetesサービスアカウントとIAMロールを関連付ける仕組みです。信頼ポリシーで特定のサービスアカウント(namespace/名前)に限定でき、PodはWeb IDフェデレーションで短期のSTS認証情報を取得します。これによりPodごとに最小権限を付与でき、静的認証情報をクラスター内に保持する必要もありません。 選択肢Bのノードインスタンスロールは同一ノード上の全Podで共有されるため、RBACはKubernetes APIの認可制御に過ぎずIAM権限のPod単位分離はできない。 選択肢CのIAMアクセスキーをSecretsに保存する方法は長期の静的認証情報を保持することになり、ローテーションや漏えいリスクの要件に反する。 選択肢Dの単一ロールを全Podで引き受ける構成はロールが過剰権限を持つため最小権限を実現できない。

ドメイン別正答率・予想スコアでリアルタイムに実力把握

無限ノックでSCSを徹底対策。全問AI生成のオリジナル問題。

無料で演習を始める →
← SCS の問題一覧に戻る