Kubernetes 1.38 amorce la migration post-quantique avec les certificats ML-DSA

29 septembre 2026. L’équipe Kubernetes publie v1.38.0-alpha.1, la première préversion de la prochaine version mineure, construite avec Go 1.27.1. 29 septembre 2026. Le changelog ajoute le support bêta de la signature des certificats de pods avec ML-DSA, l’algorithme de signature post-quantique standardisé par le NIST. 29 septembre 2026. Les dépendances gRPC sont mises à niveau pour corriger CVE-2026-84445 et CVE-2026-84304. Pourquoi c’est important : c’est la première fois qu’un algorithme de signature post-quantique entre dans le cœur de Kubernetes, et cela donne aux plateformes un terrain concret pour tester leur migration avant que les ordinateurs quantiques ne rendent obsolètes les signatures RSA et ECDSA actuelles.

ML-DSA, la signature post-quantique de référence

ML-DSA (Module-Lattice-Based Digital Signature Algorithm) est la version standardisée de Dilithium, choisie par le NIST dans FIPS 204 en août 2024 parmi les trois algorithmes de signature retenus au terme du concours de cryptographie post-quantique. Elle repose sur la difficulté des problèmes de réseaux euclidiens (lattices), une famille de problèmes réputée résistante aux attaques d’un ordinateur quantique exécutant l’algorithme de Shor — à la différence de RSA et ECDSA, dont la sécurité s’effondre face à un tel ordinateur.

Le passage à ML-DSA a un coût assumé : des clés et des signatures nettement plus volumineuses que l’ECDSA actuel. C’est précisément pourquoi Kubernetes procède par étapes, en bêta d’abord, et pourquoi la migration n’a pas vocation à être activée partout du jour au lendemain. L’enjeu, pour un opérateur, n’est pas « faut-il migrer » mais « à quel rythme tester l’interopérabilité pendant que le standard mûrit ».

Ce qui arrive concrètement en 1.38

La préversion touche quatre points du plan de contrôle et du client. Le plus visible est le support de la signature des certificats de pods avec ML-DSA, qui s’ajoute aux algorithmes existants — la demande de certificat de pod (PodCertificateRequest) et le type de volume projeté sont tous deux mis à jour. En parallèle, l’API accepte désormais les demandes de signature PKCS#10 signées avec des clés ML-DSA dans les CertificateSigningRequest, derrière la feature-gate CertificateSigningRequestMLDSA.

Côté kubelet, la configuration KubeletConfiguration permet maintenant de choisir ECDSA, RSA ou ML-DSA pour les demandes de certificat client et serveur — le défaut reste ECDSA-P256, ce qui confirme que ML-DSA est une option opt-in, pas un basculement forcé. Enfin, client-go ajoute la prise en charge des clés ML-DSA via le paquet crypto/mldsa de Go 1.27, ce qui rend l’algorithme utilisable côté contrôleur et opérateur.

L’intérêt de cet ensemble n’est pas décoratif. Les certificats de pods sont l’un des rares mécanismes de Kubernetes où la clé privée est générée et consommée automatiquement par la plateforme : c’est donc un endroit idéal pour éprouver une migration post-quantique sans exiger que chaque application réécrive son code.

Les ruptures de compatibilité à anticiper

Une version alpha n’est pas une version de production, et ce changelog le rappelle par trois changements qui casseront des configurations existantes. D’abord, les plugins de scheduler hors arbre qui utilisent la méthode NominatedPodsForNode doivent désormais passer un klog.Logger en premier argument — un changement de signature qui obligera les mainteneurs d’extensions à adapter leur code avant la montée de version.

Ensuite, deux feature-gates sont retirés de manière définitive. PodSchedulingReadiness est supprimé car la fonctionnalité est activée en permanence, et SeparateTaintEvictionController disparaît du kube-controller-manager : toute configuration qui le mentionne encore dans --feature-gates doit le retirer, sous peine d’échec au démarrage. Enfin, la feature-gate DynamicResourceAllocation, verrouillée sur « activée » depuis la 1.35, est supprimée — l’allocation dynamique de ressources est désormais activée sans condition.

Le message pour les équipes qui exploitent un cluster en production est simple : 1.38 arrive avec un bagage de nettoyage, pas seulement de nouveautés. La migration doit être testée avec les vrais manifestes et les vrais plugins, pas en se fiant au seul fait que le cluster démarre.

Des dépendances mises à niveau, dont deux correctifs gRPC

