量子计算时代即将到来，其强大的处理能力对数字世界的加密基础构成了重大威胁。在本文中，我们将探讨红帽 OpenShift 4.20 中对后量子密码学（PQC）的新兴支持，重点介绍它如何增强 Kubernetes 控制平面的核心组件：apiserver、kubelet、调度程序和控制器管理器。缺少 etcd，使用的是较旧版本的 Go。
量子威胁
当今广泛使用的公钥加密系统，如 RSA 和椭圆曲线加密技术（ECC），构成了安全增强型在线通信的基础。然而，这些系统很容易受到大规模量子计算机的攻击，而大规模量子计算机能够以惊人的速度解决这些算法背后的数学问题。这引发了一些攻击，其中攻击者会记录当前的加密流量，以便在将来访问强大的量子计算机时解密。同样的挑战也适用于静态数据，如果攻击者设法现在制作副本以供以后解密。
为了应对这种威胁，PQC 领域应运而生，它开发了新的加密算法，可以抵御来自经典计算机和量子计算机的攻击。
Kubernetes 和 OpenShift 中的 PQC
红帽 OpenShift 是经过云原生计算基金会（CNCF）认证的 Kubernetes 发行版，而 Kubernetes 是用 Go 编程语言编写的。因此，OpenShift 中的 PQC 支持之旅始于 Go。
Go 1.24 版本引入了对 X25519MLKEM768 混合密钥交换机制的支持，标志着一个重要的里程碑。X25519MLKEM768 是一种混合密钥交换，结合了经典的 X25519（椭圆曲线 Diffie-Hellman）和 ML-KEM-768（后量子算法）。最终的共享机密由这两种机制组合而成。纯 ML-KEM 完全依赖于基于网格的加密技术来实现量子抗性。X25519MLKEM768 同时为您提供 ML-KEM 的量子抗性和 X25519 的经典安全性。
目前，混合方法确实更加可靠。ML-KEM 直到 2024 年 8 月才实现标准化，这意味着它在密码学术语中被认为是“年轻的”。如果有人发现针对 ML-KEM 格假设的意外经典攻击（不是量子攻击，只是常规密码分析），纯 ML-KEM 部署就会遭到破坏。使用混合方法时，X25519 仍将占据主导地位。
只要至少有一个组件算法保持不变，生成的传输层安全性 (TLS) 会话共享机密就能提供预期的安全级别。这提供了一种可靠且向前兼容的方式，将 PQC 引入生态系统。
将 PQC 应用于 OpenShift 控制平面
OpenShift 4.20 中对 PQC 的支持不是在每个 Kubernetes 组件上配置特定的 PQC 标志。相反，它关乎这些组件之间 TLS 通信的强度，这由 Go 的底层版本及其加密库启用。
以下是 PQC 支持如何增强核心 OpenShift 组件之间通信的安全性（etcd 状态将在下文单独讨论）：
- API 服务器：作为 Kubernetes 控制平面的中央枢纽，进出 API 服务器的所有通信都是关键的安全点。借助启用了 ML-KEM 的 TLS，可以保护控制平面通信免受当前记录加密流量并计划在未来解密的攻击。
- Kubelet：在每个节点上运行的 kubelet 与 API 服务器通信，以提供节点状态更新并接收 pod 规格。这种通信现在包含了混合 PQC 密钥交换，以增强安全性，有助于验证此链路的完整性和机密性。
- 调度程序和控制器管理器：调度程序和控制器管理器不断与 API 服务器交互，以做出调度决策并管理集群状态。这些交互也受到支持 ML-KEM 的 TLS 保护，以加强保持应用运行的逻辑和操作的安全性。
红帽观点
尽管许多行业法规不要求在 2035 年之前实施 PQC，但我们正在积极致力于向 PQC 过渡。在最近的一篇文章《让您的企业组织为量子未来做好准备》中，我们强调了现在就开始 PQC 之旅的重要性。此外，正在开展的将 PQC 集成到红帽企业 Linux（RHEL）的工作有力地表明了 OpenShift 的发展方向。OpenShift 4.20 中包含的 PQC 功能是向前迈出的重要一步。
Go 版本不匹配
管理员需要考虑的一个关键因素是集群中不同组件之间可能存在 Go 版本不匹配的情况。例如，如果使用支持 ML-KEM 的 Go 版本构建的 kubectl 客户端与较旧的 API 服务器通信，则 TLS 握手可能会以静默方式降级为经典加密算法。这将导致在没有任何明确警告的情况下失去 PQC 保护。因此，务必要确认 OpenShift 环境中的所有组件都运行支持 PQC 的兼容版本。
那么 etcd 呢？
虽然核心控制平面组件受益于支持 ML-KEM 的 TLS，但由于其独特的角色和开发理念，etcd 的情况有所不同。作为整个集群的最终事实来源，etcd 的绝对优先事项是稳定性、数据完整性和性能。与 Kubernetes 相比，etcd 项目特意维护了更为保守的 Go 版本控制计划。Kubernetes 项目通常采用最新的 Go 版本来快速使用新功能和性能改进，而 etcd 团队则优先考虑稳定性，坚持使用较旧、经过更多实战检验的 Go 版本作为其稳定版本。这种有意的延迟有助于更广泛的社区在新的 Go 运行时引入像 etcd 这样关键的组件之前彻底审查其潜在问题。
缺乏即时的 PQC 支持并非疏忽，而是这种稳定性优先方法的直接后果。在 Go 1.24 中引入的 PQC 算法可以在 etcd 中得到正式支持之前，该 Go 版本必须首先被采用到 etcd 的 stable 发行分支中，该分支目前仍在使用 Go 1.23。此过程涉及广泛的验证，以确认不会对 Raft 共识协议、I/O 延迟或恢复操作产生负面影响。请继续关注未来版本中 etcd 中的量子安全支持。
未来的发展方向
PQC 集成到 OpenShift 4.20 中，证明了红帽正在采取积极主动的方法，为云原生计算开发量子就绪型未来。虽然数字签名和证书的 PQC 仍处于早期阶段，但在 TLS 中实施混合密钥交换是关键的第一步。
