CDK Pipeline手动分配S3制品桶及角色失败的权限问题排查

你遇到的两个连续报错，都是使用CdkPipeline高层封装时的典型配置误区，没有复杂的玄学原因：

• 直接修改底层L1资源属性的操作对高层组件完全无效
  你代码中对pipeline.codePipeline.artifactBucket、pipeline.codePipeline.role的直接赋值，不会触发CdkPipeline的权限自动配置逻辑。高层组件内部全权管理底层CodePipeline的依赖关系、IAM权限链路，这种绕过组件初始化流程的手动赋值，只会导致组件不知道要给哪些角色授予S3桶的访问权限，自然出现S3访问403报错。
• 手动替换主角色破坏了内置的信任关系链路
  CdkPipeline运行时会自动生成多个关联子角色：主管道执行角色、S3资产操作专属角色（也就是你报错里的PipelineAssetsFileRole）、各流水线动作的执行角色。这些子角色的信任策略，默认仅允许CdkPipeline自动生成的主管道角色发起AssumeRole请求。你手动替换主管道角色后，新角色根本不在这些子角色的信任白名单里，哪怕给新角色绑了全量Admin权限，也绕不开信任策略的校验。

很多人在这里搞混：AssumeRole的权限是被扮演的目标角色定义的、允许谁来扮演自己，和发起请求的角色有多大权限没有关系。哪怕发起方有全账号Admin权限，只要目标角色的信任策略不允许它扮演，就一定会报权限不足。

1. 正确传入自定义S3制品桶配置 #

删除你代码里后续单独给pipeline.codePipeline.artifactBucket赋值的那行代码，改为在CdkPipeline初始化的时候通过内置参数传入自定义桶，让组件自动完成全链路的权限配置：
修改后的CdkPipeline初始化代码结构如下：

const pipeline = new CdkPipeline(this, 'Pipeline', {
    pipelineName: 'WorkshopPipeline',
    cloudAssemblyArtifact,
    crossAccountKeys: false,
    // 直接在初始化参数中传入自定义S3桶
    artifactBucket: Bucket.fromBucketName(this, 'S3ArtifactBucket', 'cdktestbucketforpipeline'),
    // 原有sourceAction配置保持不变
    sourceAction: new codepipeline_actions.CodeCommitSourceAction({
        actionName: 'CodeCommit',
        output: sourceArtifact,
        repository: repo
    }),
    // 原有synthAction配置保持不变
    synthAction: SimpleSynthAction.standardNpmSynth({
        sourceArtifact: sourceArtifact,
        cloudAssemblyArtifact: cloudAssemblyArtifact,
        buildCommand: 'npm run build',
        environment : {
          buildImage: LinuxBuildImage.STANDARD_4_0,
          privileged: true
        }
    })
});

同时不要在自定义桶上配置“允许所有服务访问”的宽泛策略，这类策略很容易和后续CDK自动注入的权限规则冲突，建议给管道相关的执行角色授予精准的ListBucket/GetObject/PutObject权限即可。

2. 正确传入自定义执行角色 #

同样删除代码里给pipeline.codePipeline.role赋值的那行代码，在CdkPipeline初始化参数中传入自定义角色，让组件自动把这个角色的ARN同步到所有关联子角色的信任策略里：

const pipeline = new CdkPipeline(this, 'Pipeline', {
    // 保留前面的所有原有配置
    // ...
    // 直接在初始化参数中传入自定义执行角色
    role: Role.fromRoleArn(this, 'CDKS3TestRole', 'arn:aws:iam::012345678910:role/CDKS3Test'),
});

需要确认自定义角色的信任关系中，已经包含codepipeline.amazonaws.com服务主体，否则CodePipeline服务无法使用这个角色执行操作。

3. 残留S3 403报错的排查点 #

如果完成上述配置后依然出现S3访问拒绝，按顺序排查：

• 如果自定义桶启用了SSE-KMS加密，哪怕你设置了crossAccountKeys: false，也要给所有管道关联的执行角色授予对应KMS密钥的Decrypt/GenerateDataKey权限，否则访问加密对象时依然会返回403
• 检查桶策略是否配置了来源IP、VPC终端节点的限制，确保CodePipeline、CodeBuild的服务访问路径在允许范围内
• 不要给桶配置过于宽泛的强制允许策略，很容易因为和AWS服务内部的权限校验逻辑冲突导致访问失败

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