关于Kubernetes统一Pod使用ServiceAccount Token及自动生成Token作用的疑问

能不能用自动生成的service-account-token-xxx统一Pod的Token？ #

不行。Kubernetes从v1.21开始默认启用了TokenRequest API，每个Pod启动时都会请求专属的短期Token（挂载在/var/run/secrets/kubernetes.io/serviceaccount/token），你看到的带随机后缀的Secret是旧版的长期Token——现在默认不会自动挂载到Pod里，除非你手动配置或者关闭了自动挂载的默认行为。

而且这类长期Token存在安全隐患，一旦泄露有效期极长，Kubernetes现在也不推荐用它给Pod提供身份凭证。

那这个自动生成的长期Token有什么用？ #

它主要是为了兼容旧场景：

• 部分老应用没集成TokenRequest逻辑，只能通过挂载Secret获取SA凭证
• 外部服务需要访问K8s API时，可用来作为长期身份凭证（不过现在更推荐用ServiceAccount的TokenRequest手动生成短期Token）

怎么让同一个Deployment的所有Pod用同一个Token？ #

如果确实需要统一Token让缓存代理识别为同一身份，有两种可行方案：

1. 创建固定名称的长期Token Secret #

手动创建绑定目标ServiceAccount的Token Secret，然后在Deployment的Pod模板里显式挂载：

# 创建固定Token Secret
apiVersion: v1
kind: Secret
metadata:
  name: fixed-sa-token
  annotations:
    kubernetes.io/service-account.name: "你的ServiceAccount名称"
type: kubernetes.io/service-account-token

接着在Deployment中配置挂载：

spec:
  template:
    spec:
      volumes:
      - name: fixed-token
        secret:
          secretName: fixed-sa-token
      containers:
      - name: 你的容器名
        volumeMounts:
        - name: fixed-token
          mountPath: /var/run/secrets/kubernetes.io/serviceaccount
          readOnly: true

注意：长期Token要做好权限管控，防止泄露。

2. 调整缓存代理的识别逻辑（更推荐） #

如果缓存代理是靠Token识别身份，不如换个思路：让代理基于ServiceAccount的身份标识而非Token本身分组请求。同一个SA下的所有Pod，其Token解析后的sub字段（格式为system:serviceaccount:<命名空间>:<SA名称>）是一致的，你可以在代理层解析JWT提取这个字段，以此作为统一身份标识。
这种方式既符合K8s安全最佳实践（用短期Token），又能实现缓存统一的需求。

内容的提问来源于stack exchange，提问作者Breedly