Google项目所有者为自身配置最小权限的最佳实践

首先明确第一原则：常规开发场景下禁止本地直连生产环境，所有生产变更优先走审计完备的CI/CD流水线、权限严格收敛的云堡垒机/Cloud Shell实例，本地直连仅用于紧急故障排查场景，从架构层面切断本地代码误操作影响生产的路径。

完全不需要下载长期服务账号JSON密钥，也不用手动反复加删权限，你要的「个人身份认证+会话级权限限制」能力GCP原生就支持，具体操作如下：

• 第一步先拆分权限：你自己的个人账号在生产项目里默认只绑定只读类角色，绝对不要长期挂Owner、Editor这类高权限角色，平时本地开发默认对接和生产完全隔离的开发/预演项目，从根源上避免跑错代码影响生产。
• 第二步创建专用的运维服务账号：在生产项目里单独建服务账号，只给这个账号绑定当前操作需要的最小权限角色，比如要改Cloud Storage配置就只给存储相关的操作角色，不要给全量权限。
• 第三步配置短期模拟权限：给你的个人账号绑定该服务账号的roles/iam.serviceAccountTokenCreator角色，绑定时直接加IAM时间条件，设置权限默认1-2小时后自动失效，不需要手动事后删除。
• 第四步本地会话级授权：需要操作生产的时候，执行带模拟参数的ADC登录命令：

  gcloud auth application-default login --impersonate-service-account=你的运维服务账号邮箱 --scopes=https://www.googleapis.com/auth/devstorage.read_write
  

  这种方式拿到的是短期OAuth2令牌，没有本地存储的长期私钥，令牌到期自动失去所有权限，还可以通过--scopes参数严格限制当前会话能调用的API范围，就算你误跑了其他业务的代码，超出scope的请求会直接被拦截，完全不会出现误删其他生产资源的问题。

• 不要在本地存储服务账号的JSON私钥：这类长期密钥没有过期时间，一旦本地机器被入侵、密钥被误提交到代码仓库，等于直接把生产权限暴露出去，安全风险极高。
• 不要直接用无参数的gcloud auth application-default login登录个人账号：这种方式会继承你个人账号的所有权限，你作为项目所有者，本地跑的任何代码都有生产全量操作权限，误操作风险完全不可控。
• 不要用手动加删IAM绑定的方式管控权限：人工操作很容易出现忘记回收权限的情况，长期积累会形成大量权限后门，必须用自动过期的条件绑定、短期令牌机制做管控。
• 不要在生产和开发环境共用同一个项目、同一套IAM配置：开发、预发、生产环境必须做项目级的完全隔离，本地开发的默认配置永远指向开发环境，从配置层面避免连错生产。

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