Kubernetes v1.37：Pod 证书与集群信任捆绑包
内容提要
Kubernetes 1.37 推出 Pod Certificates 和 Cluster Trust Bundles，内置 X.509 证书签发，用于 TLS/mTLS，解决服务账户 JWT 的 bearer token 安全问题。该机制通过非对称签名实现持有证明，架构灵活，支持多种证书类型，但需安装第三方签名器（如 Tinycert）试用。
延伸解读
从 Bearer Token 到持有证明
Service Account JWT 是 bearer token，持有即拥有身份，存在被滥用的风险。Pod Certificates 通过非对称签名实现持有证明，客户端只发送签名证明而非完整凭证，从而降低凭证泄露带来的安全威胁。这一机制与 AWS SigV4、DPoP 等方案类似，但 X.509 证书在 TLS 生态中应用更广泛。
架构灵活性与可插拔设计
Pod Certificates 在 Kubelet 中内置通用机制，但提供可插拔接口，允许同一集群内同时签发多种类型的证书。这与 Service Account JWT 的单一标准不同，适应了 X.509 生态的多样性。未来 Kubernetes 可能内置至少两种证书提供者，但目前仍需依赖第三方签名器。
试用门槛与 Tinycert
由于核心 Kubernetes 尚未内置任何 Pod Certificate 签名器，试用该功能需要安装第三方组件。Tinycert 是一个玩具级签名器，适合在 Kind 集群中实验，也可作为开发自定义签名器的基础。它并非生产级解决方案，但能帮助用户理解 Pod Certificates 的工作流程。
Q&A
Kubernetes 1.37 中 Pod Certificates 和 Cluster Trust Bundles 的主要功能是什么？
Pod Certificates 和 Cluster Trust Bundles 在 Kubernetes 1.37 中正式可用，它们将 X.509 证书签发集成到核心 Kubernetes，用于 TLS 和 mTLS，为工作负载提供生产身份。
为什么 Kubernetes 要引入 Pod Certificates 来替代服务账户 JWT？
服务账户 JWT 是 bearer token，持有者即身份，存在安全风险。Pod Certificates 使用 X.509 证书，基于非对称签名实现持有证明，避免传递完整凭证，提高安全性。
Pod Certificates 的架构中有哪些主要组件？
主要组件包括：Kubelet（内置通用机制）、证书签名控制器（CSR）、证书提供者（可插拔）、Cluster Trust Bundles（分发信任锚点）以及工作负载（使用证书）。
Pod Certificates 的证书签发流程是怎样的？
流程大致为：工作负载生成密钥对和 CSR，通过 Kubelet 提交 CSR 给签名控制器，控制器验证后签发证书，证书通过 Secret 挂载到 Pod，同时 Cluster Trust Bundles 提供信任锚点供验证。
Pod Certificates 相比服务账户 JWT 有哪些优势？
优势包括：基于 X.509 证书，支持持有证明，避免 bearer token 风险；更灵活，支持多种证书类型和扩展；可插拔接口，允许不同证书提供者共存。
如何试用 Pod Certificates？
由于核心 Kubernetes 尚未内置签名器，需要安装第三方签名器，例如 Tinycert。Tinycert 是一个玩具实现，适合实验和作为开发基础。
Pod Certificates 的签名器是可插拔的，这意味着什么？
意味着 Kubelet 提供通用机制，但证书签发逻辑通过接口实现，可以在同一集群中同时运行多种不同类型的证书签发器，满足不同用途。
