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.
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.