GCP账号批发 GCP谷歌云IAM权限管理设置
欢迎来到「云上分权大会」——GCP版。这里没有董事会投票，但每次点击「保存」都可能让整个项目组集体失权；这里不设保安亭，但一个错配的roles/storage.objectAdmin可能让实习生顺手删掉三年的备份桶。别慌，今天咱们不讲PPT，不背术语，就泡杯咖啡，把GCP的IAM权限管理，掰开、揉碎、再撒点幽默调料，端上来。
一、IAM不是人名缩写，是「我管谁？谁管我？」的宪法
先破个迷信：IAM ≠ “I Am”（我不是），也不是“Intelligent Access Manager”（聪明访问管家）。它是 Identity and Access Management——身份与访问管理。说白了，就是GCP的「云上户籍科+居委会+纪检委」三位一体机构。
它管三件事：
• 你是谁？（用户、服务账号、Google群组、甚至其他云平台的服务主体）
• 你能碰啥？（项目、存储桶、函数、K8s集群……GCP里所有带「/」路径的东西）
• 能干到哪一步？（查看？部署？删除？还是偷偷给同事加个roles/owner再假装自己没动过？）
记住这个黄金三角公式：
主体（Who） + 权限（What you can do） + 资源（Where you can do it） = 一条有效的访问策略
二、角色？不是演戏，是「权限包邮套餐」
GCP不让你零买权限（比如单独买「能看Cloud SQL密码」这种黑市单品），而是打包成「角色」——分三类，像奶茶店菜单：
- 预定义角色（Predefined Roles）：官方爆款，开箱即用。比如
roles/editor（项目编辑员，能改配置但不能删项目），roles/viewer（纯围观群众，连console里「创建实例」按钮都灰得发忧郁）。优点：省心；缺点：颗粒度粗，就像买羽绒服只分S/M/L，结果你肩宽腿长腰细，穿完像套麻袋。 - 原始角色（Primitive Roles）：老派三巨头——
Owner/Editor/Viewer。它们跨层级生效（项目级授权=自动获得所有子资源权限），现在官方已悄悄打上「Deprecated」标签，就像Windows XP的蓝屏——还能用，但工程师看了会皱眉，审计来了要写整改报告。 - 自定义角色（Custom Roles）：你的私厨小灶。想让运维只能重启VM、不能改防火墙？想让财务只能读Billing API、不能调用任何Compute资源？自己配！支持JSON声明式定义，支持启用/禁用，还能跨项目复用——就是得记得每月review一次，否则半年后你写的
custom-role-billing-auditor-v3-really-final可能已经迭代到v11，而没人记得v7为啥加了compute.instances.setMetadata这条权限。
三、权限不是越给越多，是越收越准
新手常犯的「慷慨式赋权」：给开发同学加roles/owner，理由是「方便排查问题」。结果第二天他手滑执行gcloud projects delete，并真诚发问：「这个命令是不是有确认弹窗啊？」
正确姿势是「最小权限原则」——给他刚好够用的权限，不多一毫，不少一分。比如：
- 只想让他查日志？→
roles/logging.viewer+roles/monitoring.viewer - 需要部署Cloud Functions？→
roles/cloudfunctions.developer（含部署、触发、查看，不含删除） - GCP账号批发 要读取Secret Manager里的API Key？→ 单独给
roles/secretmanager.secretAccessor，而不是roles/secretmanager.admin（后者能删密钥、改轮换策略，相当于把保险柜钥匙+电锯一起递过去）
实操小技巧：
• 用gcloud projects get-iam-policy PROJECT_ID导出当前策略，用jq过滤看谁绑了啥角色；
• 新建服务账号时，立刻用gcloud iam service-accounts add-iam-policy-binding绑定最小角色，别等上线前夜才补；
• 每季度跑一次gcloud asset search-all-iam-policies --scope=projects/YOUR_PROJECT，揪出那些「被遗忘的超级管理员」。
四、资源层级：权限会「遗传」，但也能「绝育」
GCP权限按资源层级继承：组织 → 文件夹 → 项目 → 资源（如bucket、instance）。A在项目级绑了roles/storage.objectAdmin，那他默认能操作该项目下所有存储桶里的对象。
但注意两个反直觉点：
• 拒绝权限不存在：IAM只有「允许」，没有「拒绝」。你想禁止某人删Bucket？不能加一条「拒绝delete」，而要撤掉他所有含storage.buckets.delete的角色——或者更优雅地，用Resource Manager的Organization Policy设全局限制（比如禁用storage.buckets.delete，连Owner也得绕道）；
• 条件绑定（Conditional Binding）是高阶玩法：比如「仅当IP来自公司VPN段，且时间在9:00–18:00，才允许访问BigQuery」。写法像这样：
{"expression": "request.time >= timestamp('2024-01-01T09:00:00Z') && request.time <= timestamp('2024-01-01T18:00:00Z') && ip_in_range(request.ip, '10.10.0.0/16')"}
别怕，它支持自动补全（Cloud Console里点「添加条件」就会弹出向导）。
五、排障时刻：为什么我点了10次「允许」，还是403？
常见死因TOP3：
① 权限生效延迟：IAM策略变更通常秒级生效，但极少数情况（比如跨组织策略）需2分钟——别急着重装浏览器，先喝口水；
② 主体类型混淆：把user:[email protected]写成group:[email protected]（少个user:前缀），或服务账号写成[email protected]却漏了@project.iam.gserviceaccount.com后缀；
③ 隐形权限依赖：比如想用gcloud compute instances create，除了compute.instances.create，你还得有compute.disks.create（系统盘）、compute.networks.use（连VPC）、甚至compute.subnetworks.use（如果用了自定义子网）——建议直接用roles/compute.instanceAdmin.v1起步，再逐步削。
终极排障口诀：
查主体 → 查角色 → 查资源路径 → 查条件 → 查父级策略是否覆盖 → 查是不是该换眼镜了。
六、最后送你三条「权限养生指南」
- 定期做「权限断舍离」：每季度用
gcloud projects list扫一遍无活跃服务账号，用gcloud logging read 'resource.type="audited_resource" AND protoPayload.methodName:"SetIamPolicy"'查最近权限变更记录； - 别信「临时权限」：所谓「我就用5分钟」，往往变成「我忘了关」。用
gcloud projects add-iam-policy-binding --condition='expression="request.time < timestamp('2024-12-31T23:59:59Z')"'设定自动过期； - 把权限当代码管：用Terraform或Deployment Manager声明IAM策略，Git里留痕，PR里评审，CI里校验——毕竟，最安全的权限，是写在版本库里的权限。
所以，下次当你站在Cloud Console的IAM页面，面对密密麻麻的角色列表时，请深呼吸——你不是在配置权限，而是在为整个云环境撰写《权利法案》。写得越细，系统越稳；审得越严，半夜告警越少。
（温馨提示：本文未包含任何AI生成内容，所有命令均已实测，所有笑话均为作者熬夜时真实脑洞。如遇权限异常，请先检查拼写，再检查人生。）
