AWS CodePipeline触发正常CodeBuild报S3 403访问拒绝错误

报错信息：

CLIENT_ERROR: AccessDenied: Access Denied status code: 403, request id: MRKXFJDHM0ZJF1F6, host id: C6ds+Gg//r7hxFtBuwwpOPfPPcLbywL5AEWkXixCqfdNbjuFOo4zKEqRx6immShnCNK4VgIyJTs= for primary source and source version arn:aws:s3:::codepipeline-us-east-1-805870671912/segev/SourceArti/Qm4QUD8

核心逻辑差异说明 #

手动触发CodeBuild时，CodeBuild会直接使用项目内配置的GitHub源配置拉取代码，全程不会访问CodePipeline的托管S3存储桶，因此之前验证的权限正常仅覆盖了CodeBuild直连GitHub、推送ECR的链路，未覆盖Pipeline触发场景的访问链路。

CodePipeline触发构建的执行逻辑为：

1. Source阶段先拉取GitHub仓库代码，将源码打包为压缩包
2. 压缩包作为Pipeline工件，上传到CodePipeline自动创建的区域S3工件桶（即报错中提到的codepipeline-us-east-1-805870671912）
3. CodeBuild阶段启动时，不再直接拉取GitHub代码，而是从上述S3路径下载源码压缩包作为构建输入

报错的403就是CodeBuild在第三步访问S3对象时被拒绝导致的。

高频根因与排查方向 #

• CodeBuild服务角色缺少S3工件桶访问权限
  检查CodeBuild项目绑定的服务角色（注意不是CodePipeline的服务角色），确认角色权限策略中包含对该S3桶的s3:GetObject、s3:GetObjectVersion权限，资源范围需要覆盖桶下所有对象。同时检查桶本身的资源策略，确认没有显式拒绝该角色访问的规则。
• S3工件启用KMS加密但未给CodeBuild授权密钥使用权限
  这是占比最高的隐性坑：CodePipeline默认会对S3存储的工件做KMS加密，如果你使用的是客户自管理KMS密钥而非AWS默认托管密钥，哪怕S3权限配置完全正确，只要CodeBuild角色没有该密钥的kms:Decrypt、kms:GenerateDataKey权限，访问加密对象时就会返回S3 403错误，且报错信息不会提示是KMS权限问题。
• S3桶存在访问限制规则
  检查桶是否配置了强制通过VPC端点访问、IP白名单限制、禁止非指定角色访问的规则，确认CodeBuild的运行网络路径、角色身份匹配桶的允许规则。如果CodeBuild运行在VPC模式下，还要确认VPC端点的策略没有拦截到S3的访问。
• 跨账号配置错误
  如果CodePipeline、CodeBuild、S3桶三者不在同一个AWS账号下，需要确认跨账号角色信任关系、S3桶跨账号授权、KMS密钥跨账号授权都配置完整。

快速验证方法 #

使用CodeBuild服务角色的临时凭证，通过AWS CLI执行如下命令直接访问报错中的S3对象：

aws s3 cp s3://codepipeline-us-east-1-805870671912/segev/SourceArti/Qm4QUD8 ./test-source.zip

如果命令执行失败，根据返回的详细错误信息可以直接定位是S3权限缺失还是KMS解密权限缺失，无需在控制台反复试跑Pipeline。

临时验证方案 #

如果需要快速确认问题范围，可以先给CodeBuild服务角色绑定AmazonS3ReadOnlyAccess托管策略，重新跑Pipeline，如果错误消失，就可以确定是S3/KMS相关权限配置问题，后续再按最小权限原则收缩权限即可。

小概率情况是CodePipeline中CodeBuild阶段的输入工件映射配置错误，传递了不存在的工件路径，这种情况一般会返回对象不存在错误，而非403访问拒绝，优先级可以放在后面排查。

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