TLS post-quantique hybride sur un ingress Kubernetes

Dans un cluster Kubernetes, le TLS post-quantique hybride se configure là où la poignée de main se termine réellement, presque jamais dans le conteneur applicatif. Ce point est généralement le pod du contrôleur d'ingress, un équilibreur de charge cloud placé devant lui, ou un sidecar de service mesh. Le travail se fait en quatre étapes : trouver le véritable point de terminaison, vérifier la version de la bibliothèque TLS qui s'y exécute, placer un groupe hybride tel que X25519MLKEM768 devant un groupe classique dans la liste de préférence, puis vérifier depuis l'extérieur du cluster.

Étape 1 : trouver où la poignée de main se termine réellement

Les équipes configurent souvent le mauvais composant et en concluent que leur contrôleur ne prend pas en charge l'échange de clés post-quantique. Commencez par cartographier le chemin d'un paquet client. Seul le composant qui détient la clé privée et envoie le ServerHello décide du groupe d'échange de clés.

Confirmez la topologie avec des commandes en lecture seule avant de modifier quoi que ce soit :

kubectl get ingress -A -o wide
kubectl -n ingress-nginx get svc -o wide
kubectl -n ingress-nginx get svc ingress-nginx-controller -o jsonpath='{.metadata.annotations}'

Les annotations d'équilibreur de charge sur le Service du contrôleur indiquent si la couche cloud termine TLS ou le laisse passer. Si elle le termine, aucun paramètre de l'ingress ne modifiera le groupe négocié.

Étape 2 : vérifier ce que prend en charge la bibliothèque TLS du contrôleur

Les groupes hybrides sont une propriété de la pile TLS compilée dans l'image du contrôleur, pas de Kubernetes. Pour les builds basées sur OpenSSL, OpenSSL 3.5 ou ultérieur est requis pour les groupes ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism). Les plans de données basés sur BoringSSL, comme Envoy, utilisent leur propre nommage des groupes et leur propre matrice de prise en charge : lisez les notes de version de la version exacte que vous exécutez.

kubectl -n ingress-nginx exec deploy/ingress-nginx-controller -- openssl version

Si cette version est antérieure à 3.5, arrêtez-vous ici et planifiez une mise à niveau du contrôleur. Aucune clé de configuration ne peut activer un groupe que la bibliothèque n'implémente pas.

Les noms de groupes et les codepoints IANA que vous pouvez légitimement utiliser sont publiés dans le registre des paramètres TLS (iana.org) :

• X25519MLKEM768 (0x11EC, 4588), le choix par défaut de fait des navigateurs aujourd'hui, décrit sur notre page X25519MLKEM768.
• SecP256r1MLKEM768 (0x11EB, 4587) et SecP384r1MLKEM1024 (0x11ED, 4589), pour les environnements qui exigent des courbes NIST.
• Les groupes ML-KEM purs MLKEM512, MLKEM768 et MLKEM1024 (512, 513, 514). Ils ne sont pas hybrides : la plupart des lecteurs ne devraient pas encore les déployer en périphérie publique.

L'accord de clés hybride pour TLS 1.3 est spécifié dans la RFC 10024 (rfc-editor.org). ML-KEM lui-même fait l'objet de FIPS 203, définitif depuis le 13 août 2024 (csrc.nist.gov). Le groupe préstandard issu du brouillon Kyber, X25519Kyber768Draft00 (0x6399), est obsolète : s'il apparaît quelque part dans votre configuration, supprimez-le.

Étape 3 : configurer les groupes, avec un repli classique

Un seul groupe d'échange de clés est négocié par connexion, et le serveur choisit parmi ceux proposés par le client. Placer un groupe hybride en premier et un groupe classique après lui est donc sûr par construction : les clients qui connaissent le groupe hybride l'utilisent, les clients plus anciens se replient sur X25519 ou P-256.

ingress-nginx

Le contrôleur expose la clé de ConfigMap ssl-ecdh-curve, qui correspond à la directive nginx ssl_ecdh_curve et est transmise à la bibliothèque TLS sous forme de liste ordonnée de groupes (sa valeur par défaut est auto). Confirmez cette clé dans la référence ConfigMap de la version du contrôleur que vous exécutez, puis appliquez :

apiVersion: v1
kind: ConfigMap
metadata:
  name: ingress-nginx-controller
  namespace: ingress-nginx
data:
  ssl-protocols: "TLSv1.3 TLSv1.2"
  ssl-ecdh-curve: "X25519MLKEM768:X25519:prime256v1"

Ici, prime256v1 est le nom OpenSSL de secp256r1. Conserver deux groupes classiques après le groupe hybride préserve les clients TLS 1.2 et tout client TLS 1.3 qui n'implémente pas ML-KEM. La même logique d'ordonnancement s'applique à un serveur web autonome, comme le décrit notre guide pour activer ML-KEM sur nginx, Apache, HAProxy et Caddy.

Autres contrôleurs et service meshes

