このページの改善にご協力ください
このユーザーガイドに貢献するには、すべてのページの右側のペインにある「GitHub でこのページを編集する」リンクを選択してください。
IRSA で別のアカウントに対して認証する
別のアカウントのクラスターから ID プロバイダーを作成するか、連鎖した AssumeRole オペレーションを使用することで、クロスアカウントの IAM アクセス許可を設定できます。次の例では、アカウント A は、サービスアカウントの IAM ロールをサポートする Amazon EKS クラスターを所有しています。そのクラスターで実行されている Pod は、アカウント B の IAM アクセス許可を引き受ける必要があります。
-
オプション 1 の方がシンプルですが、アカウント B でアカウント A のクラスターの OIDC ID プロバイダーを作成および管理する必要があります。
-
オプション 2 は、OIDC が常にアカウント A で管理されますが、
AssumeRoleを 2 つ呼び出してロールチェイニングを行う必要があります。
オプション 1: 別のアカウントのクラスターから ID プロバイダーを作成する
この例では、アカウント A はアカウント B にクラスターからの OpenID Connect (OIDC) 発行者 URL を提供します。アカウント B は、アカウント A のクラスターからの OIDC 発行者 URL を使用して、「クラスターの IAM OIDC プロバイダーを作成する」および「IAM ロールを Kubernetes サービスアカウントに割り当てる」の手順に従います。次に、クラスター管理者は、アカウント A のクラスターのサービスアカウントに、アカウント B (444455556666) のロールを使用するように注釈を付けます。
apiVersion: v1 kind: ServiceAccount metadata: annotations: eks.amazonaws.com/role-arn: arn:aws:iam::444455556666:role/account-b-role
オプション 2: 連鎖された AssumeRole オペレーションを使用する
このアプローチでは、アカウントごとに IAM ロールが作成されます。アカウント B のロールは、アカウント A を信頼します。アカウント A のロールは、OIDC フェデレーションを使用して、クラスターから認証情報を取得します。ポッドは、AWS CLI プロファイルを使用して、2 つのロールを連鎖させます。
ステップ 1: アカウント B にターゲットロールを作成する
アカウント B (444455556666) は、アカウント A のクラスター内のポッドで必要になるアクセス許可と共に IAM ロールを作成します。アカウント B は、このロールに目的のアクセス許可ポリシーをアタッチし、次の信頼ポリシーを追加します。
アカウント B のロール用の信頼ポリシー — アカウント A の特定の IRSA ロールがこのロールを引き受けることを許可します。
{ "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:root" }, "Action": "sts:AssumeRole", "Condition": {} } ] }
重要
最小特権の場合、アカウントルート (arn:aws:iam::111122223333:root) を使用するのではなく、Principal ARN をアカウント A の特定のロール ARN に置き換えます。アカウントルートを使用すると、アカウント A のいずれの IAM プリンシパルもこのロールを引き受けることができます。
ステップ 2: アカウント A に IRSA ロールを作成する
アカウント A (111122223333) では信頼ポリシーを定義したロールを作成し、その信頼ポリシーではクラスターの OIDC 発行者アドレスで作成された ID プロバイダーから認証情報を取得することを許可します。
アカウント A のロール (OIDC フェデレーション) 用の信頼ポリシー — EKS クラスターの OIDC プロバイダーがこのロールの認証情報を発行することを許可します。
{ "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:aud": "sts.amazonaws.com" } } } ] }
重要
最小特権の場合、sub クレームの StringEquals 条件を追加して、このロールを特定の Kubernetes サービスアカウントに制限します。sub 条件がない場合、クラスター内のいずれのサービスアカウントもこのロールを引き受けることができます。sub 値では、system:serviceaccount:NAMESPACE:SERVICE_ACCOUNT_NAME
という形式を使用します。例えば、default 名前空間で my-service-account という名前のサービスアカウントに制限するには、次のようにします。
"oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:sub": "system:serviceaccount:default:my-service-account"
ステップ 3: アカウント A のロールに AssumeRole アクセス許可をアタッチする
アカウント A は、ステップ 2 で作成されたロールにアクセス許可ポリシーをアタッチします。このポリシーにより、ロールがアカウント B のロールを引き受けることが許可されます。
アカウント A のロール用のアクセス許可ポリシー — アカウント B のターゲットロールに sts:AssumeRole を付与します。
{ "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::444455556666:role/account-b-role" } ] }
ステップ 4: ロールを連鎖するようにポッドを設定する
アカウント B のロールを引き受ける Pod のアプリケーションコードは、account_b_role と account_a_role の 2 つのプロファイルを使用します。account_b_role プロファイルでは、ソースとして account_a_role プロファイルを使用します。AWS CLI では、~/.aws/config ファイルは以下のようになります。
[profile account_b_role] source_profile = account_a_role role_arn=arn:aws:iam::444455556666:role/account-b-role [profile account_a_role] web_identity_token_file = /var/run/secrets/eks.amazonaws.com/serviceaccount/token role_arn=arn:aws:iam::111122223333:role/account-a-role
他の AWS SDK の連鎖されたプロファイルを指定するには、使用する SDK のドキュメントを参照してください。詳細については、「AWS で構築するツール
