如何通过单个GCP SA为Terraform授权GCP组织所有项目

之前Org Admin授权不生效的根因 #

你之前给SA授予组织管理员（Org Admin）权限仍然跑不通部署，核心原因是GCP的IAM继承逻辑和很多人想的不一样：roles/resourcemanager.organizationAdmin这个角色的权限范围仅覆盖组织节点本身的管理操作，比如创建/删除项目、调整文件夹结构、配置组织策略，默认不会自动递归授予组织下所有项目内部的资源操作权限。Terraform要在项目内部署计算、存储、网络这类资源，必须拿到对应项目级别的对应权限，缺了这层继承绑定，哪怕你是组织管理员，进项目里部署资源照样会报权限不足。
而且直接给CI用的SA挂Org Admin属于严重的过度授权，安全风险极高，完全没必要用这么高的权限做部署。

单SA覆盖存量+未来所有新建项目的权限配置 #

整套配置只需要创建1个专用的Terraform部署SA，一次配置后不需要给任何新建项目手动加绑权限，永久生效：

• 首先在组织节点的IAM配置页，给这个SA绑定3个组织级的基础角色，不要直接绑Org Admin：
  • roles/resourcemanager.organizationViewer：允许SA枚举组织下所有文件夹、项目的层级结构，Terraform初始化时能正确识别目标项目的上下文
  • roles/serviceusage.serviceUsageAdmin：允许SA在任意项目内启用部署需要的云服务API，不用每次新建项目手动提前开API
  • roles/iam.securityReviewer：允许SA校验自身在目标项目的权限同步状态，避免因为权限继承延迟导致部署报错
• 接下来配置权限自动继承：还是在组织节点的IAM配置页，给这个SA绑定你部署基础设施实际需要的项目级服务管理员角色，比如你要部署计算资源就绑roles/compute.admin，要部署GKE就绑roles/container.admin，要配存储就绑roles/storage.admin，绑定的时候一定要勾选「应用到所有子资源」选项。

  注意：这里严格按最小权限原则绑定，不要图省事直接绑项目Owner/编辑者这类宽权限角色，避免SA被攻陷后影响面过大。
  这步配置完成后，当前组织下所有存量项目会立刻继承该SA的权限，后续所有在组织下新建的项目，会在创建完成后自动从组织节点继承这部分权限，不需要任何手动操作。

• 如果你的Terraform部署逻辑里包含创建服务账号、配置IAM绑定这类操作，再额外给SA在组织级绑定roles/iam.serviceAccountAdmin即可，不需要加其他多余权限。

Bitbucket Pipeline侧适配配置 #

• 不要给这个SA生成永久JSON密钥，直接用GCP工作负载身份联邦对接Bitbucket Pipeline，做无密钥的身份认证，彻底避免密钥泄露的风险
• Pipeline里的Terraform执行流程加两个前置校验步骤，避免偶发报错：
  1. 拿到目标项目ID后，先调用GCP Resource Manager接口校验SA是否已经在该项目上继承到了需要的权限，因为新建项目的IAM继承最多有30秒左右的传播延迟，等权限校验通过后再进入plan/apply阶段
  2. 自动扫描Terraform代码里依赖的云服务API，检查目标项目是否已经启用这些API，没启用的话先触发API启用操作，等API完全生效后再跑部署
• Terraform的Google Provider配置里不要硬编码固定项目ID，用身份模拟方式直接调用这个组织级SA的权限，支持动态传入任意项目ID执行部署。

新项目创建自动触发部署的配置 #

要实现新项目创建后自动跑Terraform部署，不需要给每个项目单独配置触发器：

• 在GCP组织级配置审计日志路由，监控google.cloud.resourcemanager.v1.ProjectCreated事件，事件触发后直接向Bitbucket Pipeline发送webhook请求，把新建项目的ID、所属文件夹等信息作为参数传给Pipeline
• Pipeline接收到请求后，自动把新项目ID注入Terraform变量，调用预定义好的基础设施模板执行部署即可，全程不需要人工介入。

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