GCP云函数部署权限配置：如何避免开发者修改Owner/Editor角色？

一、核心思路：拆分权限，避免全量setIAMPolicy权限 #

直接授予roles/resourcemanager.projectIamAdmin这类带全量setIAMPolicy权限的角色，必然会让用户能修改Owner/Editor角色，所以必须拆分权限，用最小权限原则配置：

1. 云函数部署的基础权限 #

给开发者直接授予预定义角色 roles/cloudfunctions.developer，这个角色包含了云函数创建、部署、更新的全部必要权限，比如：

• cloudfunctions.functions.create / update / delete
• cloudfunctions.functions.sourceCodeSet
• 配套的GCS代码存储访问权限（无需额外配置）

2. 受限的IAM权限授予能力 #

如果必须让开发者给其他用户授予特定低权限角色（比如云函数查看者、开发者），但禁止触碰Owner/Editor这类高权限角色，用条件IAM绑定实现：

• 先创建一个自定义角色，只包含 resourcemanager.projects.setIamPolicy 权限
• 给这个自定义角色添加条件表达式，限制可操作的角色范围：
  拒绝修改高权限角色的条件：

  !(request.query.bindings.exists(binding, binding.role in ['roles/owner', 'roles/editor', 'roles/resourcemanager.projectIamAdmin']))
  

  或者更严格，只允许授予指定的低权限角色：

  request.query.bindings.all(binding, binding.role in ['roles/cloudfunctions.developer', 'roles/cloudfunctions.viewer'])
  

  这样开发者只能添加/修改你指定的角色，无法触碰Owner/Editor。

二、更简单的替代方案：拆分职责 #

如果不需要让开发者管IAM，直接让他专注云函数部署：

• 只给 roles/cloudfunctions.developer 角色，权限授予工作由你或其他高级管理员负责，彻底避免权限风险。

如果必须开放部分IAM权限，还可以用IAM Deny Policy直接拦截：
创建一个项目级的Deny Policy，针对该开发者账号，拒绝其在操作涉及roles/owner或roles/editor时执行resourcemanager.projects.setIamPolicy动作。

三、最佳实践 #

• 最小权限优先：永远只给完成工作必需的权限，别用Editor、IAM Admin这类宽泛角色。
• 定期审计：用GCP的IAM审计日志、Access Transparency功能，定期检查权限变更记录，及时修正不合理的权限配置。
• 条件IAM常态化：对需要部分IAM权限的用户，一律用条件限制操作范围，避免权限溢出。
• 禁用共享账号：每个开发者用独立IAM账号，禁止用Owner账号做日常操作。
• 渐进式授权：新开发者先给基础部署权限，后续根据实际需求逐步添加必要的IAM权限，不要一次性开全。

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