Ne copiez pas d'annotations d'un contrôleur à l'autre. Une annotation que le contrôleur ne reconnaît pas est ignorée sans avertissement, ce qui constitue ici le mode de défaillance le plus dangereux : le déploiement semble réussi et rien n'a changé. Le principe est partout identique, seule l'interface diffère :

• Les plans de données basés sur Envoy exposent des paramètres TLS qui incluent une liste de courbes ECDH. Dans un mesh, ce champ est généralement accessible via un mécanisme de patch avancé plutôt que via une API de premier niveau : consultez la documentation de votre version de mesh et de proxy.
• Les contrôleurs basés sur HAProxy et Traefik définissent la liste de groupes dans leurs propres objets de configuration. Recherchez la clé exacte dans la documentation du contrôleur pour votre version et validez-la en préproduction.
• Si un équilibreur de charge managé termine TLS, votre seul levier est la politique TLS du fournisseur. Si aucune politique hybride n'est proposée, l'alternative consiste à déplacer la terminaison dans le cluster derrière un service passthrough de couche 4, ce qui est un changement d'architecture et mérite sa propre revue.

Ne touchez pas à la chaîne de certificats pour l'instant

Le trafic enregistré n'est protégé que par l'échange de clés, et c'est tout l'enjeu de « harvest now, decrypt later » (collecter maintenant, déchiffrer plus tard) : un attaquant qui stocke aujourd'hui du texte chiffré pourra le déchiffrer plus tard si l'échange de clés était classique. Notre article sur harvest now, decrypt later explique pourquoi l'échange de clés passe en premier. Les certificats pourront migrer plus tard : les autorités de certification publiques émettent toujours des certificats ECDSA et RSA, et les signatures ML-DSA, normalisées dans FIPS 204, ne sont pas encore généralement disponibles dans les chaînes TLS publiques. Conservez votre émetteur cert-manager actuel sans modification pendant cette phase.

Étape 4 : vérifier depuis l'extérieur du cluster

Testez depuis une machine située sur l'internet public, par le même chemin qu'emprunte un navigateur. Ne vérifiez jamais avec kubectl port-forward : cette commande contourne l'équilibreur de charge et la périphérie, et peut donc afficher une poignée de main hybride qu'aucun client réel n'obtiendra jamais. Avec OpenSSL 3.5 ou ultérieur :

openssl s_client -connect www.example.com:443 -servername www.example.com \
  -groups X25519MLKEM768 </dev/null 2>/dev/null | grep -i 'Negotiated TLS1.3 group'

Un résultat positif affiche le groupe négocié. Prouvez ensuite que le repli fonctionne toujours, c'est le test que les équipes oublient :

openssl s_client -connect www.example.com:443 -servername www.example.com \
  -groups X25519 </dev/null 2>/dev/null | grep -i 'Negotiated TLS1.3 group'

Répétez les deux tests pour chaque nom d'hôte public, y compris le domaine apex et tout hôte servi par une seconde classe d'ingress ou un autre fournisseur de périphérie. Un cluster doté de deux classes d'ingress finit souvent à moitié migré. Ce qu'un test externe peut montrer, et ce qu'il ne peut pas montrer, est décrit dans notre méthodologie du scanner.

Étape 5 : déployer et conserver les preuves

1. Appliquez d'abord la modification en préproduction, sur un contrôleur qui exécute le même tag d'image que la production.
2. Promouvez-la sur un seul nom d'hôte de production ou une seule classe d'ingress canari, pas sur l'ensemble du parc.
3. Surveillez les erreurs de poignée de main TLS et le CPU du contrôleur pendant au moins un cycle d'activité complet. Les parts de clé ML-KEM sont plus volumineuses qu'une part X25519 : les messages ClientHello et ServerHello grossissent.
4. Gardez le retour arrière prêt : rétablir la valeur précédente de la clé de ConfigMap restaure l'ancien comportement au rechargement suivant.
5. Consignez le résultat dans votre inventaire cryptographique, avec la date et l'hôte testé.

C'est à cette dernière étape qu'un changement de plateforme devient une preuve de conformité. La correspondance ci-dessous reflète notre lecture de la manière dont l'artefact technique répond à l'exigence ; il ne s'agit pas d'une citation des textes. Ces éléments sont fournis à titre d'information et ne constituent pas un avis juridique.

Étape suivante

Une fois la ConfigMap appliquée et vos tests de préproduction réussis, confirmez le résultat visible de l'extérieur : analysez votre domaine avec PQC Status pour voir quel groupe d'échange de clés votre ingress négocie réellement, quelles versions de TLS il propose et à quoi ressemble la chaîne de certificats. Lancez l'analyse une fois par nom d'hôte public, avant et après chaque mise à niveau de l'image du contrôleur, car un changement d'image peut vous ramener silencieusement à un groupe classique. Une analyse décrit uniquement la configuration TLS visible de l'extérieur : ce n'est ni une certification ni une attestation de conformité.