Quantum-resistant mTLS on Kubernetes

During KubeCon 2025 we attended a live demo about Quantum-Resistent Cloud Native infrastructure with SPIFFE. While they did demonstrate a working implementation, they did not go into detail about the used technologies and tools. In this blog post we want to cover those technologies and tools they used to implement quantum-resistant mutual TLS (mTLS) on Kubernetes.

You can watch the KubeCon demo on Youtube.

Technologies

mTLS

Mutual TLS (mTLS) is a method for the mutual authentication of two parties. It is usually used in zero-trust architecture where nothing is trusted by default, no device, user or application. mTLS makes sure that each party is who they claim to be by verifying that they both have a correct private key.

The difference between TLS and mTLS is that with TLS only one party initially has a private key. To setup a connection between parties (client-server), a handshaking procedure takes place. During this handshake both parties agree on which cryptographic method (cipher suite) is used and the server shares a public key contained in a certificate to the client with proof from a trusted third party (certificate authority) that the server has the private key belonging to the shared public key. The client can verify this certificate with the third party. Now, only a one-way asymmetric encrypted connection is used from server to client. To have encryption both ways, client to server and server to client, a key exchange must happen. During this exchange both parties generate a shared session key. How this exchange is done is dependent on the chosen cipher suite. Now that both parties have the session key, a two-way symmetric encrypted connection is possible.

In mTLS however, both the server and client can already send their public key to the other party. Both parties verify the received public key to make sure the other party is trusted. Just like TLS, a shared session key is generated for further communication.

SPIFFE/SPIRE

Now that we know how mTLS works, how can we give every party a key that is trusted by every other party?

This is where SPIRE comes in. SPIRE is an implementation of the SPIFFE APIs for workload attestation. In terms of SPIFFE, a workload can range from a single process to multiple grouped nodes. To identify workloads, they get assigned an ID in the form of an URI spiffe://<trust domain>/<workload identifier>. The trust domain is the trust root and can represent anything from an individual, organisation or even a department. The ID is contained within the SPIFFE Verifiable Identity Document (SVID). This document is valid if signed by the trust root of the ID. The SPIFFE API provides identities, private keys to sign data on behalf of the workload and a set of certificates (trust bundle) that workloads can use to verify other workload SVIDS.

For increased security, all private keys in SPIFFE are short-lived and frequently rotated. Furthermore, workloads do not know about their own identity and do not posses any form of authentication token for the API.

SPIRE can be deployed in Kubernetes and consists of a server and multiple agents. The agents expose the SPIFFE workload API to the workloads while the server is the signing authority that contains a registry of all workload identities. Before the server issues identities, the workload must pass various conditions first. Every node in the cluster must have an agent running that can connect to the central SPIRE server.

Specifically for mTLS we can use SPIRE to dyanmically provide identities in the form of X.509 certificates (X.509 SVID). This is also where Envoy comes in the picture. Using Envoy’s Secrets Discovery Service (SDS) feature, SPIRE can distribute the certificates to every workload. It is then up to Envoy to use the certificates to establish mTLS between workloads.

Envoy and Cilium

We have seen that SPIRE can provide the required certificates to Envoy to establish mTLS between workloads. But what exactly is Envoy?

Envoy is a L7 proxy that runs alongside workloads as a sidecar. The envoy proxy handles the connection between workloads while verifying the certificates provided by SPIRE. It should be noted that the demo does not use Envoy as explained in this post. The demo instead shows us mTLS using Cilium. Cilium, like envoy, can establish mTLS between workloads as a service mesh. A service mesh is in essence a layer that handles communication between all services. Cilium uses eBPF for protocols like TCP and UDP but uses a per-node Envoy proxy for protocols at the application layer like HTTP. Because Cilium uses eBPF, it can work without the sidecar proxies for workloads.

Cilium can be configured to receive X.509 certificates from SPIRE. It does this using Cilium agents as intermediate actors between the workloads and the SPIRE agents. The agents receive a common SPIFFE identity and will request identities on behalf of the workloads.

Post-Quantum Cryptography for mTLS

Now that we known which tools are needed to implement mTLS in kubernetes, we still do not know how any of these can be quantum resistant. A well known algorithm that could potentially attack asymmetric cryptography in our tools above, is Shor’s algorithm. This algorithm, designed in 1994, works on a mathematical model of a quantum computer. Therefor, Shor’s algorithm requires a quantum computer with enough qubits and without succumbing to quantum noise to run. While such a quantum computer is not feasible yet, it is just a matter of time.

A possible solution to implement quantum-resistant mTLS are Dilithium3 X.509 certificates together with Kyber key encapsulation mechanism (KEM). Dilithium is a digital signature algorithm (DSA) and is employed for asymmetric cryptography. As explained above, this can be used in mTLS to verify the other party. To then set up the session key, Kyber KEM can be used. These cryptographic algorithms are build on an NP-Hard mathematical lattice problem. Both Dilithium and Kyber KEM have been standardized by NIST as respectively ML-DSA and ML-KEM.

To make the above tools use quantum-resistant cryptography, they should be configured to use the ML-DSA and ML-KEM standards. Thus configuring SPIRE to hand out Dilithium3 X.509 certificates and configuring Cilium/Envoy to enforce the use of Kyber KEM.

Conclusion

The KubeCon demo showed us a working implementation of quantum-secure mTLS on kubernetes. This blog post on the other hand explained the technologies and tools they used for the demo and how they could be implemented for quantum-secure communication between workloads. It should be noted that the proposed cryptographic algorithm, ML-DSA and ML-KEM, might still be vulnerable to some currently unknown attacks. Furthermore, while currently no quantum computer exists that could successfully implement Shor’s algorithm to attack asymmetric cryptography, it is just a matter of time before such a computer is built.

The demo also warned that migrating from outdated cryptographic algorithms can take a lot of time, in the order of 15 to 20 years! They presented this in the form of Mosca’s Theorem that states: If the time the data must remain secure together with the time it takes to migrate to a new cryptographic system is greater than the time it takes to build a strong enough quantum computer, then it is already too late.

Sources