如何在Kubernetes中通过Service-Account-Token实现Pod运行时身份安全性的全面提升？

本文共计689个文字，预计阅读时间需要3分钟。

核心是采用TokenRequest API+托管卷，取代传统的Secret+挂载方式。这能实现自动轮换、绑定节点、限制audience等关键安全功能，而非依赖长期有效的静态Token。

停用 Secret 挂载，启用 BoundServiceAccountTokenVolume

1.21 及以上版本默认开启该特性，无需额外配置；1.25+ 版本将彻底不再自动生成 ServiceAccount 对应的 Secret。确认方式：

• 检查 Pod 中是否还存在 /var/run/secrets/kubernetes.io/serviceaccount/token 对应的 Secret 挂载（传统路径）
• 查看 Pod spec 中 volumeMounts 是否指向 service-account-token 类型的 projected volume
• 运行 kubectl get sa <name> -o yaml，若输出中无 secrets: 字段，说明已切换至投影模式

控制 Token 生命周期与自动刷新

投射卷方式下 Token 默认有效期为 1 小时，由 kubelet 在过期前主动轮换。集群管理员可通过 API Server 参数调整：

• --service-account-max-token-expiration：设最大有效期（如 3600 秒）
• --service-account-issuer：指定签发者（如 https://my-cluster.example.com），影响 JWT 中 iss 字段
• --service-account-signing-key-file：指定签名密钥，确保 Token 可被 API Server 验证

注意：社区为平滑过渡，默认将有效时间延长至 1 年，但长期依赖此设置会削弱安全性，建议保持较短周期（如 1–8 小时）。

启用节点级权限隔离（K8s ≥1.28）

在 ServiceAccount 上添加注解，可将 Token 的访问范围严格限制在 Pod 所在节点内：

• 添加 rbac.kubernetes.io/restricted-by-node: "true" 注解
• 该 Token 后续只能访问本节点上的 Node、Pod、Secret、ConfigMap、PVC、PV、ServiceAccount/token 等资源
• 适用于边缘计算、CI/CD 构建节点、多租户节点复用等需强隔离场景

确保客户端支持证书轮转

旧版 client-go 或其他 SDK 若无法处理 Token 动态更新，会导致请求失败。必须升级至具备 reload 能力的版本：

• Go client-go：≥ v0.15.7
• Python kubernetes-client：≥ v12.0.0
• Java client：≥ v9.0.0
• JavaScript client：≥ v0.10.3
• Ruby client：master 分支
• C# client：≥ v7.0.5

验证方法：监控指标 serviceaccount_stale_tokens_total，非零值表示存在客户端未及时加载新 Token。