在 Kubernetes 1.24 及更新版本中,创建 ServiceAccount(服务账户)后默认不会自动生成对应的 Secret 和 Token。这是 Kubernetes 在安全策略上的重要变更,主要解决旧版本中永久有效 Token 的安全风险问题。
以下是新旧版本行为对比及新版操作指南:
🔒 一、版本行为对比
| Kubernetes 版本 | 创建 ServiceAccount 后的行为 | Token 特性 |
| ≤ 1.20 版本 |
自动生成关联的 Secret(含永久有效 Token)
|
永不过期,存在安全风险 |
| 1.21–1.23 版本 |
自动生成 Secret,但 Token 有过期时间
|
可配置有效期 |
| ≥ 1.24 版本(当前最新) |
不再自动生成 Secret 和 Token
|
需手动创建,默认有效期 1 小时 |
⚙️ 二、新版手动创建 Token 方法
通过 kubectl create token 命令显式生成短期有效的 Token:
输出示例(直接返回 Token 字符串):
eyJhbGciOiJSUzI1NiIsImtpZCI6Ik1rQTF...
💡 关键特性:
- 短期有效性
- 默认有效期 1 小时,可通过
--duration 参数调整(如 --duration=24h)。
- 动态更新机制
- 若 Pod 使用该 ServiceAccount,kubelet 会每小时自动轮换挂载的 Token,无需手动维护。
- 无持久化 Secret
- 此命令生成的 Token 不会创建 Secret 对象,仅临时输出到终端。
🔐 三、安全最佳实践
-
避免使用高权限默认 SA
Kubernetes 自动为 Pod 分配的 default ServiceAccount 通常具有过高权限,建议绑定最小权限 Role。
-
生产环境权限控制
-
定期轮换敏感 Token
对需长期使用的 Token(如 CI/CD 系统),通过 CronJob 定期执行 kubectl create token 更新凭证。
注意:若需兼容旧版(自动生成 Secret),需显式创建 Secret 并关联 ServiceAccount 的 secrets 字段,但官方已不推荐此方式。
💎 总结
- ✅ Kubernetes ≥1.24 中,ServiceAccount 不再自动生成 Token。
- ✅ 必须通过
kubectl create token <sa-name> 手动创建短期有效 Token。
- ✅ Pod 内挂载的 Token 由 kubelet 每小时自动更新,保障安全性。