北京
如果你为 Vertex AI 配置了服务账号，发出一次预测请求并收到了 200 状态码，就认为鉴权任务已经完成，那你就只验证了一件事——这个账号能做你希望它做的事。但你漏掉了更关键的一点：它是否也能做你不希望它做的事。这两个命题在安全领域完全不等价，混为一谈会悄悄埋下权限过高的暗雷。
一次成功的调用只能证明调用者绑定了包含所需权限的角色，却无法衡量这个角色赋予的权限上限。拥有 roles/aiplatform.admin 角色的账号同样能通过你的预测请求，同时还能删除推理端点、读写 Vertex AI 资源的 IAM 策略，甚至直接启动批量作业。在“请求通过”这条标准下，两种配置看上去都一样绿灯放行，但实际风险截然不同。
真正能让这种差异浮出水面的，是一套由两个调用组成的验证协议：一个允许执行的合法调用，另一个故意设计为应被拒绝的调用，并且每个调用都预设了明确的预期状态码。这套方法并不是 Google 官方文档中记载的标准化流程，而是一种工程实践。通过同时观察“能做什么”和“不能做什么”，你才能开始逼近最小权限。
那么，一次成功的调用到底证明了什么？它只证明了授权配置的“足够性”，却对“最小性”三缄其口。Google Cloud 的官方安全建议（截至 2026 年 7 月 18 日）明确指出：应当为每个任务分配最受限的预定义或自定义角色，尽量在最低资源层级应用权限，并为不同组件分别创建服务账号。单个绿色调用的通过远不足以成为 least privilege 的证据，它只是权限审计链条中的一个必要环节，不该是终点。
忽略这一点的代价很现实。权限过宽的服务账号在日常运行中不造成任何报错，单元测试全部通过，CI 管道绿得晃眼。直到被安全审计发现，或者更糟——在一次事件中被滥用，你才意识到它们已经在系统中静默存在了数月。错误的授权方案要么在代码审核阶段被拦下来，直接拖慢上线节奏；要么悄然渗透进生产环境，形成长期可见却不可感的过度访问。
还有一个小众但值得留意的场景：如果你的部分请求通过外部兼容通道发送，比如通过 provod.ai 这类第三方路由（类似俄罗斯版的 OpenRouter），鉴权逻辑就转变为基于 API 密钥的模式，与 Google Cloud 的 IAM 体系完全脱钩。这条路径不会替你检验服务账号权限是否最小化，也不应该期望它去检验。对于混合鉴权场景，需要专门厘清两种模型之间的差别。
至于 Vertex AI 的各项预定义角色，哪些配得上“最小”，哪些又天生带着多余的翅膀，则需要打开 aiplatform.* 权限空间仔细审视。这份审视的起点，就是拒绝把一次 200 响应当作权限安全的终点。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
