不建议配置永久有效的 kubeconfig Token。因永久 Token 泄露将导致无限期集群管理员权限且无法吊销；v1.22+ 动态签发 token 有效期仅1小时，v1.24+ 已弃用手动 Secret Token；托管服务强制使用短期 OIDC/IAM 凭证；应采用短期凭证替代，如 OIDC 集成、云平台临时令牌刷新等。
不建议配置永久有效的 kubeconfig Token。Kubernetes 的安全设计原则明确反对长期不变的凭证，永久 Token 一旦泄露，等同于授予攻击者无限期集群管理员权限，且无法主动吊销。
为什么不能追求“永久有效”
ServiceAccount Token 默认由 Secret 背后管理，其有效期取决于所用机制：
- 自动挂载的
token文件（v1.22+ 默认启用）是 projected volume，由 kube-apiserver 动态签发，有效期通常为 1 小时，不可延长； - 手动创建的 Secret 类型 Token（
type: kubernetes.io/service-account-token）在 v1.24+ 已被弃用，且即使存在也不支持设为永不过期； - 使用
kubeadm token create --ttl 0生成的是节点加入用的 bootstrap token，仅用于kubeadm join，不适用于 kubeconfig 用户认证； - EKS/IKS/GKE 等托管服务强制使用短期 OIDC 或 IAM 换取临时凭证，根本不存在“静态永久 Token”路径。
更安全的替代方案
用可控、可轮换、可审计的短期凭证替代“永久 Token”：
Kubernetes Security Posture Scorecard
下载
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
-
对 CI/CD 或自动化工具：使用专用 ServiceAccount + RoleBinding，配合短期凭证注入（如 GitHub Actions 的
id-token+ OIDC，或 Jenkins 的 Vault 插件动态获取 Token）； -
对管理员临时操作：用
kubectl get --token直接传入短期令牌（例如从云平台 CLI 获取的 15 分钟有效期 ID Token），不落地保存； - 对跨集群统一认证：部署 OpenID Connect（OIDC）提供方（如 Dex、Keycloak），让所有用户/工具通过同一身份源登录，凭据生命周期由 IDP 统一管控；
-
对遗留脚本兼容需求：用 shell 封装命令，每次执行前调用
aws eks get-token或gcloud container clusters get-credentials刷新 kubeconfig 中的user.exec配置，确保每次使用都是新签发的短时效凭证。
必须规避的高危操作
以下做法会显著放大风险，应严格禁止：
- 将
serviceaccount/token内容硬编码进 Git 仓库或配置文件； - 用
kubectl create secret generic --from-literal=token=...手动注入长期 Token； - 禁用 kube-apiserver 的
--service-account-lookup或关闭TokenRequestAPI； - 在 kubeconfig 中写死
user.token字段并长期复用。
真正的稳定性不来自凭证不变，而来自自动化轮换与最小权限控制。短期凭证配合健全的刷新机制，既满足可用性，又守住安全底线。
