AWS CDK CodePipeline中CodeBuild执行角色无route53:ListHostedZonesByName权限排查

基于报错假定角色ARN定位关联资源的方法 #

AWS STS假定角色ARN的通用结构为：arn:aws:sts::<账户ID>:assumed-role/<底层长期IAM角色名称>/<临时会话标识>，对应到你的报错ARN：
arn:aws:sts::413025517373:assumed-role/plants-pipeline-BuildCDKRole0DCEDB8F-1BHVX6Z6H5X0H/AWSCodeBuild-39a582bf-8b89-447e-a6b4-b7f7f13c9db1

• 剥离临时会话后缀（斜杠后带UUID的部分，这是每次CodeBuild构建动态生成的临时标识，无长期管理意义），直接提取斜杠前的角色名plants-pipeline-BuildCDKRole0DCEDB8F-1BHVX6Z6H5X0H，这就是实际执行API操作的长期身份载体。
• 到IAM控制台的角色列表中搜索该名称，即可定位到需要配置权限的核心关联资源，无需针对每次生成的临时会话做权限绑定。
• 核查该角色的权限策略时，直接验证是否存在route53:ListHostedZonesByName操作的ALLOW规则，是否被其他DENY规则覆盖，是否存在权限边界、账户SCP的范围限制。

自定义权限绑定未生效的原因与解决方法 #

常见失效原因 #

结合你的CDK流水线场景，权限绑定不生效通常是以下几个逻辑错位导致：

• 绑定对象错位：CDK Pipelines Construct在初始化时，会自动生成名为plants-pipeline-BuildCDKRolexxx的内置构建角色，所有synth阶段的命令（包括route53.HostedZone.fromLookup()的API调用）默认由这个自动生成的角色执行。需要特别注意的是，CDK Pipelines v2版本的内部实现逻辑中，单个Action上传入的角色参数不会覆盖内置的自动角色生成流程，只有在全局codeBuildDefaults中指定的角色才会被实际作为执行身份。如果你只是在单个Action上指定自定义角色，没有在流水线全局配置中覆盖默认构建角色，那么实际跑命令的身份还是那个无权限的自动生成角色，和你自定义的角色没有关联。
• 执行阶段错位：route53.HostedZone.fromLookup()是CDK Synth阶段（CodeBuild容器内执行cdk synth的环节）的本地资源查询操作，不是后续Deploy阶段（CloudFormation更新栈的环节）的API操作。哪怕你把权限绑给了Deploy阶段的CloudFormation执行角色，synth阶段根本不会调用该身份，权限自然不会生效。
• 策略配置不合规：route53:ListHostedZonesByName是全局列表类API，不支持针对单个托管区ARN的资源级权限限定，如果你写的策略中将资源范围限定为某个具体的HostedZone ARN，哪怕操作名匹配，也会触发权限不足的报错。

落地解决步骤 #

• 修正权限绑定目标：直接将包含route53:ListHostedZonesByName权限的策略，绑定到上述从ARN中提取的自动构建角色上；更稳妥的做法是在初始化CDK Pipeline构造器时，通过全局codeBuildDefaults参数指定已配好Route53权限的自定义角色作为默认构建身份，避免Construct自动生成无权限的内置角色。
• 校准权限生效阶段：将Route53的资源查询权限，全部配置给Build阶段的CodeBuild执行角色；如果后续CloudFormation部署环节需要完成Route53记录创建、托管区关联等写操作，再将对应的写权限单独绑定给Deploy阶段的CloudFormation执行角色即可。
• 校验策略合法性：针对route53:ListHostedZonesByName的权限规则，将资源字段设置为*，不要做资源级范围限定；同时核查目标角色的权限链中，是否存在账户级SCP、权限边界的DENY规则覆盖了ALLOW权限。

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