TokenRequest API 为何无法跨集群复用 ServiceAccount Token？

Question

**问题：** 为何通过 Kubernetes `TokenRequest` API 生成的 ServiceAccount Token 无法在其他集群中复用？ 根本原因在于该 Token 是**签名绑定且上下文强耦合**的：1）Token 由目标集群的 `kube-apiserver` 使用其私钥（如 `--service-account-key-file` 指定）签名，其他集群无对应公钥验证；2）Token 的 JWT payload 中明确嵌入了签发集群的 `audience`（默认为 `kubernetes.default.svc`）、`iss`（如 `kubernetes/serviceaccount`）及 `kubernetes.io/serviceaccount/namespace` 等字段，跨集群时 audience 不匹配、issuer 不可信、命名空间上下文失效；3）`TokenRequest` 还可注入动态绑定的 `expirationSeconds` 和 `bound CIDR`（若启用），进一步限制重放与范围。因此，该机制本质是为单集群零信任环境设计的短期、可撤销、上下文感知凭证，而非通用 bearer token。跨集群身份联邦需改用 OIDC 联合认证或外部身份提供者（如 Dex、Keycloak），而非复用 `TokenRequest` Token。

Answer 1

```html

一、现象层：为何“复制粘贴 Token”在跨集群场景下直接失败？

开发者常尝试将某集群中通过 TokenRequest API 获取的 ServiceAccount Token（如 curl -X POST https://cluster-a/apis/authentication.k8s.io/v1/tokenreviews）直接用于访问 cluster-b 的 API Server，结果收到 401 Unauthorized 或 invalid bearer token 错误。这不是网络或 RBAC 配置问题，而是设计使然——Kubernetes 明确拒绝“跨集群复用”。

二、协议层：JWT 结构暴露强上下文绑定

解码一个典型 TokenRequest 生成的 JWT（如使用 jwt.io），其 payload 包含以下关键字段：

• "aud": ["kubernetes.default.svc"] —— audience 严格限定为签发集群的默认服务 DNS 名
• "iss": "kubernetes/serviceaccount" —— issuer 无全局唯一性，不携带集群标识
• "kubernetes.io/serviceaccount/namespace": "default" —— 命名空间上下文硬编码
• "exp": 1735689200 —— 动态过期时间（由 expirationSeconds 控制）
• "boundCIDRs": ["10.244.0.0/16"] —— 若启用 ServiceAccountTokenVolumeProjection 并配置 CIDR 绑定，则校验源 IP 范围

三、安全层：签名密钥隔离与零信任模型

Kubernetes 不采用共享密钥体系，每个集群独立管理其服务账户签名密钥：

集群	--service-account-key-file	公钥分发方式	能否被其他集群验证？
Cluster-A	/etc/kubernetes/pki/sa.key	仅本地 kube-apiserver 加载	❌ 否（Cluster-B 无对应公钥）
Cluster-B	/etc/kubernetes/pki/sa.key（不同内容）	同上，完全隔离	❌ 否（无法验证 Cluster-A 签名）

四、架构层：TokenRequest 是“单集群会话凭证”，非“联邦身份令牌”

下图展示 TokenRequest 的生命周期与作用域边界：

┌──────────────────┐     ┌───────────────────────────────┐
│   Client Pod     │     │     kube-apiserver (Cluster-A)  │
│ (in Cluster-A)   │────▶│ • Signs token with sa.key       │
│                  │     │ • Embeds: audience, iss, ns, exp│
└──────────────────┘     │ • Binds to projected volume     │
                         └───────────────────────────────┘
                                     │
                                     ▼ (token used elsewhere?)
                         ┌───────────────────────────────┐
                         │ kube-apiserver (Cluster-B)    │
                         │ • Rejects:                    │
                         │   – unknown issuer             │
                         │   – audience mismatch          │
                         │   – signature verification fail│
                         └───────────────────────────────┘

五、工程实践：替代方案对比与选型建议

当需实现多集群统一身份治理时，应放弃 Token 复用思路，转向标准化联邦机制：

graph LR
  A[外部身份提供者] -->|OIDC Provider| B(Cluster-A kube-apiserver)
  A -->|OIDC Provider| C(Cluster-B kube-apiserver)
  A -->|OIDC Provider| D(Cluster-C kube-apiserver)
  B -->|ID Token + Groups| E[RBAC via OIDC groups]
  C -->|ID Token + Groups| E
  D -->|ID Token + Groups| E
  style A fill:#4CAF50,stroke:#388E3C,color:white
  style E fill:#2196F3,stroke:#0D47A1,color:white

六、演进层：Kubernetes 原生增强方向

自 v1.22 起，TokenRequest 支持 audiences 字段定制化（如设为 ["cluster-a.example.com", "cluster-b.example.com"]），但前提是所有目标集群共用同一套 --service-account-issuer 和 --service-account-signing-key-file —— 这已脱离标准部署模型，进入“多控制平面共享 CA”的强耦合运维模式，实践中极少采用。更可持续的路径是拥抱 ClusterTrustBundle（v1.29+）与外部 OIDC 联邦。

七、排查清单：快速定位 Token 失效根源

1. 执行 jwt decode <token> 检查 aud 是否匹配目标集群预期值
2. 确认目标集群是否配置了 --service-account-issuer 且与 Token 中 iss 一致
3. 检查 kube-apiserver 日志中是否出现 failed to verify signature 或 audience validation failed
4. 验证 Token 是否已过期（exp 时间戳早于当前 UTC 时间）
5. 若启用 BoundServiceAccountTokenVolume，确认请求来源 IP 是否落入 boundCIDRs 范围

八、最佳实践：生产环境多集群身份治理推荐栈

对于中大型组织，建议采用分层身份架构：

• 身份层：部署 Dex 或 Keycloak 作为中央 OIDC Provider，对接 LDAP/AD/GitHub
• 接入层：各集群 kube-apiserver 配置 --oidc-issuer-url、--oidc-client-id、--oidc-username-claim 等参数
• 授权层：结合 ClusterRoleBinding + groupPrefix 实现基于 OIDC group 的跨集群 RBAC 同步
• 审计层：所有登录事件经由 OIDC Provider 统一日志输出，满足 SOC2/GDPR 审计要求

```