如何解决 IAM 中来自身份提供者的“AccessDenied”或“Not authorized to perform AssumeRoleWithWebIdentity”（无权执行 AssumeRoleWithWebIdentity）联合身份验证错误？

2 分钟阅读

我使用了具有来自身份提供者 (IdP) 的联合身份验证的 AWS Identity and Access Management (IAM) 策略或角色。我收到了“AccessDenied”或“Not authorized AssumeRoleWithWebIdentity”（未授权的 AssumeRoleWithWebIdentity）错误。

简短描述

发生 API 操作 AssumeRoleWithWebIdentity 错误是因为 IAM 信任策略配置不正确或者 IdP 中的 IAM 角色配置不正确。

解决方法

要解决此问题，请按照说明为 OpenID Connect (OIDC) 联合身份验证创建 IAM 角色。然后，遵循以下指南来配置 IAM 角色信任策略。

**注意：**如果在运行 AWS 命令行界面 (AWS CLI) 命令时收到错误，请参阅 AWS CLI 错误故障排除。此外，请确保您使用的是最新版本的 AWS CLI。

IAM 角色信任策略

确保为您的 IdP 配置正确的 IAM 角色信任策略。

GitHub IdP 的角色信任策略示例

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::012345678910:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
          "token.actions.githubusercontent.com:sub": "repo:GitHubOrg/GitHubRepo:ref:refs/heads/GitHubBranch"
        }
      }
    }
  ]
}

IAM 角色配置

确保为您的 IdP 的 IAM 角色配置正确的 Amazon Resource Name (ARN)。配置 IAM 角色的步骤因不同的 IdP 和 AWS 服务而异。

例如，要获取 Amazon Elastic Kubernetes Service (Amazon EKS) 的服务账户的 IAM 角色 ARN，请运行以下命令：

kubectl describe serviceaccount serviceaccount_name -n namespace_name

从输出中，确认 IAM 角色 ARN 是您要代入的角色。如果 IAM 角色 ARN 正确，请按照将 IAM 角色分配给您的 Kubernetes 服务账户的步骤进行操作。如果 IAM 角色 ARN 不正确，请按照创建和关联角色中的步骤更新 ARN。

有关详细信息，请参阅为您的集群创建 IAM OIDC 提供商。

CloudTrail 事件历史记录

API 操作 AssumeRoleWithWebIdentity 失败记录在 AWS CloudTrail 事件历史记录中。可以查看过去 90 天内所有支持的服务、集成和事件类型（例如创建、修改、删除）以及不可变活动。无需设置跟踪即可使用 CloudTrail 事件历史记录。

比较角色信任策略中 CloudTrail 事件历史记录中记录的 PrincipalId 值，以确认 API 请求中传递的值。

例如，如果值 arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com:sts.amazonaws.com:repo:reponame-rn/new-repo:environment:dev 记录在 CloudTrail 事件的 PrincipalID 中，请使用以下信任策略：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
          "token.actions.githubusercontent.com:sub": "repo:reponame-rn/new-repo:environment:dev"
        }
      }
    }
  ]
}

有关详细信息，请参阅使用控制台查看最近的管理事件。

配置最佳实践

要解决配置问题，请遵循以下最佳实践：

角色信任策略中的主体 ARN 不完整：信任策略中的联合主体 ARN 必须包括完整的 ARN 和 OIDC 提供商名称。例如，如果使用的是 GitHub IdP，则主体 ARN 的格式为 arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com。
ARN 分区不正确： ARN 配置必须包括角色和 OIDC 提供商的正确分区。例如，AWS GovCloud 分区中 OIDC 提供商的 ARN 格式为 arn:aws-us-gov:iam::123456789012:oidc-provider/token.actions.githubusercontent.com。
条件键不可用：并非所有 IdP 都与 OIDC 联合身份验证可用的条件键兼容。请务必验证条件键与 OIDC 提供商的兼容性。有关详细信息，请参阅 AWS OIDC 联合身份验证的可用键。
IdP 配置中缺少角色路径：必须为 IdP 配置完整的 IAM 角色和 ARN 路径。例如，administrator 路径 ARN 中的 IAM 角色名称 GitHubRole 配置为 arn:aws:iam::123456789012:role/administrator/GitHubRole。