Kubernetes v1.37 Pod Certificate 与 Cluster Trust Bundle：集群证书信任链怎么接

Kubernetes v1.37 的一个安全相关变化容易被版本发布清单带过：Pod certificates 与 ClusterTrustBundles 都进入了稳定阶段。它解决的不是“给 Pod 多加一个 Secret”这么简单，而是把工作负载身份和集群信任根的分发边界说得更清楚。

升级判断可以先记住一句话：Pod certificate 负责工作负载拿到可轮换的身份凭证，ClusterTrustBundle 负责让工作负载知道应该信任哪些证书颁发者；两者稳定后，仍需要集群管理员、证书签发组件和应用侧共同完成接入。

Kubernetes v1.37 把哪两条身份链路推到了稳定阶段

Kubernetes 官方的 v1.37 发布说明把 ClusterTrustBundles 和 Pod Certificates 列在 Stable enhancements 中。官方专题页进一步解释，Pod certificate 面向工作负载的生产身份；ClusterTrustBundle 则提供一组可以被工作负载消费的信任锚点。它们关注点不同，但都服务于“工作负载如何安全地和其他系统建立身份信任”。

这次变化更适合按“能力稳定”和“现场可用”分开理解。前者看版本与 API 文档，后者要看签发链、信任根、权限和应用是否真的消费了新凭证。

Pod certificate 和 ClusterTrustBundle 各自解决什么问题

Pod certificate 的核心是工作负载身份。应用不必长期持有一枚静态凭证，而是由集群中的证书流程申请、签发并在接近到期时轮换。应用侧要关心证书放在哪里、私钥权限如何限制、轮换后客户端是否会重新加载。

ClusterTrustBundle 的核心是信任材料分发。服务端证书换了签发机构或中间 CA 后，客户端需要知道哪些根或中间证书可以接受。把信任集合以 Kubernetes 可发现、可授权的对象形式提供，比把一段长期不更新的 CA bundle 手工复制到每个镜像更容易审计。

接入时先把四个责任边界写进设计

这张表里最容易遗漏的是最后一行。证书文件发生变化，只能证明投影或更新链路动了；如果 HTTP 客户端、gRPC 连接池或自定义 TLS 配置只在进程启动时读取文件，应用仍可能继续使用旧证书。

从 API、投影到应用重载做一轮最小验收

先确认集群版本和能力开关

先在测试集群确认 Kubernetes 版本、相关 API 资源和发行版支持矩阵，再决定是否把能力放进生产基线。不要因为发布页写了 Stable，就跳过发行版的升级说明和准入策略检查。

再验证证书的申请与轮换

给一个非生产工作负载配置短周期测试证书，记录申请时间、到期时间、签发者和更新后的文件内容摘要。验收重点是“能否按预期轮换”，而不是只看第一次申请成功。

最后验证信任根被应用消费

让测试客户端访问一个由目标 CA 签发的服务，再替换一份测试信任集合，观察新建连接和已有连接的行为。连接池若不重载信任材料，要把重建连接的动作写进应用配置或发布流程。

稳定化之后仍要防住三类误判

第一，稳定 API 不等于所有云厂商发行版都已经默认启用；第二，证书能被挂载不等于应用真的使用了它；第三，信任根更新成功不等于已经覆盖所有命名空间和工作负载。权限、准入控制器、服务网格和外部 CA 集成仍然可能改变最终行为。

对生产团队来说，比较稳的上线顺序是先选一个可回滚的工作负载做灰度，保留旧身份链路作为观察期兜底，再把证书申请、信任根更新和连接重建纳入同一份变更记录。任何一项没有可观察结果，都先停在测试环境。

相关问题

Pod certificate 能完全替代 ServiceAccount Token 吗？

不能直接画等号。两者的身份语义、验证方和消费协议可能不同，是否替换要看目标系统接受的凭证类型与集群发行版实现。

ClusterTrustBundle 是不是一个新的 Secret 类型？

不应按普通 Secret 理解。它表达的是可被工作负载消费的信任集合，接入时应按 Kubernetes 对应 API、权限和投影方式检查。

证书轮换后应用一定会自动生效吗？

不一定。文件更新、TLS 配置重载和连接池重建是三个可能分离的动作，必须用测试连接验证应用实际行为。

给升级评审的最终检查清单

评审这项 Kubernetes v1.37 变化时，可以按“版本支持—证书签发—凭证投影—信任集合—轮换观察—应用重载—回滚路径”逐项签字。这样得到的是一条可追踪的工作负载身份链，而不是只在升级报告中新增两个稳定特性名词。