Kubernetes 中的后量子密码学
随着量子计算的出现，密码学世界正处于一场重大变革的风口浪尖。虽然强大的量子计算机在许多应用中很大程度上仍是理论性的，但它们破解当前密码学标准的潜力是一个严重的问题，特别是对于长期运行的系统。这就是“后量子密码学”（PQC）的用武之地。在本文中，我将深入探讨 PQC 对 TLS 的意义，更具体地说，对 Kubernetes 生态系统的意义。我将解释 Kubernetes 中 PQC 的（令人惊讶的）现状，以及这对当前和未来的集群意味着什么。
什么是后量子密码学
后量子密码学指的是那些被认为能够抵御经典计算机和量子计算机攻击的密码学算法。主要担忧是，量子计算机使用像Shor 算法这样的算法，可以高效地破解广泛使用的公钥密码系统，如 RSA 和椭圆曲线密码学（ECC），这些是当今安全通信（包括 TLS）的基础。业界正在积极致力于标准化和采用 PQC 算法。由 NIST 首批标准化的算法之一是模块格密钥封装机制（ML-KEM），以前称为 Kyber，现在标准化为 FIPS-203（PDF 下载）。
很难预测量子计算机何时能够破解经典算法。然而，很明显，我们需要立即开始迁移到 PQC 算法，如下一节所示。为了对预测的时间线有一个感觉，我们可以参考一份涵盖向后量子密码学标准过渡的 NIST 报告。该报告宣布，使用经典密码学的系统应在 2030 年后弃用，并在 2035 年后禁用。
密钥交换与数字签名：不同的需求，不同的时间线
在 TLS 中，我们需要保护两个主要的密码学操作：
密钥交换：这是客户端和服务器就共享密钥达成一致以加密其通信的方式。如果攻击者今天记录了加密流量，他们将来如果获得了能够破解密钥交换的量子计算机，就可以解密这些流量。这使得将 KEMs 迁移到 PQC 成为当务之急。
数字签名：这些主要用于通过证书验证服务器（有时也包括客户端）的身份。服务器的真实性在连接时进行验证。虽然很重要，但今天遭受攻击的风险要低得多，因为信任服务器的决定不能在事后被滥用。此外，与经典算法相比，当前的 PQC 签名方案通常会带来显著的计算开销和更大的密钥/签名尺寸。
迁移到 PQ 证书的另一个重要障碍是根证书的升级。这些证书具有很长的有效期，并且作为信任锚安装在许多设备和操作系统中。
鉴于这些差异，TLS 中立即采用 PQC 的重点是混合密钥交换机制。这些机制将经典算法（如椭圆曲线 Diffie-Hellman 临时密钥交换（ECDHE））与 PQC 算法（如 ML-KEM）相结合。只要其中至少一个组成算法未被破解，由此产生的共享密钥就是安全的。X25519MLKEM768 混合方案是支持最广泛的一种。
当今 PQC 密钥交换机制（KEMs）的现状
整个生态系统对 PQC KEMs 的支持正在迅速改善。
Go：Go 标准库的 crypto/tls 包在 1.24 版本（2025 年 2 月发布）中引入了对 X25519MLKEM768 的支持。关键是，当没有显式配置时（即 Config.CurvePreferences 为 nil），它是默认启用的。
浏览器和 OpenSSL：主流浏览器如 Chrome（131 版，2024 年 11 月）和 Firefox（135 版，2025 年 2 月），以及 OpenSSL（3.5.0 版，2025 年 4 月），也增加了对基于 ML-KEM 的混合方案的支持。
苹果公司也在其操作系统的第 26 版中推出对 X25519MLKEM768 的支持。考虑到苹果设备的普及率，这将对全球 PQC 的采用产生重大影响。
有关更广泛行业中 PQC 现状的更详细概述，请参阅 Cloudflare 的这篇博客文章。
Kubernetes 中的后量子 KEMs：一次意外的到来
那么，这对 Kubernetes 意味着什么呢？Kubernetes 的组件，包括 API 服务器和 kubelet，都是用 Go 构建的。
截至 2025 年 4 月发布的 Kubernetes v1.33，该项目使用 Go 1.24。快速检查 Kubernetes 代码库发现，Config.CurvePreferences 并未显式设置。这得出了一个有趣的结论：Kubernetes v1.33，由于使用了 Go 1.24，默认支持混合后量子 X25519MLKEM768 进行 TLS 连接！
你可以自己测试一下。如果你设置一个运行 Kubernetes v1.33.0 的 Minikube 集群，你可以使用最新的 OpenSSL 客户端连接到 API 服务器：
$ minikube start --kubernetes-version=v1.33.0
$ kubectl cluster-info
Kubernetes control plane is running at https://127.0.0.1:<PORT>
$ kubectl config view --minify --raw -o jsonpath=\'{.clusters[0].cluster.certificate-authority-data}\' | base64 -d > ca.crt
$ openssl version
OpenSSL 3.5.0 8 Apr 2025 (Library: OpenSSL 3.5.0 8 Apr 2025)
$ echo -n "Q" | openssl s_client -connect 127.0.0.1:<PORT> -CAfile ca.crt
[...]
Negotiated TLS1.3 group: X25519MLKEM768
[...]
DONE
看吧，协商的组是 X25519MLKEM768！这是使 Kubernetes 具备量子安全性的重要一步，似乎没有经过重大公告或专门的 KEP（Kubernetes 增强提案）。
Go 版本不匹配的陷阱
Go 1.23 和 1.24 版本出现了一个有趣的问题。Go 1.23 包含了对 ML-KEM 草案版本的实验性支持，标识为 X25519Kyber768Draft00。如果 Config.CurvePreferences 为 nil，这个功能也是默认启用的。Kubernetes v1.32 使用了 Go 1.23。然而，Go 1.24 移除了草案支持，并将其替换为标准化版本 X25519MLKEM768。
如果客户端和服务器使用不匹配的 Go 版本（一个使用 1.23，另一个使用 1.24）会发生什么？它们将没有共同的 PQC KEM 可供协商，握手将回退到经典的 ECC 曲线（例如 X25519）。这在实践中是如何发生的呢？
考虑一个场景：
一个 Kubernetes 集群正在运行 v1.32（使用 Go 1.23，因此支持 X25519Kyber768Draft00）。一位开发者将其 kubectl 升级到 v1.33，该版本使用 Go 1.24 编译，只支持 X25519MLKEM768。现在，当 kubectl 与 v1.32 的 API 服务器通信时，它们不再共享一个共同的 PQC 算法。连接将降级为经典密码学，悄无声息地失去了已经存在的 PQC 保护。这凸显了理解 Go 版本升级的影响以及 TLS 栈细节的重要性。
限制：数据包大小
使用 ML-KEM 的一个实际考虑是其公钥的大小，对于 ML-KEM-768，编码后的密钥大小约为 1.2 千字节。考虑到典型的网络限制（最常见的是标准以太网帧大小限制为 1500 字节），这可能导致初始的 TLS ClientHello 消息无法容纳在单个 TCP/IP 数据包中。一些 TLS 库或网络设备可能无法妥善处理这种情况，因为它们假设 Client Hello 总是适合一个数据包。在一些与 Kubernetes 相关的项目和网络组件中已经观察到这个问题，当使用 PQC KEMs 时可能导致连接失败。更多细节可以在 tldr.fail 找到。
后量子签名的现状
虽然 KEMs 正在被更广泛地采用，但 PQC 数字签名在集成到标准工具链方面则较为落后。NIST 已经发布了 PQC 签名标准，例如 ML-DSA (FIPS-204) 和 SLH-DSA (FIPS-205)。然而，以一种广泛可用的方式实现这些标准（例如，用于 PQC 证书颁发机构）存在挑战：
更大的密钥和签名：与 Ed25519 或 RSA 等经典算法相比，PQC 签名方案通常具有大得多的公钥和签名大小。例如，Dilithium2 密钥可以比 Ed25519 密钥大 30 倍，证书可以大 12 倍。
性能：签名和验证操作可能要慢得多。虽然某些算法与经典算法相当，但其他算法可能会有更高的开销，有时性能会差 10 到 1000 倍。为了改善这种情况，NIST 正在为 PQC 签名进行第二轮标准化。
工具链支持：主流的 TLS 库和 CA 软件尚未对这些新的签名算法提供成熟的内置支持。例如，Go 团队已表示，支持 ML-DSA 是一个高优先级任务，但它最早可能出现在标准库中的时间是 Go 1.26 （截至 2025 年 5 月）。
Cloudflare 的 CIRCL（Cloudflare 可互操作可重用密码学库）库实现了一些 PQC 签名方案，如 Dilithium 的变体，并且他们维护了一个集成了 CIRCL 的 Go 的分支 (cfgo)。使用 cfgo，可以尝试生成用 PQC 算法（如 Ed25519-Dilithium2）签名的证书。然而，这需要使用自定义的 Go 工具链，并且尚未成为主流 Kubernetes 或 Go 发行版的一部分。
结论
通往后量子安全 Kubernetes 的旅程已经开始，并且可能比许多人意识到的要走得更远，这要归功于 Go 对 ML-KEM 的积极采用。在 Kubernetes v1.33 中，用户已经在许多 TLS 连接中默认受益于混合后量子密钥交换。
然而，意识到潜在的陷阱，例如 Go 版本不匹配导致降级和 Client Hello 数据包大小问题，是至关重要的。虽然 PQC 用于 KEMs 正在成为现实，但用于数字签名和证书层次结构的 PQC 仍处于开发和主流采用的早期阶段。作为 Kubernetes 的维护者和贡献者，了解这些发展将是确保平台长期安全的关键。