谷歌云优惠券 GCP谷歌云代理商主子帐号管理

一、别把GCP账号当QQ号：主子账号不是‘小号’，是基建底座

很多刚接手GCP代理业务的小伙伴，第一反应是：“主账号开个子账号，发给客户不就完事了？”——然后三天后收到客户截图：‘为什么我登上去看不到项目？’‘我的账单怎么跑他那边去了？’‘我删了个VM，怎么整个VPC都飘红了？’

醒醒，GCP不是微信小号切换界面。它的主子账号体系，本质是一套基于IAM（Identity and Access Management）+ Resource Hierarchy（资源层级）+ Billing Domain（计费域）三权分立的精密治理系统。主账号不是‘爸爸’，而是‘持证上岗的物业经理’；子账号不是‘儿子’，而是‘经备案、有工牌、限区域、领预算的外包团队’。

谷歌云优惠券 1.1 主账号 ≠ 账号Owner，而是Organization Owner

在GCP里，真正管天管地的不是你邮箱后缀为gmail.com的那个‘主号’，而是你花了$100注册并完成KYC认证后，由Google签发的Organization Resource。它才是整个云环境的‘宪法’。所有项目、文件夹、结算账户，都必须挂靠在这个Organization之下。而所谓‘主账号’，只是第一个被授予roles/resourcemanager.organizationAdmin角色的用户——说白了，就是第一个拿到管理员工牌的人。换人？只要新员工有这个角色，旧主号立马变路人。

1.2 子账号≠新建Gmail，而是‘受控身份’

国内代理商常犯的错：用客户自己的Gmail注册GCP，再塞进自己Organization。结果客户某天改密码、停用账号、甚至注销Gmail——你的生产环境直接‘失联’。正解是：所有子账号必须由代理方统一创建并托管的Service Account或Managed Service Identity（MSI），配合SCIM同步或Cloud Identity批量导入。客户看到的，只是一个带水印、限登录IP、自动过期的‘工作台入口’，背后没有真实Gmail依赖。

二、三层嵌套不是炫技，是生存刚需

GCP资源层级不是扁平列表，而是洋葱结构：Organization → Folders（可选）→ Projects → Resources。代理模式下，这三层必须焊死，否则一个客户误删项目，全盘崩塌。

2.1 Folder层：客户的‘虚拟机房’

别跳过Folders！它是代理商业务隔离的黄金分割线。比如：Folder ‘客户A-生产环境’下挂3个项目（prod-us, prod-eu, prod-backup），Folder ‘客户A-测试环境’下挂2个项目（dev, staging）。每个Folder单独绑定Billing Account，单独设IAM Policy。客户提‘我要删测试环境’，你只需删Folder，而非手抖删Project——后者可能顺带干掉Billing关联，导致历史账单丢失。

2.2 Project层：最小交付单元，但绝不裸奔

每个Project必须满足三个铁律：
① 禁用默认服务账号（default compute service account）——它自带Editor权限，是最大安全漏洞；
② 强制启用Cloud Asset Inventory——每天自动扫描谁改了防火墙、谁开了公网IP、谁绑定了高危角色；
③ 所有API必须白名单启用——别信‘先全开再收敛’，GCP里API开启=权限开放，Storage API开着，等于把S3桶门虚掩着。

三、Billing Account：钱袋子不能共用，但得能查账

国内代理最头疼的环节：客户想看自己花了多少钱，又不想让他碰你的主结算账户。解决方案不是‘给他看后台’，而是‘给他造一个透明的钱袋子’。

3.1 分账不靠截图，靠Billing Subaccount

GCP原生支持Billing Account分账。你作为代理，创建一个主Billing Account（绑你公司对公账户），再为每个客户生成独立的Billing Subaccount（需GCP Enterprise Agreement支持）。客户登录后，在Billing页面只能看到自己的Subaccount消费明细、预算告警、导出CSV——连你主账单的总金额都看不到。更狠的是：你可以设置‘超额冻结’，比如客户预充5万，花到4.8万自动暂停其所有付费API调用，不关实例，只锁计费链路。

3.2 避开‘共享结算卡’陷阱

千万别图省事，让多个客户共用一张信用卡！Google会把所有消费记在主卡名下，一旦某个客户欠费，整张卡被冻结，其他客户全部断服。正确姿势：每个Subaccount绑定独立虚拟卡（通过GCP Partner Advantage Program申请），或对接第三方Billing SaaS（如Zuora）做二次分账。

四、实操避坑清单：血泪换来的10条军规

• 禁止用主账号直接建项目——所有项目必须通过Terraform或gcloud CLI，指定--organization=xxx --folder=yyy创建，人工点击=埋雷
• 客户离职？立刻回收其Access Context Manager访问级别——别只删IAM，要进BeyondCorp控制台关掉设备信任链
• 所有子账号密码策略强制：90天轮换+MFA+设备合规检测——GCP本身不强管密码，靠Access Context Manager兜底
• 禁用‘Project Owner’角色——换成自定义角色：只放compute.instances.stop/start，砍掉delete、setIamPolicy等核按钮
• 每天凌晨执行‘僵尸资源扫描’——用Cloud Scheduler触发Cloud Function，查30天无流量的Load Balancer、7天未读取的BigQuery表，自动邮件预警
• 客户要‘完全自主’？给他一个Locked-down Cloud Shell——预装受限kubectl+gcloud，PATH只含/bin/sh和/app/bin，连git clone都不让
• 别信‘已授权’，要验‘实时权限’——用Policy Troubleshooter工具输入用户+资源+权限，秒出拒绝原因，比翻IAM日志快10倍
• 所有API调用必须打Tag——比如‘env:prod’, ‘team:customer-A’, ‘cost-center:2024-Q3’，方便Billing报表钻取
• 客户交接？导出不是截图，是terraform state + IAM binding清单 + Billing Subaccount ID——交接包里少一项，后续扯皮三个月
• 最后也是最重要的：每季度做一次‘权限熔断演练’——随机挑一个子账号，临时撤回其所有角色2小时，看监控告警是否触发、客户是否感知、恢复流程是否5分钟内闭环

五、写在最后：账号管理不是IT运维，是客户信任契约

当你把一个GCP子账号交到客户手上，你交付的不是一组API密钥，而是一份数字世界的《物业管理公约》：哪些门能开、哪些窗能开、水电费怎么算、装修要报备、紧急情况找谁。主子账号管理做得糙，轻则客户投诉‘你们云不稳’，重则因权限越界引发数据泄露，赔钱都是小事，ISO27001认证直接黄掉。

所以，下次配置子账号前，请默念三遍：
‘我不是在开账号，是在签合同；
我不是在配权限，是在划边界；
我不是在省时间，是在买安心。’
——毕竟，客户续费时，不会因为你多开了一个Project而感动，但一定会因为你没让他误删生产库而续三年。