Post-Quantum Cryptography
Red Hat OpenShift
Red Hat OpenShift leverages RHEL-based post-quantum cryptography to protect internal control plane traffic, mesh-managed microservices, and cluster ingress routing against quantum-era threats — a feature-by-feature look at OpenShift's PQC readiness, constraints, and roadmap.
On this page
PQC overview Scope Constraints Harvest Now, Decrypt Later Quantum Forgery Cryptographic policy evaluation
For threat model definitions — Harvest Now, Decrypt Later and Quantum Forgery — and status definitions, see Post-Quantum Cryptography at Red Hat.
PQC overview
As a critical cloud-native platform and container orchestration layer, Red Hat OpenShift requires a comprehensive Post-Quantum Cryptography (PQC) strategy to protect internal control plane traffic, mesh-managed microservices, and cluster ingress routing. This assessment covers the PQC roadmap, transitions, and threat landscape across active streams of OpenShift.
OpenShift relies heavily on the underlying Red Hat Enterprise Linux (RHEL) and RHEL CoreOS (RHCOS) instances for foundational cryptographic building blocks, centralizing security baseline inheritance, but also relies heavily on Go cryptography for day-to-day cryptographic operations within and between containers.
Scope
|
In-scope components
|
Out-of-scope (already quantum-resistant)
|
Constraints
Go upstream
The OpenShift ecosystem is bound by the Go language toolchain. Upstream Go (crypto/x509) does not plan to support native ML-DSA digital signatures until Go 1.27. Consequently, OpenShift's focus is on ML-KEM key encapsulation, with ML-DSA signatures under active development.
IPsec timing gaps
Consumption of fully functional PQC IPsec with persistent session re-keying is blocked until the host kernel upgrades to RHEL components that integrate this support. This delays native cluster-wide network tunnel quantum-safety until development progresses.
Operator enforcement gap
Cluster-level cryptographic policies or TLS profiles are currently not universally inherited by downstream operators, with full General Availability enforcement planned for a future release.
FIPS mutual exclusivity
Due to a lack of mature certified PQC modules from NIST, running clusters in FIPS compliance mode restricts operations to specific approved classical or hybrid curves, for example, SecP256r1MLKEM768, making pure PQC and FIPS mode mutually exclusive until certification.
Threat: Harvest Now, Decrypt Later (HNDL)
At-a-glance PQC status for each OpenShift capability against passive data-harvesting attacks. Expand any capability below the table for notes and references.
| Capability | Status | Min. version | Risk |
|---|---|---|---|
| Internal control plane traffic Kube-apiserver, kubelet scheduler, controllers |
PQ-Capable | OpenShift 4.20+ | High |
| Mesh-managed microservice traffic (mTLS) Service Mesh (Envoy proxy) |
PQ-Capable | OpenShift 4.21 | High |
| Platform-wide web ingress and APIs OpenShift APIs (Control Plane) |
PQ-Capable | OpenShift 4.20+ | High |
| Platform-wide web ingress and APIs Platform Web Ingress (The Router) |
PQ-Capable | All supported OpenShift versions | High |
| Internal cluster storage data etcd backend (data-in-transit) |
Under active development | — | Medium |
| Internal cluster storage data etcd backend (data-at-rest) |
PQ-Ready | Already quantum safe, all versions | — |
| Node-to-node inter-cluster encryption OVS-IPsec Tunnels |
Under active development | — | High |
| Node-to-node inter-cluster encryption Service-to-Service via OpenShift Service Mesh 3.3 |
PQ-Capable | Service Mesh 3.3 | — |
| Node-to-node inter-cluster encryption Service-to-Service via standard pod-to-pod traffic |
PQC not supported | — | — |
Notes & references
▸ Internal control plane traffic — Kube-apiserver, kubelet scheduler, controllers
Communication between kube-apiserver, kubelet, and etcd could be intercepted via HNDL. This is data-in-transit; 4.20 includes support for securing internal TLS 1.3 communications using hybrid key exchange x25519 + ML-KEM-768. FIPS note: No support for FIPS mode, due to lack of NIST validated modules.
Post-quantum cryptography support in Red Hat OpenShift 4.20 control plane
▸ Mesh-managed microservice traffic (mTLS) — Service Mesh (Envoy proxy)
East-west microservice data traffic is susceptible to active data collection and retroactive decryption via HNDL. Support for hybrid key exchange (x25519 + ML-KEM-768) across ingress/egress proxy endpoints; protects east/west inter-container comms via OpenShift Service Mesh 3.3. In-mesh traffic (mTLS): pod-to-pod mTLS traffic routed between sidecars or via the new ambient mode ztunnels can negotiate the hybrid PQC kex. Ingress/Egress Gateways: traffic entering or leaving the mesh through Istio Gateways can be locked down with quantum-safe TLS 1.3 configurations.
Introducing OpenShift Service Mesh 3.3 with post-quantum cryptography
Release Notes | Red Hat OpenShift Service Mesh | 3.3
▸ Platform-wide web ingress and APIs — OpenShift APIs (Control Plane)
Public-facing ingress traffic risks data exposure unless hybrid key encapsulation mechanisms are enforced. The kube-apiserver natively supports the x25519 + ML-KEM-768 hybrid key exchange by default.
▸ Platform-wide web ingress and APIs — Platform Web Ingress (The Router)
Public-facing ingress traffic risks data exposure unless hybrid key encapsulation mechanisms are enforced. The OpenShift Ingress Controller (powered by HAProxy) manages application routes and the OpenShift Web Console is capable of PQC key exchange, but requires a manual configuration shift. The OpenShift Ingress Controller relies on OpenSSL from RHEL 9 and requires the container crypto policy to be set to DEFAULT:PQ to enable PQC algorithms, which should be the default in OCP 5.0.
▸ Internal cluster storage data — etcd backend (data-in-transit)
HNDL cannot read API server traffic, but could potentially sniff internal master-node network traffic to intercept etcd replication data if they have deep infrastructure access. Peer TLS and API-server-to-etcd TLS use classical key exchange; PQC is under development.
Quantum-secure gateways in Red Hat OpenShift Service Mesh 3.2
▸ Internal cluster storage data — etcd backend (data-at-rest)
OpenShift uses AES-GCM (256-bit) or AES-CBC to encrypt etcd values at rest, and these algorithms are already quantum-safe.
▸ Node-to-node inter-cluster encryption — OVS-IPsec Tunnels
Lack of persistent session re-keying support allows traffic decryption after the initial handshake expiration window. OpenShift node-to-node IPsec (OVS-IPsec/Libreswan) does not yet offer PQC key exchange. Enabling native IPsec encrypts internode traffic with traditional cryptography today.
▸ Node-to-node inter-cluster encryption — Service-to-Service via OpenShift Service Mesh 3.3
If customers deploy Service Mesh 3.3 across their nodes, pod-to-pod mTLS traffic moving between different nodes uses x25519 + ML-KEM-768 out-of-the-box. This secures application level payloads even if the underlying node network is unencrypted.
▸ Node-to-node inter-cluster encryption — Service-to-Service via standard pod-to-pod traffic
Standard application pods communicating via normal cluster IPs across nodes w/o a Service Mesh or IPsec rely on whatever crypto the developer compiled into the application container itself.
Threat: Quantum Forgery
At-a-glance PQC status for each OpenShift capability against signature-forgery attacks. Expand any capability below the table for notes and references.
| Capability | Status | Min. version | Risk |
|---|---|---|---|
| Admission controller Sigstore verification |
Under active development | — | High |
| Platform-wide web ingress and APIs Server Authentication |
Under active development | — | High |
| Runtime image verification CRI-O/Podman |
PQ-Capable | OpenShift 4.22 | — |
| Go-native platform digital signatures | Under active development | — | — |
Notes & references
▸ Admission controller — Sigstore verification
Quantum Forgery allows bypass of release integrity, potentially permitting malicious updates to be executed without native parsing error controls. OpenShift native architecture ClusterImagePolicy natively enforces Sigstore image verification, but it does not yet enforce or support PQC signature validation in production.
▸ Platform-wide web ingress and APIs — Server Authentication
Quantum Forgery allows bypass of release integrity, potentially permitting malicious updates to be executed without native parsing error controls. The APIs and Web Ingress can use PQC to negotiate the session keys that encrypt data-in-transit, but neither can use PQC for Server Authentication (Certificates). When you hit the OpenShift Console via HTTPS, the identity of the server is still verified using traditional signatures like RSA or ECDSA.
▸ Runtime image verification — CRI-O/Podman
Nodes can manually parse primitive OpenPGP formats under custom configurations, but native runtime ML-DSA parsing is un-automated. FIPS note: No PQC support for FIPS mode.
▸ Go-native platform digital signatures
Go 1.27 will have pure ML-DSA support. Waiting on upstream release.
Cryptographic policy evaluation
While the admission controller can securely talk over a quantum-safe connection, the cryptographic checks it performs depend entirely on the specific tool being used, such as Gatekeeper, Kyverno, or OpenShift's native ClusterImagePolicy.
Image signature verification
Status: Under active development
Standard admission controllers checking container signatures use classical algorithms, ECDSA/RSA. Upstream groups are currently benchmarking post-quantum signature algorithms like ML-DSA (FIPS 204), but they are not yet production-ready due to the large payload sizes of PQC signatures, which can cause timeout issues in admission webhooks.
Policy-as-code (OPA/Gatekeeper/Kyverno)
Status: Dependent on third parties
These admission controllers evaluate text-based rules, like Rego or YAML constraints to block root containers. The admission controller itself doesn't need PQC to read text; however, if these policies rely on verifying external cryptographic tokens or artifacts, they remain bound to classical crypto until those upstream open-source projects explicitly add ML-DSA support.
