**協助改進此頁面** 

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

若要為本使用者指南貢獻內容，請點選每個頁面右側面板中的**在 GitHub 上編輯此頁面**連結。

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 使用 IRSA 向其他帳戶進行身分驗證
<a name="cross-account-access"></a>

您可以從另一個帳戶的叢集建立身分提供者，或使用鏈結的 `AssumeRole` 操作，設定跨帳戶 IAM 許可。在下列範例中，*帳戶 A* 擁有 Amazon EKS 叢集，該叢集支援服務帳戶的 IAM 角色。在該叢集上執行的 Pod 必須取得*帳戶 B* 的 IAM 許可。
+  **選項 1** 更簡單，但需要帳戶 B 為帳戶 A 的叢集建立和管理 OIDC 身分提供者。
+  **選項 2** 會在帳戶 A 中保留 OIDC 管理，但需要透過兩個`AssumeRole`呼叫鏈結角色。

## 選項 1：從另一個帳戶的叢集建立身分提供者
<a name="_option_1_create_an_identity_provider_from_another_accounts_cluster"></a>

在此範例中，帳戶 A 將為帳戶 B 提供其叢集的 OpenID Connect (OIDC) 發行者 URL。帳戶 B 遵循[為您的叢集建立 IAM OIDC 提供商](enable-iam-roles-for-service-accounts.md)和 [將 IAM 角色指派給 Kubernetes 服務帳戶](associate-service-account-role.md) 中的指示，使用來自帳戶 A 叢集的 OIDC 發行者 URL。然後，叢集管理員會註釋帳戶 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 聯合從叢集取得登入資料。然後，Pod 會使用 CLI AWS 設定檔將兩個角色鏈結在一起。

### 步驟 1：在帳戶 B 中建立目標角色
<a name="_step_1_create_the_target_role_in_account_b"></a>

帳戶 B ({{444455556666}}) 會建立具有帳戶 A 叢集中 Pod 所需許可的 IAM 角色。帳戶 B 會將所需的許可政策連接至此角色，然後新增下列信任政策。

 **帳戶 B 角色的信任政策** — 此政策允許帳戶 A 的特定 IRSA 角色擔任此角色。

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {}
    }
  ]
}
```

**重要**  
如需最低權限，請將 `Principal` ARN 取代為帳戶 A 中的特定角色 ARN，而不是使用帳戶根 (`arn:aws:iam::111122223333:root`)。使用帳戶根允許帳戶 A 中的任何 ** IAM 主體擔任此角色。

### 步驟 2：在帳戶 A 中建立 IRSA 角色
<a name="_step_2_create_the_irsa_role_in_account_a"></a>

帳戶 A ({{111122223333}}) 會建立具有信任政策的角色，該政策會從使用叢集 OIDC 發行者地址建立的身分提供者取得憑證。

 **帳戶 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：將 AssumeRole 許可連接至帳戶 A 的角色
<a name="_step_3_attach_the_assumerole_permission_to_account_as_role"></a>

帳戶 A 會將許可政策連接至步驟 2 中建立的角色。此政策允許角色擔任帳戶 B 的角色。

 **帳戶 A 角色的許可政策** — 此政策`sts:AssumeRole`授予帳戶 B 的目標角色。

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::444455556666:role/account-b-role"
        }
    ]
}
```

### 步驟 4：將 Pod 設定為鏈結角色
<a name="_step_4_configure_the_pod_to_chain_roles"></a>

Pod 擔任帳戶 B 角色的應用程式碼使用兩個描述檔：`account_b_role` 和 `account_a_role`。`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 SDKs的鏈結設定檔，請參閱您正在使用的 SDK 文件。如需詳細資訊，請參閱[要建置的工具 AWS](https://aws.amazon.com/developer/tools/)。