使用 IRSA 对另一个账户进行身份验证 - Amazon EKS
从其它账户的集群创建身份提供程序选项 2：使用链式 AssumeRole 操作

帮助改进此页面

要帮助改进本用户指南，请选择位于每个页面右侧窗格中的在 GitHub 上编辑此页面链接。

使用 IRSA 对另一个账户进行身份验证

您可以通过从其它账户的集群创建身份提供者或者使用链接的 AssumeRole 操作，配置跨账户 IAM 权限。在以下示例中，账户 A 拥有一个支持服务账户的 IAM 角色的 Amazon EKS 集群。在该集群上运行的容器组（pod）需要承担来自账户 B 的 IAM 权限。

  • 选项 1 更简单，但需要账户 B 为账户 A 的集群创建和管理 OIDC 身份提供程序。

  • 选项 2 将 OIDC 管理保留在账户 A 中，但需要通过两次 AssumeRole 调用进行角色链式操作。

从其它账户的集群创建身份提供程序

在此示例中，账户 A 从其集群向账户 B 提供 OpenID Connect（OIDC）颁发者 URL。账户 B 遵循为集群创建 IAM OIDC 提供者和为 Kubernetes 服务账户分配 IAM 角色中的说明，使用来自账户 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）使用 AWS CLI 配置文件将这两个角色链接在一起。

步骤 1：在账户 B 中创建目标角色

账户 B（444455556666）创建一个 IAM 角色，该角色具有账户 A 集群中容器组（pod）所需的权限。账户 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 角色的权限策略–该策略授予对账户 B 目标角色的 sts:AssumeRole 权限。

{
    "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 SDK 指定链接的配置文件，请参考所使用 SDK 的文档。有关更多信息，请参阅用于在 AWS 上进行构建的工具。