Kubernetes ServiceAccount 令牌检查：有效期之外还要看权限

业务容器并不一定需要访问 Kubernetes API。即使使用短期令牌，如果绑定了过大的权限，泄露后仍可能造成严重影响。工作负载身份审查应同时看“有没有必要、能做什么、能用多久”。

从工作负载清单开始

为每类应用记录使用的 ServiceAccount、所需 API 操作、命名空间和负责团队。把只提供 HTTP 服务的应用与需要管理集群资源的控制器分开，不要让所有工作负载共用一个高权限身份。

Kubernetes 官方文档推荐通过 TokenRequest 或投射卷使用短期令牌，并说明 kubelet 会轮换投射令牌；长期静态令牌并非推荐方式。对不需要自动注入凭证的 Pod，可以按官方机制设置 automountServiceAccountToken。

三层验收缺一不可

1. 凭证必要性：不需要 API 的应用不应因为默认配置而获得无用凭证。
2. 授权范围：需要访问的资源和动作能够成功，明确无关的资源与跨命名空间操作应被拒绝。
3. 生命周期：客户端能使用轮换后的凭证，过期凭证不能继续完成受保护操作。

测试使用专用身份与无害资源，不打印令牌内容。对依赖轮换的客户端，应确认它会重新读取挂载文件，而不是只在启动时读一次并无限缓存。

外部系统还要核对受众

如果令牌用于集群外的服务，验证方需要检查签发方、受众、有效期及其他所需声明。不能因为一个令牌能被解析，就把它当成可用于任意服务的通行证。

发现历史静态令牌时，先识别使用方并设计迁移，再撤销旧凭证，避免无计划中断。最终报告应同时列出身份映射、权限范围与轮换验证结果。

参考：Kubernetes：Service Accounts。核对日期：2026年10月4日。