AWS CodeBuild访问Secrets Manager遇AccessDeniedException求助

使用AWS CodePipeline + CodeBuild搭建CI/CD管道，部署Elastic Beanstalk上的Docker应用。Docker凭证存储在Secrets Manager中，在CodeBuild里配置为环境变量，但已配置IAM策略的情况下，仍触发AccessDeniedException。

现有配置 #

CodeBuild IAM角色权限策略 #

{ 
  "Version": "2012-10-17", 
  "Statement": [ 
    { 
      "Effect": "Allow", 
      "Action": [ "secretsmanager:GetSecretValue" ], 
      "Resource": [ "arn:aws:secretsmanager:region:userid:secret:secretname-??????"] 
    }
  ]
}

Secrets Manager资源权限策略 #

{
  "Version" : "2012-10-17",
  "Statement" : [ 
    {
      "Effect" : "Allow",
      "Principal" : {
        "AWS" : "arn:aws:iam::userid:role/service-role/servicename"
      },
      "Action" : "secretsmanager:GetSecretValue",
      "Resource" : "arn:aws:secretsmanager:region:userid:secret:secretname-??????"
    } 
  ]
}

错误信息 #

Phase context status code: Secrets Manager Error Message: AccessDeniedException: User: arn:aws:sts::userid:assumed-role/servicerolename/AWSCodeBuild-codebuildid is not authorized to perform: secretsmanager:GetSecretValue on resource: id_value because no identity-based policy allows the secretsmanager:GetSecretValue action

已尝试附加客户托管策略、创建内联策略，均无效；IAM策略模拟器测试角色访问权限显示“允许”。

排查解决步骤 #

• 核对资源ARN的精确性
  错误信息中提到的资源是id_value，但策略里使用的是带-??????占位符的ARN。登录Secrets Manager控制台，复制目标Secret的完整ARN（包括自动生成的随机后缀），替换IAM策略和资源策略中的ARN，确保完全匹配。

• 检查IAM角色的信任关系
  确认CodeBuild服务能正确扮演该角色，信任策略需包含codebuild.amazonaws.com作为服务主体：

  {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Principal": {
          "Service": "codebuild.amazonaws.com"
        },
        "Action": "sts:AssumeRole"
      }
    ]
  }
  

• 排查权限边界与SCP限制

  • 检查IAM角色是否设置了权限边界，如果边界策略未包含secretsmanager:GetSecretValue动作，会覆盖附加的允许策略导致拒绝。
  • 若账号属于AWS Organizations，确认是否存在**服务控制策略（SCP）**限制了Secrets Manager的访问权限，需确保SCP允许目标角色执行secretsmanager:GetSecretValue。

• 验证Secret状态与版本
  确认目标Secret处于启用状态，且CodeBuild尝试访问的是存在的版本（如默认版本），避免因Secret轮换或版本禁用导致的访问问题。

• 修正策略模拟器测试条件
  策略模拟器测试时，需使用错误信息中的Assumed Role ARN（arn:aws:sts::userid:assumed-role/servicerolename/AWSCodeBuild-codebuildid）而非角色本身的ARN，部分策略可能对角色的扮演实体有额外限制，使用实际Assumed Role ARN测试才能准确反映权限情况。

内容的提问来源于stack exchange，提问作者GalB