Le 14 septembre 2026, Microsoft a coupé le fil d’une fonctionnalité que des milliers de clusters Azure Kubernetes Service utilisaient encore pour faire confiance à leurs propres autorités de certification internes. La propriété préversion enableCustomCATrust a pris sa retraite ce jour-là, huit jours seulement avant la publication de cet article. Les équipes qui n’avaient pas migré vers le mécanisme définitif risquent désormais des échecs lors du redimensionnement de leurs nœuds ou du renouvellement de leurs certificats. Ce changement technique, en apparence mineur, révèle en fait trois façons radicalement différentes dont Azure, AWS et Google Cloud gèrent la confiance cryptographique dans leurs clusters Kubernetes managés. Pour les entreprises françaises et européennes soumises à NIS2 et à DORA, la question dépasse largement le simple ticket de maintenance.
Ce qu’était enableCustomCATrust et pourquoi Azure l’a retiré
La fonctionnalité Custom CA Trust d’AKS permet à un cluster de faire confiance à une autorité de certification privée, celle d’une entreprise qui gère sa propre infrastructure à clés publiques, un registre de conteneurs interne signé par une CA maison, ou un proxy d’entreprise qui intercepte le trafic TLS sortant. Quand le paramètre enableCustomCATrust=true était activé au niveau d’un pool de nœuds, AKS ajoutait une étiquette au nœud et déployait un DaemonSet accompagné de services hôtes chargés de synchroniser les certificats fournis par le client dans les magasins de confiance de chaque nœud, selon la documentation officielle Microsoft Learn.
Le problème, c’est que cette implémentation appartenait à une version préversion de la fonctionnalité. Microsoft a publié une version disponible en production (GA) plus robuste, pilotée par le paramètre –custom-ca-trust-certificates, directement lors de la création ou de la mise à jour du cluster. Les notes de version publiées sur GitHub par l’équipe Azure/AKS précisent que le champ enableCustomCATrust a été retiré à partir de l’API 2025-09-02-preview, car il devient inutile une fois la fonctionnalité GA en place. La dernière API préversion à exposer encore ce champ était la 2025-08-02-preview.
La chronologie exacte de la bascule
Microsoft n’a pas improvisé cette transition. Le calendrier s’étale sur plus d’un an, entre la sortie de l’implémentation GA et le retrait définitif du champ préversion. Les administrateurs qui suivent le AKS Docs Tracker ou les issues GitHub du dépôt Azure/AKS avaient reçu plusieurs alertes avant l’échéance du 14 septembre.
| Date | Événement | Impact pour les équipes AKS |
|---|---|---|
| 2 septembre 2025 | L’API 2025-09-02-preview retire le champ enableCustomCATrust des schémas ARM | Les nouveaux déploiements via cette API ne peuvent plus s’appuyer sur l’ancien champ |
| Août 2025 | Dernière API préversion (2025-08-02-preview) à exposer encore enableCustomCATrust | Fenêtre de tolérance pour les scripts d’infrastructure existants |
| Juillet 2026 | AKS Newsletter et Microsoft Release Radar classent la dépréciation en priorité haute | Recommandation explicite de migrer avant l’échéance |
| 14 septembre 2026 | Retraite officielle de la propriété préversion | Risque d’échec au redimensionnement des nœuds et au renouvellement des certificats |
| 22 septembre 2026 | Huit jours après l’échéance | Premiers retours de terrain sur les clusters non migrés |
Ce qui casse concrètement sur un cluster non migré
Microsoft est explicite sur ce point dans ses notes de version : les pools de nœuds qui dépendent encore de enableCustomCATrust=true peuvent rencontrer des échecs pendant les opérations de mise à l’échelle et pendant le renouvellement des certificats. Concrètement, un cluster qui doit ajouter des nœuds pour absorber un pic de charge, un scénario classique pour un site e-commerce français pendant les soldes ou un service bancaire lors d’un pic transactionnel, peut voir ses nouveaux nœuds échouer à rejoindre le cluster si le mécanisme de synchronisation des CA personnalisées ne fonctionne plus.
La documentation chinoise d’Azure, plus détaillée sur ce point que sa version anglaise, précise un détail technique qui a surpris plusieurs administrateurs : la version actuelle du CLI Azure ne propose plus l’option –disable-custom-ca-trust qui figurait pourtant dans une documentation antérieure. Pour retirer proprement la propriété d’un pool de nœuds affecté, il faut passer par une mise à jour générique de la ressource plutôt que par un paramètre dédié. Cette absence d’outil de migration en un clic a ralenti certaines équipes, notamment celles qui gèrent leur infrastructure via Terraform ou Bicep sans veille active sur les notes de version AKS.
La solution GA et sa limite à dix certificats
Le remplacement officiel repose sur un mécanisme documenté et stable. On prépare un fichier texte contenant jusqu’à dix certificats encodés en base64, séparés par des lignes vides, puis on le transmet au cluster via la commande az aks create ou az aks update. Microsoft plafonne volontairement ce nombre à dix CA par cluster, une limite pensée pour couvrir la majorité des architectures d’entreprise (CA racine interne, CA intermédiaire par filiale, CA de test) sans ouvrir la porte à une prolifération de confiance impossible à auditer.
# Ancienne méthode (préversion, retirée le 14 septembre 2026)
az aks nodepool update \
--resource-group mon-groupe \
--cluster-name mon-cluster \
--name pool1 \
--enable-custom-ca-trust true
# Méthode GA recommandée depuis 2025
az aks update \
--resource-group mon-groupe \
--name mon-cluster \
--custom-ca-trust-certificates ./ca-entreprise.pem
# Vérification après migration
az aks show \
--resource-group mon-groupe \
--name mon-cluster \
--query "securityProfile.customCaTrustCertificates"Pour les équipes qui gèrent des dizaines de clusters à travers plusieurs régions Azure Europe, la migration reste un chantier d’inventaire avant d’être un chantier technique. Il faut d’abord identifier chaque pool de nœuds qui référence encore l’ancien champ, puis vérifier que les dix certificats maximum suffisent à couvrir la hiérarchie de CA de l’organisation.
Pourquoi les CA privées comptent autant en entreprise
Une autorité de certification privée n’est pas un caprice d’architecte. Les banques, les assureurs et les administrations françaises s’appuient massivement sur une PKI interne pour signer le trafic entre microservices, sécuriser l’accès à des registres de conteneurs internes et faire respecter le chiffrement de bout en bout entre un cluster Kubernetes et un mainframe historique. Sans confiance CA correctement propagée sur chaque nœud, un pod ne peut plus valider le certificat TLS d’un service interne et l’appel échoue silencieusement, souvent au pire moment, pendant une bascule de trafic.
C’est précisément ce terrain que la directive NIS2 vient réglementer. Le texte européen, transposé en France par une loi sur la résilience des infrastructures critiques, impose aux entités couvertes de documenter la gestion de leurs clés cryptographiques et de leurs procédures de continuité. Selon les estimations les plus récentes relayées par PwC France et par plusieurs cabinets de conformité, entre 15 000 et 18 000 entités françaises entrent dans le périmètre de NIS2, contre environ 500 sous l’ancienne directive NIS1. Une rupture de confiance CA mal gérée sur un cluster de production devient, dans ce cadre, un incident potentiellement reportable plutôt qu’un simple ticket d’astreinte.
AWS répond avec EKS Auto Mode et les certificateBundles
Le champ certificateBundles d’EKS Auto Mode
Amazon a suivi une trajectoire parallèle mais distincte. Le 16 octobre 2025, AWS a annoncé de nouvelles fonctionnalités de sécurité pour EKS Auto Mode, dont le support de bundles de CA personnalisées via le champ certificateBundles d’une NodeClass. L’objectif affiché est de permettre aux nœuds de faire confiance automatiquement à des CA d’entreprise, notamment pour tirer des images depuis un registre privé signé par un certificat auto-signé, sans passer par une AMI personnalisée ni un script de démarrage maison.
Le Private CA Connector, un besoin différent
Cette approche reste toutefois circonscrite à EKS Auto Mode. Pour les groupes de nœuds gérés classiquement ou pour Fargate, les équipes doivent encore s’appuyer sur un bootstrap AMI, une configuration de trust store au niveau OS, ou un DaemonSet maison, un peu comme le faisait l’ancien enableCustomCATrust d’Azure avant sa version GA. En parallèle, AWS a étendu son offre d’émission de certificats avec le Private CA Connector for Kubernetes, ajouté comme add-on EKS le 4 juin 2025 puis élargi à GovCloud et au connecteur Active Directory en septembre 2026. Ce connecteur s’intègre avec cert-manager pour émettre des certificats de charge de travail depuis AWS Private CA, ce qui couvre un besoin différent : signer des certificats plutôt que distribuer la confiance dans le trust store des nœuds.
Google Cloud choisit une architecture centrée sur le plan de contrôle
Certificate Authority Service, une PKI managée
GKE aborde le sujet sous un angle encore différent. La documentation Google décrit la possibilité de faire fonctionner ses propres autorités de certification et clés dans GKE via Certificate Authority Service (CAS), le service géré de Google Cloud pour l’émission et la gestion de CA. Le flux documenté consiste à créer les CA dans CAS, accorder les rôles IAM nécessaires à l’agent de service GKE, puis créer un cluster qui utilise ces CA et ces clés personnalisées.
Cette architecture cible avant tout la personnalisation de la PKI du plan de contrôle et du cluster, pas un remplacement généralisé du trust store du système d’exploitation sur chaque nœud. Pour la confiance envers un registre privé, Google documente une voie distincte : déposer le certificat public de la CA privée dans Secret Manager, puis configurer containerd sur les pools de nœuds pour l’utiliser. Trois clouds, trois philosophies. Azure vise le trust store du nœud directement, AWS segmente entre nœuds (certificateBundles) et charges de travail (Private CA Connector), Google privilégie la personnalisation du plan de contrôle couplée à une configuration explicite du runtime de conteneurs.
Comparaison technique : AKS, EKS et GKE face à la gestion des CA
| Critère | Azure AKS | AWS EKS | Google GKE |
|---|---|---|---|
| Mécanisme actuel | –custom-ca-trust-certificates (GA) | certificateBundles (EKS Auto Mode) | Certificate Authority Service (CAS) |
| Portée | Trust store de chaque nœud | Trust store des nœuds Auto Mode uniquement | PKI du plan de contrôle et du cluster |
| Limite documentée | 10 CA maximum par cluster | Non précisée publiquement | Dépend des quotas CAS du projet |
| Émission de certificats de charge de travail | Non couvert par cette fonctionnalité | AWS Private CA Connector + cert-manager (ajouté le 4 juin 2025) | CAS + cert-manager |
| Cas d’usage principal | PKI d’entreprise, proxys internes | Registres privés, images auto-signées | Personnalisation avancée de la PKI cluster |
| Historique récent | Migration forcée depuis une préversion retirée le 14 septembre 2026 | Fonctionnalité lancée le 16 octobre 2025 | Approche stable, documentée en continu en 2025-2026 |
L’angle marché : adoption, gaspillage et poids de la confiance PKI
Kubernetes n’a jamais été aussi central dans les infrastructures d’entreprise, ce qui rend chaque incident de confiance CA plus coûteux qu’il y a trois ans. L’enquête annuelle de la Cloud Native Computing Foundation, publiée le 20 janvier 2026, situe l’usage de Kubernetes en production à 82 % chez les organisations qui utilisent des conteneurs, contre 66 % en 2023. Parmi les organisations qui hébergent des modèles d’IA générative, 66 % s’appuient sur Kubernetes pour gérer tout ou partie de leurs charges d’inférence.
Le rapport Flexera 2026 State of the Cloud, quinzième édition publiée le 18 mars 2026, ajoute une couche financière à ce tableau. Il montre que 73 % des organisations exploitent désormais un environnement hybride et que 29 % des dépenses cloud IaaS et PaaS sont gaspillées, un chiffre qui inverse cinq années de baisse continue. Dans ce contexte de complexité croissante, une panne liée à un certificat mal migré n’est plus un simple bug de configuration. Elle s’ajoute à une facture cloud déjà jugée en partie incontrôlée par les directions financières.
| Indicateur | Valeur | Source |
|---|---|---|
| Usage de Kubernetes en production (organisations utilisant des conteneurs) | 82 % en 2025, contre 66 % en 2023 | CNCF Annual Cloud Native Survey, 20 janvier 2026 |
| Organisations IA générative utilisant Kubernetes pour l’inférence | 66 % | CNCF Annual Cloud Native Survey, 20 janvier 2026 |
| Organisations en environnement cloud hybride | 73 % | Flexera State of the Cloud, 18 mars 2026 |
| Dépenses cloud IaaS/PaaS jugées gaspillées | 29 % | Flexera State of the Cloud, 18 mars 2026 |
| Entités françaises dans le périmètre NIS2 | 15 000 à 18 000 | PwC France, 2 juillet 2025 |
| Entreprises estimant qu’une heure de panne coûte plus de 300 000 dollars | 93 % | ITIC Global Server Hardware and Server OS Reliability Survey, 2025 |
Le coût réel d’une rupture de confiance TLS non planifiée
L’enquête ITIC 2025 sur la fiabilité des serveurs d’entreprise donne une mesure concrète du risque financier. Sur les organisations interrogées, 93 % estiment qu’une heure de panne non planifiée coûte au moins 300 000 dollars, et 46 % placent ce coût au-delà d’un million de dollars par heure. Ces chiffres couvrent l’ensemble des pannes d’infrastructure, pas uniquement les incidents Kubernetes, mais ils donnent un ordre de grandeur pertinent pour évaluer le risque d’une migration de certificat mal anticipée sur un cluster de production.
Pour un cluster AKS qui échoue à redimensionner ses nœuds en pleine charge, la panne ne se limite pas à l’indisponibilité brute. Elle inclut le temps d’astreinte pour diagnostiquer que la cause vient d’un champ de configuration retiré, souvent une découverte tardive, le temps de bascule vers la méthode GA en urgence plutôt qu’en migration planifiée, et dans certains secteurs régulés, l’obligation de qualifier l’incident au regard de NIS2 ou de DORA pour les entités financières.
Contexte historique : d’un DaemonSet artisanal à une API stable
La trajectoire de enableCustomCATrust illustre un schéma classique dans l’histoire de Kubernetes managé. Une fonctionnalité utile arrive d’abord en préversion, sous forme d’un DaemonSet et de services hôtes bricolés pour répondre à une demande urgente de clients d’entreprise. Elle gagne en popularité, puis le fournisseur cloud la rebâtit sur une base plus stable, généralement une API native intégrée au plan de contrôle plutôt qu’un composant tiers déployé sur chaque nœud.
On retrouve la même logique dans l’évolution générale de la gestion des certificats sur le web ces dernières années, avec le raccourcissement progressif de la durée de vie maximale des certificats TLS publics, appelé à passer de 200 jours aujourd’hui à 47 jours d’ici 2029 selon le calendrier fixé par le CA/Browser Forum. Les fournisseurs cloud suivent une tendance similaire à l’intérieur de leurs clusters managés : automatiser la rotation, réduire la fenêtre d’exposition d’une CA compromise, et retirer progressivement les mécanismes manuels remplacés par des API déclaratives.
Ce que ça change pour les équipes DevOps et SRE en France
Pour une équipe plateforme qui gère de l’infrastructure as code, la leçon dépasse le cas particulier d’Azure. Chaque fournisseur cloud maintient son propre calendrier de dépréciation de fonctionnalités préversion, souvent documenté uniquement dans des notes de version GitHub ou des newsletters spécialisées, rarement remonté automatiquement dans les tableaux de bord de conformité internes.
- Auditer tous les pools de nœuds AKS pour repérer une dépendance résiduelle à enableCustomCATrust avant toute opération de scaling planifiée
- Basculer vers –custom-ca-trust-certificates en testant d’abord sur un cluster de non-production, avec vérification via az aks show
- Vérifier que la hiérarchie de CA de l’organisation tient dans la limite de dix certificats imposée par Azure
- Documenter la procédure de gestion des CA pour chaque cluster managé dans le registre de risques exigé par NIS2 ou DORA
- Mettre en place une veille automatisée sur les notes de version AKS, EKS et GKE plutôt qu’une lecture manuelle occasionnelle
Cinq prédictions pour la gestion des CA dans le Kubernetes managé
Sur la base des trajectoires déjà engagées par les trois fournisseurs, plusieurs évolutions semblent probables pour 2027.
- Azure devrait continuer à réduire l’écart entre la préversion et la version GA de ses fonctionnalités de sécurité, ce cycle de dépréciation rapide devenant la norme plutôt que l’exception.
- AWS étendra probablement certificateBundles au-delà d’EKS Auto Mode vers les groupes de nœuds gérés classiques, pour unifier la gestion de la confiance CA sur l’ensemble du service.
- Google Cloud renforcera vraisemblablement l’intégration entre Certificate Authority Service et les pools de nœuds GKE, pour rapprocher son modèle de la granularité offerte par ses concurrents.
- La pression réglementaire européenne, portée par NIS2 et DORA, poussera davantage d’entreprises françaises à exiger une documentation formelle de la chaîne de confiance CA de leurs clusters, y compris pour les migrations internes des fournisseurs cloud.
- Les outils d’inventaire de certificats spécialisés pour Kubernetes gagneront du terrain face à la simple veille manuelle des notes de version, à mesure que le nombre de clusters gérés par équipe augmente.
Le prochain rendez-vous de dépréciation à surveiller
La retraite d’enableCustomCATrust ne sera pas un cas isolé. Les trois principaux fournisseurs cloud publient régulièrement des calendriers de dépréciation pour leurs services Kubernetes managés, souvent liés au rythme de sortie des nouvelles versions de l’API Kubernetes elle-même. Les équipes qui traitent ces annonces comme un flux d’actualité technique plutôt que comme un point de conformité s’exposent à répéter, dans six ou douze mois, exactement le même scénario : une fonctionnalité préversion qui disparaît sans que personne dans l’équipe n’ait suivi l’échéance.
Le point à retenir pour les entreprises européennes : la gestion des autorités de certification dans Kubernetes managé n’est plus une case technique isolée dans un ticket d’infrastructure. Elle croise directement les obligations de continuité imposées par NIS2, les exigences de traçabilité de DORA pour le secteur financier, et le coût très concret d’une heure de panne évalué par ITIC à plus de 300 000 dollars pour neuf entreprises sur dix.
Questions fréquentes
Que se passe-t-il si mon cluster AKS utilise encore enableCustomCATrust après le 14 septembre 2026 ?
Le champ ne provoque pas de panne immédiate en lui-même, mais Microsoft avertit que les opérations de mise à l’échelle des nœuds et de renouvellement des certificats peuvent échouer sur les pools qui en dépendent encore. La migration vers –custom-ca-trust-certificates reste recommandée sans délai.
Combien de certificats personnalisés puis-je ajouter à un cluster AKS ?
Dix certificats maximum, encodés en base64 ou séparés par des lignes vides dans un fichier texte, selon la documentation Microsoft Learn.
AWS EKS propose-t-il un équivalent exact de la fonctionnalité AKS ?
Pas exactement. Le champ certificateBundles d’EKS Auto Mode, lancé le 16 octobre 2025, couvre la confiance des nœuds envers des CA personnalisées, mais uniquement pour les clusters en mode Auto Mode. Les groupes de nœuds gérés classiquement nécessitent encore une configuration manuelle.
Google GKE permet-il aussi de faire confiance à une CA privée sur chaque nœud ?
GKE documente surtout l’usage de Certificate Authority Service pour personnaliser la PKI du plan de contrôle et du cluster. Pour un registre privé, Google recommande de passer par Secret Manager et une configuration containerd sur les pools de nœuds, une approche différente d’un trust store injecté automatiquement.
Cette dépréciation concerne-t-elle les entreprises soumises à NIS2 en France ?
Oui, indirectement. NIS2 couvre entre 15 000 et 18 000 entités françaises selon les estimations de PwC France, et exige une documentation des procédures de gestion cryptographique et de continuité. Une panne de confiance CA sur un cluster de production entre dans le périmètre des incidents à documenter, voire à signaler selon leur gravité.
Comment vérifier si mon cluster AKS dépend encore de l’ancien mécanisme ?
La commande az aks show avec une requête sur le profil de sécurité du cluster permet de vérifier l’état actuel des certificats CA personnalisés configurés. Un audit systématique de tous les pools de nœuds reste la méthode la plus fiable avant toute opération de scaling.
Existe-t-il un outil pour automatiser cette migration sur plusieurs clusters ?
Microsoft ne publie pas d’outil de migration en un clic pour ce cas précis. La documentation recommande une mise à jour générique de la ressource pour chaque pool de nœuds concerné, ce qui pousse la plupart des équipes à scripter leur propre inventaire et leur propre migration via Terraform, Bicep ou l’Azure CLI.
Cette retraite de fonctionnalité est-elle liée à une faille de sécurité ?
Non. Il s’agit d’une dépréciation planifiée liée au passage d’une implémentation préversion vers une fonctionnalité GA plus robuste, pas d’une réponse à une vulnérabilité découverte sur enableCustomCATrust.
