**このページの改善にご協力ください** 

このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。

# IRSA で別のアカウントに対して認証する
<a name="cross-account-access"></a>

別のアカウントのクラスターから ID プロバイダーを作成するか、連鎖した `AssumeRole` オペレーションを使用することで、クロスアカウントの IAM アクセス許可を設定できます。次の例では、*アカウント A* は、サービスアカウントの IAM ロールをサポートする Amazon EKS クラスターを所有しています。そのクラスターで実行されている Pod は、*アカウント B* の IAM アクセス許可を引き受ける必要があります。
+  **オプション 1** の方がシンプルですが、アカウント B でアカウント A のクラスターの OIDC ID プロバイダーを作成および管理する必要があります。
+  **オプション 2** は、OIDC が常にアカウント A で管理されますが、`AssumeRole` を 2 つ呼び出してロールチェイニングを行う必要があります。

## オプション 1: 別のアカウントのクラスターから ID プロバイダーを作成する
<a name="_option_1_create_an_identity_provider_from_another_accounts_cluster"></a>

この例では、アカウント A はアカウント B にクラスターからの OpenID Connect (OIDC) 発行者 URL を提供します。アカウント B は、アカウント A のクラスターからの OIDC 発行者 URL を使用して、「[クラスターの IAM OIDC プロバイダーを作成する](enable-iam-roles-for-service-accounts.md)」および「[IAM ロールを Kubernetes サービスアカウントに割り当てる](associate-service-account-role.md)」の手順に従います。次に、クラスター管理者は、アカウント A のクラスターのサービスアカウントに、アカウント B ({{444455556666}}) のロールを使用するように注釈を付けます。

```
apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::444455556666:role/account-b-role
```

## オプション 2: 連鎖された `AssumeRole` オペレーションを使用する
<a name="_option_2_use_chained_assumerole_operations"></a>

このアプローチでは、アカウントごとに IAM ロールが作成されます。アカウント B のロールは、アカウント A を信頼します。アカウント A のロールは、OIDC フェデレーションを使用して、クラスターから認証情報を取得します。ポッドは、AWS CLI プロファイルを使用して、2 つのロールを連鎖させます。

### ステップ 1: アカウント B にターゲットロールを作成する
<a name="_step_1_create_the_target_role_in_account_b"></a>

アカウント 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 name="_step_2_create_the_irsa_role_in_account_a"></a>

アカウント 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 name="_step_3_attach_the_assumerole_permission_to_account_as_role"></a>

アカウント 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: ロールを連鎖するようにポッドを設定する
<a name="_step_4_configure_the_pod_to_chain_roles"></a>

アカウント 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 で構築するツール](https://aws.amazon.com/developer/tools/)」を参照してください。