谷歌云大额代付 GCP Workload Identity 配置无效：谷歌云 K8s ServiceAccount 关联 IAM 报错定位

这类报错，表面上看是“Workload Identity 没生效”，实际排查下来，真正卡住的往往不是 YAML，而是账号、权限、账单、项目状态。

我遇到过很多类似场景：用户已经把 K8s ServiceAccount 绑定好了，也在 IAM 里加了角色，但 Pod 还是拿不到 GCP 凭证，常见表现是 403、permission denied、token exchange failed、service account not found。如果你现在卡在这里，先别盯着代码改，先看账号和项目是否真的能正常工作。

一、先判断：这是技术配置问题，还是账号层面已经出问题

很多人一上来就改 ServiceAccount 绑定，但如果你的 GCP 账号本身有下面这些情况，Workload Identity 再怎么配也会失败：

Billing 没开通或已停用：项目处于欠费、暂停、未绑定账单的状态，GKE 相关 API 和 IAM 变更可能不稳定。
项目权限不完整：你只有项目查看权限，没有 iam.serviceAccounts.setIamPolicy 或对应 Owner/Editor 权限。
账号风控未过：新注册账号、异地登录、频繁切换付款卡，可能导致 IAM 操作能点但不真正生效。
你拿到的是转售/代开账号：Billing Owner 不在你手里，后面一改支付方式或变更联系人，就容易被锁。

实操建议：如果你是企业环境，先确认“项目所有权、账单所有权、IAM 管理权”三件事都在同一个组织里，不然后续排障会反复绕圈。

二、最常见的 4 类报错，分别对应什么问题

现象	大概率原因	优先检查项
`403 iam.serviceAccounts.getAccessToken denied`	GCP Service Account 没授予 `roles/iam.workloadIdentityUser`	IAM 绑定是否绑到正确 GSA、namespace、KSA
`invalid resource name`	项目编号、项目 ID、命名空间拼错	是否把 `PROJECT_NUMBER` 和 `PROJECT_ID` 混用了
Pod 里还是拿到节点身份	集群没有真正启用 Workload Identity，或旧 Pod 没重建	集群 workload pool、节点池、重启策略
配置都对，但日志里没有 token exchange	KSA 注解缺失，或注解在错误的 namespace	kubectl 里的 ServiceAccount 名称是否一致

三、按这个顺序查，最快

不要先改十几处配置，按下面顺序排，通常 10 分钟内能定位到问题点。

# 1) 看集群是否真的开了 Workload Identity
gcloud container clusters describe CLUSTER_NAME \
  --region REGION \
  --project PROJECT_ID \
  --format="value(workloadIdentityConfig.workloadPool)"

# 2) 检查 KSA 是否有注解
kubectl get sa KSA_NAME -n NAMESPACE -o yaml

# 3) 绑定 GSA 权限
gcloud iam service-accounts add-iam-policy-binding GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \
  --project PROJECT_ID \
  --role roles/iam.workloadIdentityUser \
  --member "principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/KSA_NAME"

# 4) 给 KSA 打注解
kubectl annotate serviceaccount KSA_NAME -n NAMESPACE \
  iam.gke.io/gcp-service-account=GSA_NAME@PROJECT_ID.iam.gserviceaccount.com --overwrite

# 5) 重建 Pod，让新身份生效
kubectl rollout restart deploy/DEPLOY_NAME -n NAMESPACE

注意一个高频坑：很多人 IAM 绑定写对了，但把 PROJECT_NUMBER 写成了 PROJECT_ID，结果看起来“配置都提交成功”，实际 token 交换根本对不上。

四、如果你是刚买账号、刚做实名，问题可能不在 Kubernetes

从实际处理经验看，新账号的风控和支付状态，往往比 Workload Identity 本身更影响排障效率。

个人卡 vs 企业卡：个人卡通过率高不代表后续稳定，企业卡更适合长期项目，但首次验证更慢。
实名资料不一致：账号注册国家、付款卡归属地、企业证件地址不一致，容易触发审核。
首次扣费失败：GCP 很多场景不是“先充值再用”，而是先绑卡、后计费；首笔验证失败会影响项目可用性。
频繁换卡/换主体：这类操作容易让账单账户进入人工审核，期间 IAM 改动和资源创建都可能受限。

如果你现在是“账号刚开好，GKE 也刚建好”，建议先确认账单页状态正常，再去看 Workload Identity。很多“403”其实是项目已经被暂停，只是错误信息没有直接告诉你。

五、支付方式和风控：这部分会直接影响你能不能继续调试

GCP 国际站常见支付方式还是信用卡/借记卡，企业场景通常会走更正式的账单主体或渠道。实际项目里我见过不少案例：

谷歌云大额代付 卡本身可用，但 3DS 验证失败，导致账单授权没通过。
同一张卡短时间绑定多个账号，触发支付风控。
账号刚开就频繁创建/删除项目，触发资源风控，API 权限不稳定。
企业账号资料没补全，后面做 Service Account 变更时被要求补税务/法人信息。

实用建议：如果你的目标是尽快把 GKE 跑起来，不要把测试环境和正式账单账户混在一起。单独建一个测试项目，能省掉很多“权限明明对，但系统就是不放行”的时间。

六、成本怎么控：别为了查一个权限，烧掉一整天预算

Workload Identity 本身不直接收费，但你为了验证它，通常要开 GKE、Pod、节点池、日志，这些都会计费。实际排查时，成本最容易超的是：

GKE Standard 长时间空跑：节点不小心留着，一天就会持续计费。
日志和调试输出过多：大量拉取日志、开启更高采样，账单涨得很快。
谷歌云大额代付 测试项目没有关停：很多人问题解决了，集群和节点池忘了删。

如果只是验证 Workload Identity，通常一个小规格节点池就够了；如果你们团队经常做权限联调，建议固定一个低成本测试项目，不要在生产项目里反复试错。这样一来，账单可控，风控也更稳定。

七、我建议你优先做的 3 个动作

先查账号和账单状态：确保项目没停、支付没失败、权限是你自己的。
再查绑定链条：KSA 注解、GSA IAM 绑定、namespace、项目编号逐项核对。
最后重建 Pod：不重启，很多旧身份缓存不会自动刷新。

如果你现在是在企业采购流程里，还没正式把 GCP 账号落到自己名下，先别急着做生产配置。账号归属不清，后面排查 IAM 问题会非常被动。

FAQ：常被问到的几个点

Q1：绑定都成功了，为什么 Pod 还是 403？
A：大概率是 Pod 没重建，或者 KSA 注解和命名空间不一致。先重启工作负载，再看日志。

Q2：能不能用“买来的账号”直接做生产？
A：不建议。只要 Billing Owner、IAM Owner 不在你自己手里，后面一旦风控、续费或审计，项目会非常被动。

Q3：实名审核会影响 Workload Identity 吗？
A：会。尤其是新账号、企业资料未完善、支付验证失败时，项目创建和 IAM 变更都可能受影响。

Q4：怎么判断是 GCP 问题还是我集群配置问题？
A：先看账单和项目状态，再看集群 workload pool，最后才是 KSA/GSA 绑定。顺序反过来，通常会浪费很多时间。

如果你愿意，我可以下一步直接给你一份“Workload Identity 逐项排查清单”，按命令行一步一步定位到是哪一行配置错了。