go程序不能创建或更新serviceaccount的token，因k8s≥1.24已废弃自动挂载机制，token由tokenrequest api动态签发；程序须用rest.inclusterconfig()加载挂载的token、ca.crt和namespace，并配合正确rbac绑定才能安全调用api。
Go 程序本身不“创建”或“管理”ServiceAccount 资源——那是 kubectl 或 YAML 声明式部署干的事；Go 用 client-go 只能读、列、绑定 RBAC，但不能直接操作 ServiceAccount 的 token 或 Secret（尤其 K8s ≥1.24 后 token 不再自动挂载）。真正要做的，是让 Go 程序安全、正确地 *使用* ServiceAccount 身份调用 API。
为什么不能用 client-go 创建/更新 ServiceAccount 的 token
Kubernetes 从 1.24 开始彻底移除了 auto-generated ServiceAccount token 的自动挂载机制。ServiceAccount 对象本身不再关联 Secret，secrets 字段已废弃。你用 client-go 调用 Create() 或 Update() 操作 corev1.ServiceAccount，永远无法控制其 token——token 由 TokenRequest API 动态签发，且仅限集群内使用（如 InClusterConfig）。
- 试图手动 patch
secrets字段会失败：字段已被 server 忽略 - 通过
CoreV1().Secrets(ns).Create()手动建 token Secret 是无效的：Kubelet 不认，API Server 不验证 - 唯一合法获取 token 的方式是：
TokenRequest子资源调用（需对应 RBAC 权限），或依赖 Pod 启动时自动挂载（需启用automountServiceAccountToken: true）
Go 中加载 ServiceAccount 身份必须用 rest.InClusterConfig()
Pod 内运行的 Go 程序，必须走 rest.InClusterConfig()，而不是硬编码 token 或读取本地 kubeconfig。它会自动读取 /var/run/secrets/kubernetes.io/serviceaccount/ 下的 token、ca.crt 和 namespace，构造出带身份认证的 REST config。
- 路径错误或文件缺失 → 报错
open /var/run/secrets/.../token: no such file or directory - CA 证书不匹配（比如自建集群未挂载正确 ca.crt）→ TLS handshake timeout 或 x509 cert error
- 没指定
Namespace字段（例如 List Pods 时传空字符串）→ 403 Forbidden，因为默认 ns 是default，而你的 SA 可能只在production绑定权限 - 示例片段：
cfg, err := rest.InClusterConfig()
if err != nil {
log.Fatal(err)
}
clientset, err := kubernetes.NewForConfig(cfg)
if err != nil {
log.Fatal(err)
}
// 注意：这里必须显式传入 pod 所在命名空间，不能省略
pods, err := clientset.CoreV1().Pods("production").List(ctx, metav1.ListOptions{})
RBAC 绑定必须显式做，Go 代码里不处理授权逻辑
ServiceAccount 没权限是常态——default SA 默认零权限。Go 程序跑不起来，90% 是因为 RoleBinding 没写对，而不是代码问题。
-
RoleBinding的subjects必须严格匹配：kind: ServiceAccount、name: "my-sa"、namespace: "production"—— 少一个就 403 - 不要用
ClusterRoleBinding绑定到非cluster-admin的 ClusterRole，除非真需要跨 ns；否则权限爆炸且难审计 - 测试权限是否生效，最快方法不是改 Go 代码，而是进容器执行：
curl -k --cacert /var/run/secrets/.../ca.crt -H "Authorization: Bearer $(cat /var/run/secrets/.../token)" https://kubernetes.default.svc/api/v1/namespaces/production/pods - 常见报错：
User "system:serviceaccount:production:my-sa" cannot list resource "pods" in API group "" in the namespace "production"→ 直接检查 RoleBinding 是否存在、命名空间是否一致、Role 的rules是否覆盖verbs: ["list"]和resources: ["pods"]
automountServiceAccountToken: false 是默认安全项，别乱开
除非你的 Go 程序明确需要调用 Kubernetes API，否则应在 Pod spec 中关闭 token 挂载：automountServiceAccountToken: false。这是 CIS Kubernetes Benchmark 强制要求，也是最小权限原则落地点。
- 开了但不用 → 攻击者一旦逃逸进容器，立刻拿到集群访问凭证 在 Helm chart 或 Operator 生成的 Deployment 中，常被忽略这个字段，默认为
- 若确实要用（比如 Operator 需要动态创建资源），则必须配合 RBAC 限制到最小范围，并避免使用
ClusterRoleBinding到cluster-admin - 验证是否挂载成功：
ls -l /var/run/secrets/kubernetes.io/serviceaccount/应有token、ca.crt、namespace三个文件；缺任一说明挂载失败或被禁用
true最易被忽略的一点：ServiceAccount 的 namespace 隔离是硬性的，subjects.namespace 和 RoleBinding.namespace 必须与 Pod 所在 namespace 完全一致；跨 ns 的 RBAC 绑定只能靠 ClusterRoleBinding，但它绕过了命名空间边界，应视为高危操作。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
