A deeper look at post-quantum cryptography support in Red Hat OpenShift 4.20 control plane

The age of quantum computing is on the horizon, and with its immense processing power comes a significant threat to the cryptographic foundations of our digital world. In this article, we’ll explore the emerging support for post-quantum cryptography (PQC) in Red Hat OpenShift 4.20, focusing on how it enhances the core components of the Kubernetes control plane: the apiserver, kubelet, scheduler, and controller-manager. Missing is etcd, using an older version of Go.

The quantum threat

Today’s widely used public-key cryptosystems, such as RSA and elliptic curve cryptography (ECC), form the foundation of security-enhanced online communication. These systems are vulnerable to attacks from large-scale quantum computers, however, which can solve the mathematical problems underlying these algorithms with alarming speed. This has given rise to attacks in which adversaries record encrypted traffic today to decrypt it in the future once they have access to a powerful quantum computer. The same challenge applies to data at rest if an adversary manages to make a copy now to decrypt later.

To counter this threat, the field of PQC has emerged, developing new cryptographic algorithms that are resistant to attacks from both classical and quantum computers.

PQC in Kubernetes and OpenShift

Red Hat OpenShift is a Cloud Native Computing Foundation (CNCF) certified distribution of Kubernetes, and Kubernetes is written in the Go programming language. Thus, the journey to PQC support in OpenShift begins with Go.

The Go 1.24 release marked a significant milestone by introducing support for the X25519MLKEM768 hybrid key exchange mechanism. X25519MLKEM768 is a hybrid key exchange that combines classical X25519 (elliptic curve Diffie-Hellman) with ML-KEM-768 (the post-quantum algorithm). The final shared secret is derived from both mechanisms combined. Pure ML-KEM relies entirely on lattice-based cryptography for quantum resistance. X25519MLKEM768 gives you ML-KEM’s quantum resistance and X25519’s classical security simultaneously.

The hybrid approach is genuinely more robust at the moment. ML-KEM was only standardized in August 2024, meaning that it’s considered “young” in cryptographic terms. If someone discovers an unexpected classical attack against ML-KEM’s lattice assumptions (not quantum, just regular cryptanalysis), pure ML-KEM deployments would be broken. With the hybrid, you still have X25519 holding the line.

The resulting shared secret for a Transport Layer Security (TLS) session provides the expected security level as long as at least one of the component algorithms remains unbroken. This offers a robust and forward-compatible way to introduce PQC into the ecosystem.

Applying PQC to the OpenShift control plane

The support for PQC in OpenShift 4.20 is not about configuring specific PQC flags on each Kubernetes component. Instead, it’s about the strength of the TLS communication between these components, which is enabled by the underlying version of Go and its cryptographic libraries.

Here’s how PQC support enhances the security of the communication between the core OpenShift components (etcd status is discussed separately below):

• API server: As the central hub of the Kubernetes control plane, all communication to and from the API server is a critical security point. With ML-KEM enabled TLS, the control plane communication is protected from attacks that record encrypted traffic today with plans to decrypt it in the future.
• Kubelet: The kubelet, running on each node, communicates with the API server to provide node status updates and receive pod specifications. This communication now incorporates a hybrid PQC key exchange for enhanced security, helping to verify the integrity and confidentiality of this link.
• Scheduler and controller-manager: The scheduler and controller-manager continually interact with the API server to make scheduling decisions and manage the cluster’s state. These interactions are also protected by the ML-KEM-enabled TLS to strengthen the security of the logic and operations that keep your applications running.

The Red Hat perspective

Although many industry regulations do not require PQC until 2035, we are actively working on the transition to PQC. In a recent article, “Preparing your organization for the quantum future,” we emphasize the importance of starting the PQC journey now. Furthermore, the work being done to integrate PQC into Red Hat Enterprise Linux (RHEL) is a strong indicator of the direction for OpenShift. The inclusion of PQC capabilities in OpenShift 4.20 is a significant step forward.

The Go version mismatch

A crucial consideration for administrators is the potential for a Go version mismatch between different components in a cluster. For example, if a kubectl client built with a ML-KEM-aware Go version communicates with an older API server, the TLS handshake may silently downgrade to a classical cryptographic algorithm. This would result in the loss of PQC protection without any explicit warning. It is therefore essential to confirm that all components in your OpenShift environment are running compatible versions that support PQC.

What about etcd?

While the core control plane components benefit from ML-KEM-enabled TLS, the story for etcd is different, rooted in its distinct role and development philosophy. As the definitive source of truth for the entire cluster, etcd’s absolute priorities are stability, data integrity, and performance. The etcd project intentionally maintains a more conservative Go versioning schedule compared to Kubernetes. While the Kubernetes project often adopts the latest Go release to use new features and performance improvements quickly, the etcd team prioritizes stability by sticking to older, more battle-tested Go versions for its stable releases. This deliberate lag helps the broader community thoroughly vet any potential issues in a new Go runtime before it’s introduced into a component as critical as etcd.

The lack of immediate PQC support is not an oversight but a direct consequence of this stability-first approach. Before PQC algorithms, introduced in Go 1.24, can be officially supported in etcd, that Go version must first be adopted into etcd’s stable release branches, which currently still use Go 1.23. This process involves extensive validation to confirm that there is no negative impact on the Raft consensus protocol, I/O latency, or recovery operations. Stay tuned for quantum-safe support in etcd in a future release.

The road ahead

The integration of PQC into OpenShift 4.20 is a testament to the proactive approach Red Hat is taking to develop a quantum-ready future for cloud-native computing. While PQC for digital signatures and certificates is still in its early stages, implementing hybrid key exchange in TLS is a critical first step.