aekkorn - stock.adobe.com
Chiffrement post-quantique dans OpenShift : les entreprises n’en auront pas besoin avant 2035
Malgré l’intégration du chiffrement post-quantique dans RHEL 10 et OpenShift 4.20, Red Hat signale que les entreprises des secteurs critiques peuvent s’en passer dans l’immédiat. En attendant, la filiale d’IBM renforce la sécurité et les options de haute disponibilité de sa plateforme basée sur Kubernetes.
A l’occasion de l’édition nord-américaine de la KubeCon 2025, Red Hat a annoncé la disponibilité générale d’OpenShift 4.20. Une mise à jour placée sous le signe de la cybersécurité et de la résilience.
La filiale d’IBM commence par la prise en charge du chiffrement post-quantique. Pour mémoire, cette approche consiste à se protéger contre la menace hypothétique de superordinateurs, potentiellement quantiques, capables de casser les clés de chiffrement issues d’algorithmes comme RSA et ECC.
Le NIST (National Institute of Standards and Technology) a développé trois standards d’implémentation de techniques de chiffrement post-quantique : les FIPS 203, 204 et 205. En juin dernier, Red Hat avait déjà ajouté la prise en charge des algorithmes d’encapsulation et de désencapsulation de clés ML-KEM et RSASVE dans RHEL 10. C’est au tour d’OpenShift d’y passer. Plus spécifiquement, l’éditeur applique la technique au mTLS, un type d’authentification mutuelle associée au protocole de sécurisation des échanges de paquets TLS.
Chiffrement post-quantique dans Kubernetes : Red Hat prend les devants, même s’il a le temps
Il s’agit plus particulièrement de renforcer la protection des communications entre l’API Server, Kubelet, le planificateur et le contrôleur du cœur Kubernetes sous-jacent.
Ici, Red Hat s’appuie sur une librairie de la version 1.24 de Go, le langage dans lequel Kubernetes est écrit.
« La version 1.24 de Go a marqué une étape importante en introduisant la prise en charge du mécanisme d’échange de clés hybrides X25519MLKEM768 », écrit dans un billet de blog Jean-Philippe Jung, responsable produit sécurité d’OpenShift et d’OpenStack chez Red Hat.
Le système utilisé combine « le mécanisme classique X25519 (courbe elliptique Diffie-Hellman) et ML-KEM-768 (algorithme post-quantique). Le secret partagé final est dérivé des deux mécanismes combinés », ajoute-t-il.
Cette approche permettrait de bénéficier des avantages des deux technologies de chiffrement. Cette combinaison est surtout nécessaire puisque l’implémentation des algorithmes n’est pas standardisée dans la plupart des systèmes. Les fournisseurs cloud et les grands éditeurs proposent des déploiements parfois radicalement différents. En la matière, Red Hat tente d’aller un peu plus vite que le projet Kubernetes, sans pour autant trop s’en éloigner.
Il faut dire que la galerie de composants de l’orchestrateur n’évolue pas au même rythme.
Par exemple, etcd, la base de données clé-valeur qui stocke les informations sur le fonctionnement des clusters, utilise encore Go 1.23. Les contributeurs de Kubernetes estiment que la « source de vérité » des clusters K8s doit maintenir une forme de stabilité, d’intégrité des données et de bonnes performances, dixit Jean Philippe Jung.
Et c’est aux primoadoptants de faire attention à ces possibles incompatibilités entre les composants d’un même cluster Kubernetes.
« Par exemple, si un client kubectl construit avec une version de Go prenant en compte ML-KEM communique avec un serveur API plus ancien, la négociation TLS peut passer silencieusement à un algorithme de chiffrement classique », illustre Jean-Philippe Jung. « Cela entraînerait la perte de la protection post-quantique, sans avertissement explicite. Il est donc essentiel de confirmer que tous les composants de votre environnement OpenShift utilisent des versions compatibles qui prennent en charge PQC ».
Si le chiffrement post-quantique dans Kubernetes et OpenShift est balbutiant (et sûrement un peu marketing), il n’en reste pas moins qu’une forme de préparation est nécessaire, notent les porte-parole de la filiale d’IBM. Les acteurs malveillants et certains États sont soupçonnés de stocker des données en attente d’avoir la puissance de calcul pour les déchiffrer.
De son côté, Red Hat estime que les entreprises issues de secteurs critiques n’ont pas besoin du chiffrement post-quantique avant 2035. La date n’est pas choisie au hasard. Et elle n’a pas grand-chose à voir avec le développement d’ordinateur quantique enfin complet. Le NIST a pour projet de déprécier les algorithmes RSA-2048 et ECC-256 bits en 2030, puis de les désactiver en 2035.
Les acteurs du marché IT ont encore dix ans pour se mettre d’accord.
La gestion externalisée des secrets enfin disponible
En attendant, la sortie d’OpenShift 4.20 est l’occasion pour Red Hat d’annoncer la disponibilité générale d’un moyen d’apporter son propre fournisseur d’identité OIDC. Les administrateurs accèdent également à un framework de gestion de sécurité sans confiance basé sur le projet SPIFFE (Secure Production Identity Framework for Everyone).
Pour les plus motivés, Red Hat se propose de se mettre à Istio à travers Red Hat OpenShift Service Mesh 3.2. L’implémentation de la technologie de maillage de (micro) services prend désormais en charge le mode Ambient. Cette approche sans side-car permettrait de réduire la gestion du chiffrement des flux mTLS entre pods, de simplifier l’observabilité et l’application des règles de sécurité réseau. Le tout à un coût plus faible qu’à l’accoutumée.
De plus, il est dorénavant possible de s’appuyer sur des services de gestion de secrets externes via un opérateur. Les secrets peuvent être stockés dans AWS Secret Manager et Systems Manager Parameter Store, HashiCorp Vault, Google Secret Manager, Azure Key Vault, ou encore IBM Key Secrets Manager. L’opérateur gère l’application external-secrets. Il appelle les clés pour les provisionner et les rafraîchir à l’échelle d’un cluster.
Une haute à disponibilité à deux nœuds (ou presque)
Red Hat n’oublie pas ses clients on premise. Il vante un nouveau mode de déploiement d’OpenShift basé sur seulement deux nœuds. Pour cela, il s’appuie sur le projet Arbiter, outil de planification et de mise à l’échelle pour Kubernetes. Il s’agit là de réduire les coûts d’infrastructure tout en maintenant une forme de haute disponibilité. En réalité, ce « form factor » dépend de trois nœuds : deux nœuds disposant du control plane OpenShift Container Plaftform et un nœud Arbiter. Il est toutefois léger. « Le nœud Arbiter stocke l’intégralité des données etcd, ce qui permet de maintenir un quorum etcd et d’éviter le “split brain” », précise la documentation de la filiale d’IBM.
Dans le cas de Kubernetes, un scénario « split brain » (séparation du cerveau, en français) se produit quand une panne réseau ou autre provoque la séparation et l’isolation des nœuds d’un cluster etcd. La « source de vérité » est alors divisée en deux parties ou plus. Ici, le nœud Arbiter contient l’ensemble des données etcd en provenance des deux autres nœuds.
« Le nœud Arbiter n’exécute pas les composants supplémentaires du plan de contrôle kube-apiserver et kube-controller-manager, ni les charges de travail ». Il n’aurait besoin que de 2vCPU et de 8 Go de mémoire vive pour fonctionner.
Enfin, l’opérateur réseau des clusters OpenShift prend en charge « nativement » le routage BGP (Border Gateway Protocol) à travers le plug-in OVN-Kubernetes. Cela permettrait de faciliter les échanges entre la plateforme de conteneurisation et les autres réseaux dans les data centers on premise des entreprises. « Cela signifie une adaptation plus rapide aux changements de réseau, à la migration des machines virtuelles ou aux événements de basculement (fail-over) », assure Red Hat dans un communiqué. Pour l’instant, ce routage est seulement disponible pour les machines bare-metal, mais une prise en charge des fournisseurs cloud est également sur la feuille de route.
À noter qu’OpenShift 4.20 bénéficie d’un support étendu à l’ensemble des services d’infrastructure d’Oracle, dont Alloy et EU Sovereign Cloud.
