Kubernetes 1.37 Pod证书怎么签发：Signer与mTLS信任链排查

Kubernetes 1.37 最近有一个容易被忽略、但和 HTTPS/mTLS 关系很大的变化：Pod Certificates 与 Cluster Trust Bundles 的基础能力已经进入 GA。它不是"再加一个 Secret 类型"，而是把工作负载的 X.509 身份、私钥生成、证书签发、信任链分发和自动轮换，接进了 Kubernetes 的核心工作流。 $1$

这件事对运维人员的实际意义是：以后给 Pod 配 mTLS，不一定要把证书和私钥提前烘进镜像，也不必让每个业务团队各自拼一套轮换脚本。证书生命周期可以由 Kubelet、Signer 和应用共同完成。不过，自动签发不等于应用自动生效，轮换文件之后，应用是否重新加载仍然是业务自己的责任。

一、Kubernetes 1.37 到底新增了什么

官方把这套能力拆成两部分：

Pod Certificates：面向 Pod 请求和获取 X.509 证书、私钥以及证书链；
Cluster Trust Bundles：把匹配到的信任锚证书集合投影到工作负载文件系统。

二者组合起来，应用可以使用 TLS 或 mTLS 与其他服务通信。这里讨论的是集群内部工作负载身份，不是 Ingress 的公网域名证书，也不是 kubelet 自身的客户端证书轮换。先分清对象，才不会拿着 Pod 的门禁卡去修网站的门锁。

二、它解决了 JWT 身份的哪个问题

ServiceAccount JWT 使用方便，而且已经深度集成到 Kubernetes。但它本质上是 bearer token：谁拿到 token，谁就可以代表这个身份发起请求。X.509 的思路不同，私钥用于证明"我确实持有这把密钥"，证书只描述公钥和身份。

更关键的是，Pod Certificate 设计要求私钥尽可能在工作负载侧生成并留在本地。Signer 看到的是证书请求和公钥，不需要接触业务私钥。这个边界很适合内部服务间的 mTLS，也符合私钥不离开使用方的基本原则。 $1$

三、完整签发链路怎么跑

可以把链路理解成下面六步：

Pod 被调度到 Node，Kubelet 发现 PodSpec 中声明了 podCertificate 或 clusterTrustBundle 投影卷；
Kubelet 按 keyType 生成私钥；
Kubelet 创建指向指定 Signer 的 PodCertificateRequest；
Signer Controller 审核请求并把证书链写入状态；
Kubelet 把私钥、证书链和信任束写入容器文件系统；
证书接近刷新时间时，Kubelet 重复请求并更新文件。

这和传统的"先在 CI 里生成证书，再打包进 Secret"相比，最大的变化是签发动作靠近工作负载运行时，密钥生成也可以靠近工作负载本身。

四、自动轮换最容易踩的坑

官方明确提醒：自动轮换已经内置，但应用必须自己正确处理轮换。未来由 Kubernetes 核心提供的 Signer，证书有效期上限将是 24 小时；其他 Signer 的允许上限是 91 天。这是上限，不代表每次都能签足对应时长。 $1$

因此，应用不能只在启动时读取一次 tls.crt 和 tls.key。可以优先使用 credential bundle，让 Kubelet 把私钥和证书链写到一个文件中，应用通过 inotify 或定时轮询发现文件变化后重新加载 TLS 配置。

如果把私钥和证书拆成两个文件，就要处理更新时序：应用可能刚读到新证书，却还没读到匹配的新私钥。生产环境中，这类竞态往往比证书过期更难排查。

五、Signer 还不是 Kubernetes 自带的万能 CA

这里要特别降温：Pod Certificates 的基础设施进入 GA，不代表 Kubernetes 1.37 已经自带一个可以直接用于生产的公共 CA。

官方示例使用了第三方 Tinycert Signer 来演示完整流程，并且明确说明 Tinycert 不是完整的生产方案。 $1$ 真正上线前，仍然要单独设计 Signer 的身份认证、授权范围、CA 私钥保护、审计日志、吊销策略和灾备方案。

也就是说，Kubernetes 负责把"申请、投影、轮换"的管道铺好；谁来签、签什么、信任谁，仍然是平台团队必须做的安全决策。

六、和传统 Secret 方案怎么选

方案	优点	主要风险	适合场景
手工 Secret	简单、兼容性好	轮换依赖人工或外部脚本	低频内部服务、临时环境
cert-manager	生态成熟，ACME 和内部 CA 都能接	组件较多，需要管理 Secret 生命周期	已有 cert-manager 的生产集群
Pod Certificates	私钥可在工作负载侧生成，投影和轮换更贴近 Pod	Signer 与应用热加载仍需建设	平台级 mTLS、需要自建 Signer 的工作负载身份

没有必要为了追新把所有 Secret 一次性迁移。更稳妥的做法是先挑一条内部 mTLS 链路做试点，验证证书更新、应用 reload、故障回退和节点重启后的恢复。

七、先看请求和信任束，再查文件

下面是只读诊断命令，不会安装 Signer，也不会生成私钥。先替换命名空间和请求名；列表为空时回查 Pod 的投影配置，出现 Denied 或 Failed 时查看 conditions，而不是反复重建 Pod。

bash 复制代码

kubectl get podcertificaterequests -n <命名空间>
kubectl get podcertificaterequests <请求名> -n <命名空间> -o yaml
kubectl get clustertrustbundles

本地拿到叶证书后，可只读检查身份、用途和到期时间。证书可用于客户端还是服务端，还要看 Signer 策略、SAN 与扩展用途，不能见到 PEM 就默认两边都能用。不要把 credential bundle 当普通日志输出，它包含私钥。