借助Github Action的AWS联合身份跨账号扮演角色遇权限问题求助

环境说明 #

我拥有两个AWS账号：源账号和目标账号。已配置AWS OIDC联合身份，可通过GitHub Actions官方Action使用令牌登录AWS，配置如下：

- name: configure aws credentials
  uses: aws-actions/configure-aws-credentials@v1
  with:
    role-to-assume: arn:aws:iam::<source account id>:role/role-A
    aws-region: us-east-1

问题描述 #

现在想使用Terraform管理这两个账号的资源，已按指南配置允许role-A扮演目标账号的role-B，但遇到如下403权限错误：

Error: 022-08-31T09:28:04.246] [ERROR] default - 
Error: error configuring Terraform AWS Provider: IAM Role (arn:aws:iam::<destination account id>:role/role-B) cannot be assumed.

There are a number of possible causes of this - the most common are:
  * The credentials used in order to assume the role are invalid
  * The credentials do not have appropriate permission to assume the role
  * The role ARN is not valid

Error: operation error STS: AssumeRole, https response error StatusCode: 403, RequestID: 7227d0e8-e955-45ac-8f08-fc48699564e3, api error AccessDenied: User: arn:aws:sts::<source account id>:assumed-role/role-A/GitHubActions is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::<destination account id>:role/role-B


  with provider["registry.terraform.io/hashicorp/aws"].security,
  on cdk.tf.json line 4125, in provider.aws[1]:
4125:       }

已配置的IAM策略 #

role-A的权限策略 #

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::<destination account id>:role/role-B"
        }
    ]
}

role-B的信任策略 #

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::<source account id>:role/role-A"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

排查步骤 #

• 核对账号ID与角色ARN准确性：确认所有配置和错误信息中的<source account id>、<destination account id>是12位纯数字的AWS账号ID，无拼写错误、空格或特殊字符。
• 验证role-A的会话权限传递：GitHub Actions扮演role-A后生成的会话为arn:aws:sts::<source account id>:assumed-role/role-A/GitHubActions，需确认role-A的信任策略允许GitHub OIDC身份提供商扮演它，且无权限边界或会话策略限制sts:AssumeRole操作。
• 检查role-B信任策略的Principal规则：确保role-B信任策略中的Principal是role-A的IAM角色ARN，而非STS会话ARN。如果role-A的信任策略有条件限制（如SourceIP、StringEquals），需确认GitHub Actions执行环境满足条件。
• 本地模拟测试：用AWS CLI模拟GitHub Actions场景，先获取role-A临时凭证，再尝试扮演role-B：

  # 获取role-A临时凭证
  aws sts assume-role --role-arn arn:aws:iam::<source account id>:role/role-A --role-session-name test-session
  # 配置临时凭证到环境变量
  export AWS_ACCESS_KEY_ID=<临时AK>
  export AWS_SECRET_ACCESS_KEY=<临时SK>
  export AWS_SESSION_TOKEN=<临时会话令牌>
  # 尝试跨账号扮演role-B
  aws sts assume-role --role-arn arn:aws:iam::<destination account id>:role/role-B --role-session-name test-cross-account
  

  若本地测试报错，说明是IAM配置问题；若本地成功，需检查GitHub Actions环境或Terraform提供商配置。
• 检查Terraform提供商配置：确认目标账号的AWS提供商配置正确依赖role-A的凭证扮演role-B，示例配置：

  provider "aws" {
    alias  = "security"
    region = "us-east-1"
    assume_role {
      role_arn = "arn:aws:iam::<destination account id>:role/role-B"
    }
  }
  

  确保无额外的access_key等配置覆盖GitHub Actions设置的环境变量。
• 排查权限边界与SCP：若role-A或role-B设置了权限边界，需确认边界允许对应操作；同时检查组织级的服务控制策略（SCP）是否限制了跨账号角色扮演。
• 查看CloudTrail日志：在源账号和目标账号的CloudTrail中搜索错误中的RequestID（7227d0e8-e955-45ac-8f08-fc48699564e3），获取详细的拒绝原因。

内容的提问来源于stack exchange，提问作者Omer Levi Hevroni