La préversion embarque aussi des montées de dépendances qui touchent la sécurité. Kubernetes passe à Go 1.27.1 et met à jour google.golang.org/grpc vers v1.84.0, ce qui corrige deux vulnérabilités de la bibliothèque gRPC-Go : CVE-2026-84445, qui permettait à un serveur xds.NewGRPCServer() d’accepter une requête RPC malformée, et CVE-2026-84304, une faille de fragmentation des trames HTTP/2 pouvant conduire à une consommation de mémoire excessive. Pour les plateformes qui exposent des API gRPC en interne — c’est le cas de etcd et de nombreux plans de contrôle — ces correctifs se propagent de facto avec la version.

Ce que vous devez tester

La migration post-quantique ne se teste pas en production. Sur un cluster de test, activez la feature-gate et observez le comportement des CSR signés en ML-DSA :

# kube-apiserver : activer la signature des CSR avec des clés ML-DSA
--feature-gates=CertificateSigningRequestMLDSA=true

# Vérifier la version de l'apiserver déployée sur le cluster de test
kubectl version --short
# La sortie doit montrer v1.38.0-alpha.1 ou une préversion ultérieure

Le test pertinent n’est pas d’activer la feature-gate et de regarder si le cluster tourne : c’est de soumettre un CertificateSigningRequest réel signé avec une clé ML-DSA et de vérifier qu’il est approuvé, délivré, puis consommé par un pod sans casser la rotation des certificats. Cartographiez aussi les composants qui parlent gRPC à l’apiserver ou à etcd, et validez qu’ils acceptent les versions corrigées de la bibliothèque.

Harvest now, decrypt later : le vrai calendrier

Le terme technique qui rend cette migration urgente est le « harvest now, decrypt later ». Un adversaire doté de moyens suffisants peut aujourd’hui intercepter et archiver du trafic ou des artefacts signés en RSA ou ECDSA, puis les déchiffrer ou les falsifier une fois qu’un ordinateur quantique capable d’exécuter l’algorithme de Shor sera disponible. Pour des certificats à longue durée de vie — certificats racines d’entreprise, CA intermédiaires, certificats de nœuds de cluster qu’on renouvelle rarement — la donnée signée aujourd’hui reste exposée pendant des années.

C’est ce qui justifie de commencer les tests avant que la menace soit matériellement là. Le NIST fixe l’échéance de bascule des systèmes fédéraux américains vers la cryptographie post-quantique à 2030 pour les actifs les plus critiques, avec un objectif de migration complète en 2035. Le fait que Kubernetes introduise ML-DSA dès la 1.38, en 2026, montre que l’écosystème traite ce calendrier comme une contrainte de conception, pas comme un sujet de veille.

Le coût concret de ML-DSA mérite d’être chiffré : la variante ML-DSA-65 produit une clé publique d’environ 1 952 octets et une signature d’environ 3 309 octets, contre 32 et 64 octets pour une clé Ed25519. Cet écart se répercute sur la taille des CSR, des certificats et du trafic de rotation — un surcoût à mesurer sur les plans de contrôle denses, et une raison de plus de tester en environnement réel avant de généraliser.

Verdict

Si vous exploitez un cluster en production, ne faites rien de plus que préparer le terrain : 1.38 est en alpha, et la migration ML-DSA reste opt-in. Lisez les trois changements cassants — signature des plugins de scheduler, suppression de SeparateTaintEvictionController et de DynamicResourceAllocation — et planifiez leur correction dans vos extensions avant la sortie stable. Si vous pilotez une plateforme exposée à des cycles de vie longs (certificats à longue durée, appareils difficiles à mettre à jour), commencez dès maintenant les tests d’interopérabilité ML-DSA sur un cluster de test : le standard existe, et l’effort de migration se paie au moment où vous décidez de le faire, pas au moment où vous y êtes contraint. Et si vous maintenez un composant du plan de contrôle, mettez à niveau gRPC-Go vers v1.84.0 indépendamment de Kubernetes : les deux CVE corrigées ne dépendent pas de la montée de version du cluster.

Références

• Kubernetes Announce — Kubernetes v1.38.0-alpha.1 is live! (29 septembre 2026)
• GitHub — kubernetes/kubernetes CHANGELOG-1.38.md
• NVD — CVE-2026-84445, gRPC-Go xDS server malformed RPC
• NVD — CVE-2026-84304, gRPC-Go HTTP/2 frame fragmentation
• NIST — FIPS 204, Module-Lattice-Based Digital Signature Standard (août 2024)