集群服务间的身份认证与面向用户的登录认证有本质区别：服务没有人工输入密码的环节，调用通常由后台进程自动发起。因此，认证凭证必须能够被程序安全地获取、加载和展示给对端，同时又要避免把长期有效的静态密钥散落在配置文件、环境变量或代码仓库中。短期令牌机制的核心思路，是将服务身份拆分为一个长期可信的账号身份，以及由该身份申请得到的、有效期很短的动态凭证。验证方只需要信任签发者的公钥，就能在不访问中心化存储的情况下确认令牌真伪。
这种模型把静态密码或长期Token的风险窗口压缩到分钟级。即使令牌在传输日志、错误信息或调试输出中被意外记录，只要它已经过期，攻击者也无法继续使用。接下来从身份模型转变、声明设计、Kubernetes实战和方案对比几个角度展开。
一、从长期静态凭证到短期动态令牌：身份模型的转变
传统集群服务认证常给每个服务配置一个长期有效的API Key、共享Secret或持久化Token。这种方式实现简单，但有几个明显缺陷。第一，长期凭证一旦写入配置文件，就很难安全轮换。很多团队为了减少变更风险，会把Secret复制到多台机器、多个环境，甚至提交到Git仓库。第二，验证方如果要检查长期Token是否仍然有效，通常需要调用一个中心化认证服务；如果认证服务暂时不可用，调用链可能被拖垮。第三，长期凭证缺乏细粒度的受众和过期约束，一个用于日志系统的Token很可能也能被用来访问数据库。
短期令牌机制引入了签发者、持有者和验证者三方模型。持有者使用自己的服务账号身份向签发者申请令牌，签发者颁发一个带有数字签名和过期时间的结构化令牌，验证者只需用签发者的公钥验签即可。因为令牌中已经包含过期时间和受众字段，验证者无需回源查询。密钥方面，长期服务账号私钥可以保存在节点或Pod的内部挂载中，尽量少暴露；真正在网络中传递的是短期令牌。私钥泄露仍然严重，但可以通过撤销服务账号、轮换公钥或缩短令牌有效期来降低损失。
需要注意，短期令牌并不是简单把有效期从一年改成五分钟。它要求整个签发和验证链路都围绕时间、签名和声明来设计。例如，如果集群节点之间时钟不同步，五分钟有效期的令牌可能刚发出就被判定为过期，或者已经过期的令牌被误认为有效。签发者需要明确令牌的受众，只有目标服务才能接受该令牌，避免令牌被转发到其他接口后继续使用。验证者还应当校验令牌的签发者是否可信、签名算法是否符合预期，以及令牌是否在有效期内。任何一项缺失，都可能让短期令牌退化成一种仅仅带有过期时间的静态JWT。
二、短期令牌的声明设计与验签链路
短期令牌通常使用JWT格式承载身份信息。JWT分为头部、载荷和签名三部分，载荷中包含一组声明。对于集群服务认证，建议至少包含以下字段：sub表示服务账号的稳定标识；iss表示签发者；aud表示令牌允许访问的接收方；iat表示签发时间；nbf表示生效时间；exp表示过期时间。某些场景下还可以加入jti作为唯一令牌ID，用于审计或撤销判断。
受众声明是短期令牌中最容易被忽视但最关键的一环。假设服务A向认证中心申请了一个令牌，用于调用服务B。如果令牌的aud没有限制为服务B，那么任何持有该令牌的人都可以把它发送给服务C，只要服务C信任同一个签发者，也会验证通过。正确做法是，签发令牌时把目标服务的标识写入aud，验证方在验签后还要检查自己的服务名是否出现在受众列表中。这样，令牌即使被截获，也不能在集群内任意横向调用。
验签链路通常放在网关、Sidecar或服务框架的中间件中。验证步骤包括：从HTTP请求头中提取Bearer Token；使用签发者公钥验证签名；检查exp和nbf，允许几秒到几十秒的时钟偏移；检查iss是否在可信列表中；检查aud是否包含当前服务标识；最后将sub映射为本地权限策略中的身份。下面是一个Go语言验签中间件的简化示例：
package main
import (
"fmt"
"time"
"github.com/golang-jwt/jwt/v5"
)
// 验签密钥来自签发者的公钥或JWKS
var verifyKey = []byte("public-key-pem-content")
func verifyServiceToken(tokenString, expectedAudience string) (string, error) {
token, err := jwt.Parse(tokenString, func(t *jwt.Token) (interface{}, error) {
// 限制签名算法，防止算法混淆攻击
if _, ok := t.Method.(*jwt.SigningMethodRSA); !ok {
return nil, fmt.Errorf("unexpected signing method: %v", t.Header["alg"])
}
return verifyKey, nil
})
if err != nil {
return "", err
}
claims, ok := token.Claims.(jwt.MapClaims)
if !ok || !token.Valid {
return "", fmt.Errorf("invalid token")
}
// 校验过期时间和生效时间
now := time.Now().Unix()
if int64(claims["exp"].(float64)) < now-30 {
return "", fmt.Errorf("token expired")
}
if int64(claims["nbf"].(float64)) > now+30 {
return "", fmt.Errorf("token not valid yet")
}
// 校验受众是否包含当前服务标识
aud := claims["aud"].(string)
if aud != expectedAudience {
return "", fmt.Errorf("audience mismatch")
}
sub := claims["sub"].(string)
return sub, nil
}
该示例演示了短令牌验证的几个关键点：限制算法、使用公钥验签、容忍少量时钟偏移、校验受众以及提取主体身份。实际生产代码还应处理JWKS动态获取、令牌类型声明和错误分类。
三、Kubernetes TokenRequest API 实战：签发与验证
Kubernetes为ServiceAccount提供了一种获取短期令牌的机制，即TokenRequest API。传统做法是从Secret中读取ServiceAccount Token，这种Token通常长期有效，而且与ServiceAccount一一对应。TokenRequest则允许Pod在运行时为指定ServiceAccount申请一个带有过期时间、受众和绑定Pod信息的短期令牌。从v1.20开始，Kubernetes进一步使用Bound Service Account Token，通过投射卷自动注入有时效的令牌。
使用TokenRequest API的请求体可以很简单。以下是一个通过kubectl创建TokenRequest的示例，它可以模拟服务在集群内申请短期令牌的过程：
apiVersion: authentication.k8s.io/v1
kind: TokenRequest
metadata:
name: my-service-account
spec:
audiences:
- api-server
expirationSeconds: 600
执行kubectl create token my-service-account --audience=api-server --duration=10m后，会返回一个JWT。该JWT的aud字段为api-server，过期时间为十分钟。令牌中还会包含sub、namespace和Pod UID等绑定信息。验证方可以使用Kubernetes的TokenReview API来校验令牌，也可以直接使用Kubernetes的OIDC发现文档获取公钥，在服务本地完成验签。
TokenRequest带来的另一个好处是，Pod内不再需要保存长期有效的ServiceAccount Token。旧的静态Secret Token虽然仍然存在，但可以通过关闭自动挂载或启用ServiceAccount令牌投射来减少暴露。部署到不同环境的服务可以为同一ServiceAccount申请不同受众的短期令牌，例如一个只用于访问API Server，另一个只用于访问自建服务。这样即使某个令牌泄露，其作用范围也受到受众和过期时间的限制。
在应用层接入Kubernetes TokenRequest时，服务通常不需要自己实现签发逻辑，而是调用Kubernetes API Server的/api/v1/namespaces/{namespace}/serviceaccounts/{name}/token端点。Pod内的客户端可以通过底层ServiceAccount的CA证书和令牌认证到API Server。对于自建服务间的认证，可以继续使用同一套JWT机制，只需要在签发阶段把目标服务写入受众，并让目标服务信任Kubernetes的签发公钥即可。这样统一了身份来源和验证标准，减少每个服务各自实现认证逻辑的负担。
四、短期令牌与mTLS的对比及落地建议
除了短期JWT，集群服务认证还可以使用双向TLS。mTLS要求调用方和服务端都持有证书，在TLS握手阶段完成双向身份校验。短期JWT通常运行在HTTP层，把令牌放在Authorization头中；mTLS运行在传输层，对应用代码相对透明。两者的安全模型不同，选型时要考虑基础设施成熟度、服务通信协议和运维复杂度。
mTLS的优势是延迟更低，证书校验在握手阶段完成，业务请求不需要额外携带大体积的JWT。它的挑战在于证书签发、分发和轮换需要完善的PKI或SPIFFE/SPIRE体系。如果集群内已经使用服务网格，通常会自动获得mTLS能力。如果服务间通过非HTTP协议通信，或者对调用方身份要求严格到连接级别，mTLS更合适。短期JWT的优势是跨语言、跨平台友好，适合HTTP或gRPC等基于请求头的认证，并且可以和OAuth2、OIDC体系自然衔接。它的缺点是每个请求都要传递令牌，头部体积略大，应用层需要做验签中间件。
无论选择哪种方案，都应该避免回到长期静态凭证的老路。落地时可以从几个方面逐步推进：第一，梳理服务账号清单，删除不再使用的账号，限制每个账号的权限。第二，把令牌有效期控制在十到十五分钟以内，并通过自动重试机制处理令牌过期。第三，在验证方统一使用公钥验签，禁止将共享密钥同时用于签发和验证。第四，记录令牌的jti或指纹，必要时在鉴权层实现短周期撤销。第五，对时钟同步提出明确要求，使用NTP或等效机制保证节点时间偏差在允许范围内。
短期令牌机制并不是银弹，它的意义在于将身份凭证从静态长期存储转变为动态、可约束、可过期的短期凭据。在集群规模扩大后，服务间的信任关系必须建立在统一身份源、明确受众边界和自动化轮换之上，才能既保持调用链路的简洁，又避免单点凭证泄露带来的横向攻击。