Google工作负载身份联合集成Azure DevOps部署权限异常排查

• 检查Azure DevOps任务的凭据隔离配置
  确保两条流水线的GCP身份验证任务是独立配置的，别共享同一组变量或任务模板。要是用了模板，得确认模板里没硬编码SA1的参数，变量也正确覆盖了。每条流水线的任务里要明确指定对应服务账号的完整邮箱，别依赖默认值或全局变量。

• 验证GCP令牌生成的上下文隔离
  在每条流水线的GCP身份验证步骤里，加个显式清理环境变量的操作：

  unset GOOGLE_APPLICATION_CREDENTIALS
  unset GOOGLE_OAUTH_ACCESS_TOKEN
  

  别让流水线共享代理池的缓存，或者把代理池设成每次任务后清理环境。用自托管代理的话，要确保代理每次任务结束后重置环境变量和缓存文件。

• 检查工作负载身份联合的模拟权限配置
  确认用于模拟的管理服务账号，同时对SA1和SA2都有roles/iam.serviceAccountTokenCreator权限，而且权限绑定没限制特定的Azure DevOps主体。另外也要检查SA2的IAM绑定，确保它确实有目标存储桶的storage.objects.list权限，别把权限不足误当成身份复用问题。

• 调整令牌生成命令的参数
  获取GCP令牌时，除了--force，还要指定完整的模拟服务账号邮箱，加--token-format=access_token，并且显式指定输出文件，避免覆盖：

  gcloud auth print-access-token --impersonate-service-account=SA2@your-project.iam.gserviceaccount.com --force --token-format=access_token > sa2_token.txt
  

  后续部署任务里明确用这个令牌文件，别依赖gcloud的默认凭据缓存：

  gcloud functions deploy ... --access-token-file=sa2_token.txt
  

• 排查Azure DevOps变量的作用域
  检查流水线变量是不是设成了全局作用域，导致SA1的变量值被SA2的流水线继承。确保每条流水线的变量是流水线级别的私有变量，或者在任务里直接指定参数，别依赖变量。

• 检查gcloud工具的版本和缓存行为
  把gcloud更到最新版本，旧版本可能有凭据缓存的bug。在身份验证步骤前，执行gcloud config unset auth/impersonate_service_account，清除之前的模拟配置。

内容的提问来源于stack exchange，提问作者Mohan Rana