使用 IRSA 向其他帳戶進行身分驗證 - Amazon EKS
選項 1：從另一個帳戶的叢集建立身分提供者選項 2：使用鏈結AssumeRole操作

協助改進此頁面

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

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

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

使用 IRSA 向其他帳戶進行身分驗證

您可以從另一個帳戶的叢集建立身分提供者，或使用鏈結的 AssumeRole 操作，設定跨帳戶 IAM 許可。在下列範例中，帳戶 A 擁有 Amazon EKS 叢集，該叢集支援服務帳戶的 IAM 角色。在該叢集上執行的 Pod 必須取得帳戶 B 的 IAM 許可。

  • 選項 1 更簡單，但需要帳戶 B 為帳戶 A 的叢集建立和管理 OIDC 身分提供者。

  • 選項 2 會在帳戶 A 中保留 OIDC 管理，但需要透過兩個AssumeRole呼叫鏈結角色。

選項 1：從另一個帳戶的叢集建立身分提供者

在此範例中，帳戶 A 將為帳戶 B 提供其叢集的 OpenID Connect (OIDC) 發行者 URL。帳戶 B 遵循為您的叢集建立 IAM OIDC 提供商和 將 IAM 角色指派給 Kubernetes 服務帳戶 中的指示，使用來自帳戶 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操作

在此方法中，每個帳戶都會建立 IAM 角色。帳戶 B 的角色信任帳戶 A，而帳戶 A 的角色使用 OIDC 聯合從叢集取得登入資料。然後，Pod 會使用 CLI AWS 設定檔將兩個角色鏈結在一起。

步驟 1：在帳戶 B 中建立目標角色

帳戶 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 (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 會將許可政策連接至步驟 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 設定為鏈結角色

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。