Technical documentation
K8s 密钥轮换后旧凭据为何还能用？别把“能轮换”当“已撤权”
K8s 密钥轮换后旧凭据为何还能用？别把“能轮换”当“已撤权”
Kubernetes 服务账户密钥轮换配置指南旨在通过自动化机制更新凭证，但必须配合显式撤权操作才能确保旧密钥彻底失效，而非仅依赖轮换动作本身。
机器身份的核心误区：为什么“能轮换”不等于“已撤权”？
机器身份的核心误区在于混淆了凭证轮换与权限撤销，误以为密钥旋转即代表旧凭据自动失效，实则忽略了认证授权体系中两段式结构的逻辑差异。
很多运维同仁有个直觉：只要 ServiceAccount 的密钥在旋转，旧凭据就应该自动失效。这种想法其实忽略了 Kubernetes 认证与授权那套严密的“两段式”结构，导致大家把“能轮换”误读成了“已撤权”。这中间差的不止是技术细节，更是安全逻辑的根本差异。
ServiceAccount 不是人的账户副本
Kubernetes 严格区分了面向人的普通用户和面向应用进程的 ServiceAccount[1]。后者由 API 管理，且作用域被限制在特定命名空间内[2]。这意味着它本质上是进程的身份标识，而非人类共享密钥的数字化身。当 Pod 内的进程使用关联的 ServiceAccount 向 API Server 发起请求时，若验证通过，系统仅将其标记为 system:authenticated[1]。这仅仅回答了“你是谁”，并未赋予任何具体的资源操作权限。
认证后的授权陷阱
取得凭据只是通过了第一道关卡，真正的访问控制发生在 RBAC 层。认证机制确认主体身份，RBAC 规则才决定该主体能对何种资源执行什么动作[2]。如果审计流程只检查 Pod 是否持有有效身份，却忽略其背后的 RBAC 绑定关系，就会错误地将“可认证”等同于“最小权限”。
| 关注点 | 常见误区 | 实际风险 |
|---|---|---|
| 身份来源 | 认为拥有 Token 即代表安全 | Token 仅证明通过 system:authenticated[1] |
| 权限边界 | 误以为轮换密钥即切断所有访问 | 未更新 RBAC 绑定时，旧身份仍具高权限 |
| 爆炸半径 | 依赖单一身份层控制风险 | 实际风险取决于授权层的配置粒度[2] |
若只确认身份有效而忽略授权层，一旦凭证泄露，攻击者即可利用残留的高权限绑定进行横向移动。控制爆炸半径的关键不在于密钥本身的生命周期，而在于授权策略能否及时响应并拒绝旧主体的既有权限[2]。
这里存在一个常被争论双方忽略的前提：很多人默认“密钥轮换”是一个原子操作，即新密钥生效的同时旧密钥立即作废。但在 Kubernetes 的架构中，密钥轮换（Key Rotation）往往只是改变了未来签发的依据，而 RBAC 的 RoleBinding 或 ClusterRoleBinding 对象本身并不包含“谁持有哪个密钥版本”的元数据。也就是说，当你轮换密钥时，你并没有修改那个允许该 ServiceAccount 访问 pods/exec 的 RBAC 规则；你只是换了一把钥匙，而那把旧钥匙对应的“锁芯”（RBAC 规则）依然敞开着。只要攻击者手里还握着旧密钥，且 RBAC 规则没变，他就能继续通过认证并获取授权。这种“身份层与授权层解耦”的特性，使得单纯依靠密钥轮换无法实现真正的“零信任”阻断，必须配合外部策略引擎或定期清理 RBAC 绑定才能达成闭环。
SPIFFE/SPIRE 架构下的信任边界：密钥管理与节点证明的局限
SPIFFE/SPIRE 架构下的信任边界由私钥管理、节点证明与工作负载选择器三重独立环节共同决定，任一环节配置失误都会导致签发边界偏离设计意图。
很多人误以为把 Trust Domain 当作一串身份字符串就能搞定安全，其实它本质上是签发权威的验证范围。[3] 在 SPIRE Agent 内部，私钥管理、节点证明与工作负载选择被严格拆分为三个独立组件。KeyManager 负责生成并存储 Agent 私钥，NodeAttestor 收集节点身份证明信息，WorkloadAttestor 则为工作负载生成选择器。[4] 这种职责分离意味着，工作负载的可信度并非由单一环节决定，而是依赖私钥受控、节点可被证明、选择器映射正确这三重条件。[4] 只要其中任一环节配置出错，签发的边界就会偏离设计意图，就像一把锁的钥匙孔形状对了，但锁芯结构却被人偷偷改过一样。
为了更直观地理解这些组件如何协同又各自独立，我们可以对比它们在身份链条中的具体分工：
| 组件名称 | 核心职责 | 依赖的外部输入 | 潜在风险点 |
|---|---|---|---|
| KeyManager | 生成并存储 Agent 私钥 | 无（内存型） | 重启后需重新证明，但旧凭据未失效 |
| NodeAttestor | 收集节点身份证明信息 | 节点硬件/环境特征 | 证明逻辑错误导致非法节点接入 |
| WorkloadAttestor | 为工作负载产生选择器 | Pod 标签/镜像指纹 | 选择器映射错误导致权限越界 |
尽管内存型 KeyManager 不持久化私钥，Agent 重启后必须重新完成证明，但这并不能推定所有已发放的工作负载凭据立即失效。[4] 现有的材料没有提供关于 SVID 生命周期、验证缓存或撤销传播的具体语义。[4] 这意味着，即使旧的私钥在内存中消失，持有该私钥签发的 SVID 仍可能在缓存或未同步的资源端继续通行。这种“灰色地带”让运维人员难以确信轮换动作是否真正切断了旧凭据的使用路径。
在实际的分布式集群场景中，SPIRE 的 Bundle 更新往往面临“最终一致性”的挑战。例如，在一个拥有数百个节点的跨可用区部署中，当 Trust Domain 的根证书发生变更时，部分处于网络抖动或离线状态的节点可能数小时甚至数天都无法拉取最新的 Bundle。在此期间，这些节点上的工作负载虽然持有的是“过期”的 SVID，但只要它们本地缓存的验证逻辑尚未超时，或者攻击者利用旧 SVID 发起的请求恰好落在某些节点的缓存窗口内，这些请求就可能被误判为合法。这种非实时的同步机制，使得“短周期令牌”在理论上的优势在工程实践中被大幅稀释，因为攻击者不需要等待整个集群同步完毕，只需要在某个滞后的节点上找到漏洞即可。
打破迷思：短周期令牌与 Bundle 更新为何不能自动完成全域撤权
短周期令牌与 Bundle 更新无法自动完成全域撤权，因为工程落地中缺乏明确的有效期数据与缓存策略，导致支持撤销并不等同于撤销即时生效。
很多人认为，只要配置了短周期的令牌或更新了信任包，泄露的旧凭据就会立刻失效。这种直觉在理论上是美好的，但在工程落地时却往往落空。Kubernetes 文档虽然提到了服务账户令牌的撤销机制，甚至允许将有效性绑定到对象生命周期，但通篇未给出任何关于令牌具体有效期、轮换传播时延或验证端缓存策略的数据[2]。这意味着，“支持撤销”并不等同于“撤销即时生效”。
轮换只是改变未来，不代表终结过去
轮换动作本质上是在改变未来的签发和验证依据，而非直接抹除过去的痕迹。当你更新了 ServiceAccount 密钥或触发了 SPIFFE bundle 更新，新的证书确实开始生效，但这并不意味着所有持有旧证书的节点会瞬间感知并停止使用。
现有的材料显示，SPIFFE bundle 仅证明了验证者拥有获取信任材料的规范化方式，却无法证明每个验证者在何时刷新了本地副本，也无法界定旧密钥在多长时间内仍会被接受[3]。这就好比银行更换了金库密码，但持有旧钥匙的保安可能还在值班，直到他们收到明确的换班通知或被系统强制踢出。如果资源端依赖本地缓存的验证材料，或者网络存在延迟，旧凭据就能在这些时间窗口内继续通过认证。
为了更清晰地展示两种观点的差异，我们来看下表：
| 对比维度 | “自动撤权”假设派 | “证据不足”现实派 |
|---|---|---|
| 触发条件 | 密钥更新或 TTL 到期即视为失效 | 需等待验证端主动拉取新 Bundle |
| 失效范围 | 全域立即生效，无时间差 | 受限于缓存策略和网络传播延迟 |
| 数据支撑 | 依赖“短周期”概念的直觉推断 | 缺乏具体的 TTL、缓存上限观测数据 |
| 风险窗口 | 极短，可忽略不计 | 取决于 Bundle 刷新频率和离线行为 |
| 结论可靠性 | 无法被现有文档证实 | 基于材料缺口作出的工程推论 |
证据不足的工程外推
将”Bundle 存在”直接解读为“强制实时撤权”，属于一种证据不足的外推。目前没有任何官方文档提供了轮换成功率、续期窗口或资源端拒绝旧凭据的具体观测证据[2][4]。
在缺乏这些关键数据的情况下，断言“短周期令牌天然限制泄露风险”是站不住脚的。如果验证端没有及时更新本地存储的信任材料，或者工作负载处于离线状态，旧凭据依然有效。因此，真正的安全边界不在于你生成了多短的令牌，而在于你的架构是否具备检测并阻断那些“未被及时更新”的旧会话的能力。
构建可检验命题：如何验证“旧凭据不可再用”的真实状态
验证旧凭据不可用的真实状态需执行反事实测试，即在替换事件后直接用旧主体发起请求并观察系统是否返回拒绝结果，以此覆盖四个关键边界条件。
别把“开启轮换”当作终点，真正的验收需要一套反事实测试方案。在撤销或替换事件发生后，直接用旧主体、旧令牌发起预定义请求，观察系统是否返回拒绝结果[2][4]。这一过程必须覆盖四个关键边界，缺一不可。
四步验收法
- 签发端：确认是否已停止产生旧身份材料。
- 认证端：检查是否拒绝使用旧凭据的登录请求。
- 授权端：验证旧主体是否仍被 RBAC 策略允许访问资源。
- 资源端：核查依赖 Bundle 更新后的节点是否拒绝旧凭证。
Kubernetes 明确区分了“认证成功”与”RBAC 授权”，SPIFFE 则将信任锚定在 Trust Domain 与 Bundle 的关系中[1][2]。这意味着上述四项结果无法相互替代：即使认证端拒绝，若授权端缓存未刷新，攻击者仍可能利用旧权限；反之亦然。
| 边界环节 | 核心动作 | 常见误区 | 验证依据 |
|---|---|---|---|
| 签发端 | 停止生成旧材料 | 以为新签即代表旧失效 | 日志记录无新产出 |
| 认证端 | 拒绝旧凭据请求 | 混淆认证失败与授权失败 | API Server 响应码 |
| 授权端 | 拒绝旧主体权限 | 忽略 RBAC 缓存延迟 | 策略执行点日志 |
| 资源端 | 完成 Bundle 更新 | 假设所有节点实时同步 | 跨节点连接测试 |
从机制到务实路径的闭环
ServiceAccount 和 SPIFFE ID 只是构成闭环的组件，而非自动实现的零信任保障。现有文档未提供具体的 TTL 设置、缓存上限或撤销传播时延数据[2][4]。因此，关于轮换是否缩短泄露窗口、旧凭据是否彻底失效，最终结论必须依赖具体版本的部署配置和实测日志来补足证据[3]。不要试图用理论推导代替现场观测。
对于希望建立自动化验证能力的团队，建议引入一个轻量级的“凭据健康检查”脚本，作为 CI/CD 流水线的一部分。该脚本应模拟一个已知泄露的旧 SVID 或 Token，在每次轮换操作完成后，自动向集群内的不同节点（包括主节点、边缘节点和离线恢复节点）发起请求。脚本不应只检查 API Server 的全局状态，而应专门监控每个节点的本地响应码。如果某个节点在轮换后 5 分钟内仍未拒绝旧凭据，流水线应立即报警并暂停后续的发布流程。这种“以攻促防”的验证机制，比单纯依赖配置文件的静态扫描更能真实反映系统的安全水位。
FAQ：关于密钥轮换的常见疑问
Q: 既然轮换不能保证立即失效，那还有必要做吗？ A: 绝对有必要。虽然它不能“一键清零”旧权限，但它限制了攻击者利用泄露密钥的时间窗口。配合严格的 RBAC 策略和定期的审计，轮换依然是纵深防御中最基础的一环。
Q: 如何判断我的 SPIFFE Bundle 是否真的更新了？
A: 不要只看配置文件。建议在集群内随机选取几个节点，手动执行 spire-agent status 或检查其本地缓存时间戳，并尝试用旧 SVID 发起一个非关键请求，观察 API Server 的响应代码是否为 401 或 403。
Q: 有没有办法实现“即时”撤权？ A: 在当前的 K8s 原生机制下很难做到物理意义上的“即时”。最接近的方案是结合外部 CA 的 CRL（证书吊销列表）或 OCSP 实时查询，但这会增加架构复杂度。对于大多数场景，缩短 Token 生命周期 + 快速回滚 RBAC 策略是性价比最高的选择。
参考来源
- Authenticating | Kubernetes · https://kubernetes.io/docs/reference/access-authn-authz/authentication/（A级）
- Managing Service Accounts | Kubernetes · https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/（A级）
- SPIFFE Trust Domain and Bundle | SPIFFE · https://spiffe.io/docs/latest/spiffe-specs/spiffe_trust_domain_and_bundle/（A级）
- SPIRE Agent Configuration Reference | SPIFFE · https://spiffe.io/docs/latest/deploying/spire_agent/（A级）