GCE 服务账号权限怎么排查？IAM、访问范围与应用身份
VM 内应用访问 Google Cloud API 失败时，先确认实际身份，再核对 IAM 角色、访问范围和目标资源策略。
需要梳理你的部署与运维需求？联系 @ak6793 ↗
先确定应用究竟用了谁的凭据
记录 VM 所在项目、附加服务账号和目标 API。应用可能使用环境变量指向的凭据文件，也可能从元数据服务取得实例身份。CLI 当前登录用户又可能与应用身份不同。先观察错误中的主体和日志，区分执行命令的账号与应用访问资源的账号，再制定最小范围的修复。
检查目标资源上的 IAM 授权
列出应用真正需要执行的动作，例如读取某个存储桶内对象。把对应权限授予应用服务账号，并尽可能收敛到目标资源。跨项目访问时，应在资源所在项目或资源级策略中确认授权。权限边界、IAM 拒绝策略和组织限制也可能影响结果，保留错误码与请求时间便于审计。
再检查实例访问范围
Compute Engine 的访问范围会影响使用实例凭据访问 API 的请求。官方建议的常见配置是使用 cloud-platform 范围，再用 IAM 角色控制资源权限。已有 VM 可能带有限制性范围，即使角色包含所需权限，请求仍可能失败。检查现有范围和具体客户端行为后，再按官方流程安排修改及维护窗口。
把部署者的 actAs 与应用权限分开核对
将某个服务账号附加到 VM，需要部署者具备相应的服务账号使用权限。这个步骤决定谁能让 VM 使用某个身份。应用启动后的 API 调用，则取决于服务账号自己的资源权限。排查创建失败时先看 actAs 相关错误，排查运行失败时再看应用主体和目标 API。
用一次具体请求验证修复
从 VM 上执行应用实际需要的一次读取或写入，记录目标资源和脱敏结果。确认成功后移除为排查临时增加的权限，并继续观察审计日志。避免给共享默认服务账号持续叠加宽泛角色，因为同一身份可能被多台 VM 使用。为每个工作负载记录身份、用途、授权范围和责任人，便于后续迁移。