GCP国际版 谷歌云 GCP 账号机器学习权限

别再让AI工程师满世界乱窜了：GCP机器学习权限不是越宽越好，是越准越安全

你有没有见过这样的场面？——一位刚入职的AI工程师，兴冲冲打开GCP控制台，想把训练好的模型部署上线，结果点着点着，一不小心删掉了整个项目的BigQuery数据集；或者更刺激的：他顺手给自己的服务账号加了个roles/owner，然后在Notebook里敲下gcloud projects delete my-ml-project……还好有组织策略拦了一道，不然连后悔键都来不及按。

这不是段子，是我上周帮客户做权限审计时亲眼盯出来的三起真实事件。GCP的机器学习生态（Vertex AI、AI Platform、BigQuery ML）像一座功能齐全但动线复杂的科技商场——你得发对工牌，而不是直接塞一把万能钥匙。今天咱们不讲枯燥的RBAC理论，就聊人话、踩坑、给解法。

先搞清一个真相：GCP里压根没有叫“机器学习权限”的内置角色

没错，你翻遍gcloud iam roles list | grep -i ml，搜不到任何以ml.或ai.开头的预定义角色。Google很诚实：它不打包卖“AI权限”，只卖“能力积木”。比如：

• roles/aiplatform.user → 能操作Vertex AI资源（训练、部署、预测），但不能创建项目或改网络
• roles/aiplatform.admin → 可管理Vertex AI的端到端生命周期，含删除Endpoint、取消训练作业
• roles/bigquery.dataEditor → 对BigQuery表可读可写，但不等于能跑CREATE MODEL——那还得额外加bigquery.models.create权限

记住：权限不是按产品命名，而是按动作+资源类型+层级组合。比如aiplatform.endpoints.predict允许调用预测接口，但aiplatform.endpoints.delete才是删Endpoint的开关——它们可以分开放，也可以捆在一起。

实战三连问：你的ML团队到底需要哪几块积木？

问题1：让算法同学训模型，但不许他碰生产环境

典型场景：数据科学家用Vertex AI Custom Training跑PyTorch，模型存到Artifact Registry，最终由MLOps工程师部署。这时候千万别给aiplatform.admin——它默认带aiplatform.endpoints.delete，相当于给了消防斧去厨房切菜。

推荐组合：
roles/aiplatform.user + roles/storage.objectAdmin（读写训练数据桶） + roles/artifactregistry.reader（拉取基础镜像）
再加一条自定义权限：aiplatform.customJobs.create 和 aiplatform.customJobs.get —— 仅限创建/查自己发起的训练任务，别人任务看不见。

小技巧：用resourceAttributes.resourceType == "aiplatform.googleapis.com/CustomJob"配合条件表达式，锁定只能操作labels.team == "research"的作业。

问题2：数据工程师要建BigQuery ML模型，但不能导出用户表

很多人以为bigquery.dataEditor够用了，结果这位同事顺手写了EXPORT DATA OPTIONS(format = 'CSV') TO 'gs://leak-bucket/users.csv'……

解法分两步：
① 收回bigquery.jobs.create的全局权限，改为绑定到特定数据集：
bigquery.datasets.get, bigquery.tables.getData, bigquery.models.create —— 全部限制在projects/my-proj/datasets/ml_training
② 在组织层级启用constraints/iam.allowedPolicyMemberDomains，强制所有服务账号邮箱必须来自@mycompany.com，堵死个人Gmail绑定的后门。

问题3：运维要监控模型延迟，但绝不能重启API服务

Vertex AI Endpoint自带Cloud Monitoring Viewer角色？太松！它能看所有指标，包括那些不该暴露的——比如vertexai.googleapis.com/endpoint/request_count可能泄露业务量峰值。

精准方案：
新建自定义角色，只含：
monitoring.timeSeries.list（限定时间序列前缀：vertexai.googleapis.com/endpoint/latency）
logging.logEntries.list（过滤resource.type="aiplatform.googleapis.com/Endpoint" AND severity>=WARNING）
再配上resourcemanager.projects.get——只为显示项目名，不给resourcemanager.projects.list（否则能扫全公司项目）。

GCP国际版 三个必踩的权限雷区（附避雷口诀）

• 雷区1：用roles/editor代替ML专用角色
  口诀：“Editor=编辑器，不是AI助理。它能删Cloud Storage桶，但不会写TensorFlow。”
• 雷区2：给服务账号加roles/iam.securityAdmin
  口诀：“安全管理员权限≈给你造钥匙的模具。除非你是IAM架构师，否则请绕行。”
• 雷区3：在项目级授予权限，却忘了组织级约束已禁用某些API
  口诀：“项目说‘可以’，组织说‘不行’——就像孩子说能吃糖，家长早把糖罐锁了。”

一键自查：三行命令揪出危险权限

把下面命令复制进Cloud Shell，5秒出报告：

# 查所有带‘delete’的ML相关权限
gcloud projects get-iam-policy my-proj --flatten="bindings[].members" --format="table(bindings.role, bindings.members)" --filter="bindings.role:aiplatform OR bindings.role:bigquery" | grep -i delete

# 查哪些账号拥有跨项目访问权限
gcloud projects get-iam-policy my-proj --flatten="bindings[].members" --format="json" | jq -r '.bindings[] | select(.role | contains("aiplatform") or .role | contains("bigquery")) | .members[]' | grep @

# 检查是否有服务账号被授予owner
gcloud projects get-iam-policy my-proj --flatten="bindings[].members" --format="table(bindings.role, bindings.members)" | grep owner

发现高危项？别急着删——先用gcloud projects test-iam-permissions模拟验证影响范围。比如：
gcloud projects test-iam-permissions my-proj --permissions=aiplatform.endpoints.delete,aiplatform.models.delete

最后送你一张权限速查表（打印贴工位）

权限设计的本质，不是筑墙，而是修路——让对的人，在对的时间，走对的路，拿对的东西。下次再有人问“给我个ML权限”，别急着点授权按钮，先问他一句：
“你想动哪块砖？模型？数据？还是API网关？——我给你配一块刚好卡住的。”