AWS automatise la rotation du certificat racine d’EKS, avant l’expiration des clusters créés en 2018
Le 20 août 2026, Amazon EKS a annoncé la rotation automatisée de l’autorité de certification de chaque cluster, avec un cycle de vie géré et des garde-fous. Les clusters créés depuis 2018 arrivent au bout de la validité de dix ans de leur CA : la rotation est une responsabilité partagée, et la partie nœuds et clients externes reste à la charge de l’exploitant.
20 août 2026. Amazon EKS annonce la rotation de l’autorité de certification (CA) de chaque cluster, via un cycle de vie géré avec garde-fous automatisés. Depuis 2018. Chaque cluster EKS possède une CA propre qui chiffre les connexions vers l’API Kubernetes du cluster, avec une validité de dix ans. Désormais. Les clusters de l’époque arrivent au point où la rotation doit commencer.
Pour une équipe qui exploite EKS, c’est un rappel que les certificats expirent même quand on ne les voit pas — et qu’AWS vient de transformer une dette opérationnelle en fonctionnalité.
Un compte à rebours de dix ans
La mécanique est simple à comprendre, mais facile à oublier. Chaque cluster Amazon EKS a sa propre autorité de certification, qui permet d’établir des connexions chiffrées et authentifiées vers l’API server du cluster. AWS émet ces CA avec une validité de dix ans.
Les clusters créés depuis le lancement du service, en 2018, approchent donc de l’expiration de leur certificat racine. Ce n’est pas un bug : c’est une conséquence arithmétique de la durée de vie choisie à l’origine. Mais pour les équipes qui n’ont jamais eu à y penser, la première rotation d’une CA de cluster est un exercice délicat — la mauvaise manipulation peut casser la connexion de tous les composants au plan de contrôle.
AWS formalise donc le processus en le rendant géré. La rotation suit un cycle de vie : l’API et les composants gérés par AWS sont mis à jour pour faire confiance à la CA de remplacement, et l’exploitant n’a plus à orchestrer la bascule à la main.
Une responsabilité partagée, sans ambiguïté
Le point clé de l’annonce est la répartition des rôles. AWS gère le cycle de vie de la rotation et met à jour automatiquement les composants qu’il administre. Mais la rotation d’une CA de cluster est une responsabilité partagée : le client reste responsable de deux choses.
D’abord, remplacer ses nœuds de travail. Les instances EKS Auto Mode et les nœuds Fargate sont mis à jour automatiquement par AWS, mais les groupes de nœuds gérés par le client doivent être remplacés pour embarquer la nouvelle CA.
Ensuite, mettre à jour les clients externes. Tout ce qui se connecte à l’API server en dehors du cluster — outils de déploiement, pipelines CI/CD, kubectl des développeurs, opérateurs, contrôleurs — doit apprendre à faire confiance à la CA de remplacement avant son activation. Un client qui ne connaît pas la nouvelle racine se retrouve rejeté au moment de la bascule.
La formulation d’AWS est prudente : l’activation de la CA de remplacement doit précéder la mise à jour des clients, sinon l’accès se coupe.
Les garde-fous automatisés
C’est là que l’offre apporte sa valeur. Amazon EKS fournit des garde-fous automatisés tout au long du processus : des notifications anticipées avant l’expiration de la CA, l’ajout automatique d’une CA de remplacement si le client n’en crée pas une, et une activation automatique si le client ne l’active pas selon son propre calendrier.
La pièce la plus utile est la capacité de rollback. Si la bascule vers la CA de remplacement révèle un problème — un client oublié, un nœud non remplacé — l’exploitant peut revenir à la CA précédente pour résoudre l’incident avant de retenter. C’est le filet de sécurité qui manquait à toute rotation manuelle : la possibilité de faire marche arrière sans reconstruire le cluster.
La fonctionnalité est disponible sans coût supplémentaire dans toutes les régions commerciales AWS, via la CLI, les API EKS, CloudFormation et la console.
La rotation sur un cluster non géré
Pour mesurer ce qu’AWS apporte, il suffit de regarder comment la rotation se passe sur un Kubernetes auto-hébergé. Dans un cluster kubeadm, la CA du plan de contrôle vit dans des fichiers du répertoire /etc/kubernetes/pki. La faire tourner exige de générer une nouvelle CA, de signer de nouveaux certificats pour l’API server, les contrôleurs et les kubelets, puis de redémarrer les composants dans le bon ordre. Une erreur de séquence, et le cluster se retrouve incohérent — l’API server rejette des kubelets, les contrôleurs perdent la main, et le diagnostic part d’une grappe de certificats qui ne concordent plus.
cert-manager automatise la rotation des certificats TLS d’application, mais la CA racine du cluster reste un actif manuel dans la plupart des déploiements. Beaucoup d’équipes la découvrent le jour où elle expire, précisément parce que sa durée de vie de dix ans dépasse le mandat de quiconque l’a installée : le cluster d’origine survit souvent à son créateur.
C’est ce trou que l’annonce d’EKS comble pour le service géré. La différence tient moins à la technique qu’à la responsabilité : AWS endosse le suivi du calendrier, les notifications et l’activation, pendant que l’exploitant conserve ce qui lui revient — ses nœuds et ses clients externes.
Ce qui casse exactement pendant une rotation
Comprendre la rotation, c’est comprendre ce qui se passe quand elle échoue à moitié. Un kubectl qui ne fait pas confiance à la nouvelle CA voit ses appels rejetés avec une erreur TLS ; un nœud qui n’a pas été remplacé continue de présenter un certificat signé par l’ancienne racine ; un opérateur ou un webhook qui valide l’API server contre une CA épinglée échoue silencieusement.
La fenêtre critique est celle de la coexistence : l’ancienne et la nouvelle CA doivent être simultanément acceptées pendant que les clients basculent un à un. C’est exactement ce que le cycle de vie géré d’EKS orchestre — et ce qu’une rotation manuelle fait souvent mal, en activant la nouvelle racine avant que tous les clients ne la connaissent. La règle simple : la confiance précède la bascule, jamais l’inverse.
Qui est réellement concerné
L’annonce vise d’abord les équipes qui exploitent des clusters antérieurs aux réglages modernes d’EKS. Un cluster lancé en 2018 ou 2019 a une CA qui approche du terme de ses dix ans, et ses opérateurs ont probablement vu passer plusieurs générations d’ingénieurs depuis — l’auteur d’origine est souvent parti. Ce sont les clusters les plus exposés, et précisément ceux que le cycle de vie géré est conçu pour sauver : AWS notifie, ajoute une CA de remplacement et active si personne ne le fait.
Le second groupe est celui des clients externes câblés en dur sur le cluster : runners auto-hébergés, agents GitLab ou Jenkins, backends d’état Terraform, sondes de supervision. Aucun n’est visible par AWS, et aucun ne se mettra à jour tout seul. Le coût d’un oubli est une coupure sèche au moment de l’activation — exactement la défaillance que le rollback existe pour rattraper.
Verdict
Si vous exploitez des clusters EKS créés entre 2018 et 2020, vérifiez cette semaine la date de validité de votre CA — la fenêtre de dix ans arrive à échéance, et une expiration non traitée coupe l’accès à l’API server sans préavis. Le plus tôt vous planifiez la rotation, le plus vous pouvez la faire à votre rythme plutôt qu’en urgence.
Si vous utilisez EKS Auto Mode ou Fargate, la partie gérée par AWS se met à jour toute seule, mais vos clients externes — pipelines, kubectl, opérateurs — restent de votre responsabilité. Inventoriez-les avant d’activer la CA de remplacement, et gardez le rollback sous la main pour la bascule.
Si vous gérez d’autres autorités de certification — internes, Vault, cert-manager — la leçon se transpose : une CA de dix ans est un actif qu’on oublie précisément parce qu’il dure longtemps. Automatisez la rotation avant qu’elle ne devienne un incident.