CodePipeline角色权限全开仍遇CodeBuild DOWNLOAD_SOURCE阶段访问拒绝求助

我之前也碰到过一模一样的问题！这种情况大概率不是CodePipeline角色的权限不够，而是CodeBuild项目本身的服务角色或者资源的共享权限没配置对——毕竟手动跑CodeBuild正常，说明CodeBuild角色本身能拉取源码，但通过CodePipeline触发时，还有额外的权限环节要处理。下面是我当时排查的几个关键方向，按优先级来：

CodePipeline要触发CodeBuild，除了自己的角色有权限，CodeBuild的服务角色得信任CodePipeline的服务主体。你可以进入CodeBuild项目的「设置」→「服务角色」，查看角色的信任策略，确认是否包含codepipeline.amazonaws.com这个主体。标准的信任策略应该类似：

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

如果没有codepipeline.amazonaws.com，添加之后再重新触发流水线试试。

哪怕你给CodePipeline角色配了宽松权限，万一源码存在S3或CodeCommit里，可能还有额外的资源级限制：

• 如果是S3源码桶：检查桶策略是否明确允许CodePipeline角色的ARN执行s3:GetObject、s3:ListBucket等操作；
• 如果是CodeCommit存储库：要给CodePipeline角色添加codecommit:GitPull等读取权限。

如果你的流水线用了自定义S3桶作为工件存储，这个桶的权限要同时开放给CodePipeline和CodeBuild角色：

• CodePipeline角色需要s3:PutObject权限，把源码包传到工件桶；
• CodeBuild角色需要s3:GetObject权限，从工件桶拉取源码（这就是DOWNLOAD_SOURCE阶段的核心操作）。

别只停留在「访问拒绝」的提示，去CloudWatch里找到CodeBuild执行失败的日志，里面会明确显示被拒绝的操作和目标资源ARN——这是最直接的排查线索。比如日志里可能显示AccessDenied: s3:GetObject on arn:aws:s3:::my-pipeline-bucket/xxx，那你就针对性地给对应角色添加该权限。

虽然你说角色权限宽松，但万一漏了这个核心权限？CodePipeline要触发CodeBuild，必须拥有codebuild:StartBuild权限，资源范围至少要覆盖你的CodeBuild项目ARN（也可以先用*测试是否是这个问题）。

如果你的S3桶、CodeBuild工件或源码用了KMS加密，相关角色还需要额外的KMS权限：

• CodePipeline角色需要kms:Encrypt/kms:Decrypt权限来处理加密的工件；
• CodeBuild角色需要kms:Decrypt权限来解密拉取的源码文件。

我当时的问题就是CodeBuild服务角色没加CodePipeline的信任主体，加上之后流水线立刻就正常了。建议你先从CloudWatch日志入手，定位具体的拒绝原因，再针对性修复会高效很多。

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