Google Cloud 子账号与 IAM 权限管理新手指南

现在这年头，企业不用云服务简直没法运转，Google Cloud Platform (GCP) 在数据分析和机器学习这块儿确实有两把刷子。但团队一扩大，麻烦就来了：权限怎么分？直接把主账号密码扔给同事？别，这可是安全大忌。可要是给每个人都单独开个云服务商账号，实名认证、绑海外支付方式这些流程，想想都头大。这时候，Google Cloud 的 IAM（身份与访问管理）系统就派上用场了。简单说，它能让你在一个主账号底下，精细控制“谁”能对“哪些东西”做“什么操作”。

咱们今天就来聊聊怎么玩转 GCP 的子账号和 IAM 权限，帮你搭一个既安全又灵活的云资源管理框架。

搞懂三个核心：身份、资源和角色

动手之前，得先明白 IAM 靠什么运转。就三样东西：身份（Who）、资源（What）和角色（How）。

身份，说白了就是谁要访问。可能是具体的人（用 Google 邮箱登录），也可能是应用程序专用的服务账号（比如跑在虚拟机上的程序），甚至可以把一群人打包进一个 Google 群组，统一授权，省事儿。要是公司用了多云环境，还能通过“工作负载身份联邦”让外部身份（比如 Azure AD 的用户）直接访问 GCP。
资源，就是你要保护的那些云资产，比如一台虚拟机、一个存文件的存储桶，或者一个 BigQuery 数据集。
角色，定义了具体能干什么。GCP 有几种角色：基本角色（像 Viewer、Editor）权限太宽，生产环境最好别用；预定义角色是推荐选项，比如只让看存储桶文件但不能改，就有专门的 roles/storage.objectViewer 角色；如果这还满足不了你，那就自己定制一个角色，把需要的权限组合起来。
动手实操：给新同事开个只读权限

光说不练假把式。假设新来一位数据分析师，需要他能查 BigQuery 数据，但不能修改。一步步来：

第一步，进 Google Cloud Console，找到 IAM 和管理 -> IAM。点右上角的 授予访问权限，把同事的 Google 邮箱填进去。选角色的时候，在菜单里找到 BigQuery -> BigQuery 数据查看者，这个角色正好符合“只读”要求。加个备注说明用途，以后好查账。保存之后，对方会收到邮件邀请，接受就能用了。

别忘了这些好习惯

单个授权简单，但要管得好，得记着几个原则：

最小权限是黄金法则——只给够用的权限，别图省事扔个 Editor 角色了事。比如管虚拟机的人，给 roles/compute.instanceAdmin 就比 Editor 安全多了。

人多了就用群组管理。如果有十个数据分析师，别一个个加权限。建个 Google 群组（比如 data-analysts@your-company.com），把人都加进去，然后一次性把角色赋给整个群组。以后有人进出，动群组就行了，IAM 策略不用改。

应用别用人账号。跑程序需要访问 GCP 服务？专门开个服务账号，给它最小权限。比如备份程序，给个管理特定存储桶的角色就够了。

复杂情况怎么办？项目、文件夹和组织

资源多了，可能分在不同项目里，甚至需要整个公司层面管控。IAM 也能应对：

项目是最常见的权限边界，比如开发、测试环境各放一个项目，权限分开管。如果项目多了（像“电商事业部”底下有前端、后端项目），可以把它们塞进一个文件夹，在文件夹层级设权限，底下所有项目都继承。组织是最高层级，在这设的策略（比如强制开启安全设置），对所有文件夹和项目都有效。所以高层级授权要格外小心，权限是会继承的。

安全与效率怎么平衡？

权限管得太细，安全是上去了，管理成本也高了。比如临时和外部合作，对方要是卡在支付或实名验证上，项目进度可能就拖慢了。有些团队会找靠谱的云服务合作伙伴，通过他们开独立的云账号。这样权限管理就“外部化”了——不用在主账号下分角色，直接给对方一个独立账号，风险隔离了，财务和项目管理也简单点。当然，选第三方平台，稳定可靠肯定是第一位的。

说到底，掌握 Google Cloud IAM 就像给云资源装了套智能门禁。从小团队授权到公司级框架，它都能支撑。核心就是最小权限，善用群组和层级，定期检查权限使用情况。一个好的权限体系，不仅是安全防线，更是团队高效协作的基石。现在就去你的 Cloud Console，试试给同事分配第一个精确角色吧。