Aidez à améliorer cette page

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Pour contribuer à ce guide de l'utilisateur, cliquez sur le GitHub lien Modifier cette page qui se trouve dans le volet droit de chaque page.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Faites pivoter l'autorité de certification (CA) du cluster EKS

Dans l'infrastructure à clé publique (PKI), une autorité de certification (CA) est une entité de confiance qui émet et signe des certificats numériques. Ces certificats établissent l'identité et permettent une communication cryptée entre les systèmes à l'aide du protocole TLS (Transport Layer Security). Lorsqu'un client se connecte à un serveur, celui-ci présente un certificat signé par une autorité de certification. Le client vérifie le certificat du serveur par rapport aux autorités de certification auxquelles il fait confiance avant d'autoriser la connexion.

Dans Amazon Elastic Kubernetes Service (Amazon EKS), une autorité de certification est créée pour chaque cluster EKS au moment de la création du cluster. Cela suit le même modèle que Kubernetes en amont : chaque cluster EKS possède sa propre autorité de certification qui signe les certificats pour le serveur API. C'est ce qui permet aux composants du plan de contrôle, aux nœuds de travail et aux clients de s'authentifier auprès du serveur API et d'établir des connexions cryptées avec le cluster EKS.

Ces autorités de certification (CA) ont une période de validité définie. La rotation de l'autorité de certification est le processus qui consiste à remplacer l'autorité de certification de votre cluster EKS avant son expiration, afin de garantir que votre cluster reste opérationnel et accessible. Nous avons intégré des dispositifs de protection qui gèrent automatiquement ce processus. Si vous n'initiez pas vous-même la rotation de l'autorité de certification, nous ajouterons automatiquement une autorité de certification de remplacement et l'activerons avant l'expiration de l'autorité de certification sortante, afin de garantir la disponibilité de votre cluster.

Pendant la rotation de l'autorité de certification, une autorité de certification successeure est ajoutée à votre cluster EKS. EKS distribue automatiquement le CA successeur à tous les composants AWS gérés (plan de contrôle, instances en mode automatique EKS et nœuds AWS Fargate). Vous êtes responsable de la mise à jour des nœuds de travail que vous gérez (mode automatique non-EKS, non-Fargate) et des clients externes (tels que les fichiers kubeconfig et les CI/CD pipelines) afin qu'ils fassent confiance à l'autorité de certification qui succédera avant son activation. Une fois l'autorité de certification suivante activée, le cluster EKS passe à la signature de certificats avec l'autorité de certification suivante. Le CA sortant est ensuite retiré.

La rotation des CA est requise pour chaque cluster EKS car les CA ont une période de validité limitée. La période de validité dépend de la date de création de l'autorité de certification du cluster. Pour plus de détails, consultez la section des questions fréquemment posées. Les protections EKS garantissent que votre cluster lui-même reste disponible tout au long du cycle de vie de la rotation, mais une rotation réussie dépend également de la mise à jour des nœuds de travail que vous gérez et des clients externes afin qu'ils conservent la connectivité après l'activation de l'autorité de certification suivante.

Les API, l'expérience de la console, les notifications et les instructions détaillées des sections suivantes sont conçues pour vous aider tout au long de ce processus. L'ensemble des responsabilités est couvert dans la section sur le modèle de responsabilité partagée.

Comment fonctionne la rotation CA

La rotation des CA dans Amazon EKS est un processus en plusieurs étapes. Nous avons mis en place des mesures de protection automatiques pour préserver la disponibilité des clusters EKS tout au long du cycle de rotation, que vous agissiez ou non. Une rotation réussie, dans laquelle tous vos composants conservent leur connectivité, nécessite les étapes décrites dans les sections suivantes.

Étape 1 : ajouter une autorité de certification de remplacement

Une autorité de certification successeur est ajoutée au cluster EKS. À partir de ce moment, le cluster EKS fait confiance à la fois à l'autorité de certification sortante et à l'autorité de certification suivante. Les certificats continuent d'être émis par l'autorité de certification sortante. Aucune interruption ne se produit.

Vous pouvez ajouter vous-même une autorité de certification successeur à tout moment à l'aide de la AWS CLI, de l'API EKS, de la console ou de l'infrastructure en tant que code (IaC) AWS CloudFormation, par exemple, tant que votre cluster est actif. Si vous ne le faites pas, nous en ajouterons automatiquement un en votre nom.

L'autorité de certification suivante ne peut pas être activée tant que la distribution aux composants AWS gérés dans EKS (étape 2) n'est pas AWS terminée. C'est le bon moment pour commencer à identifier les nœuds de travail et les clients externes qui doivent être mis à jour. L'identification de tous les systèmes qui se connectent au serveur d'API de votre cluster EKS peut prendre du temps, en particulier dans les environnements comportant plusieurs équipes, CI/CD pipelines et outils de surveillance. Le fait de démarrer ce processus le plus tôt possible vous donne la plus grande flexibilité pour coordonner les mises à jour selon votre propre calendrier.

Étape 2 : Distribution de l'autorité de certification suivante

Une fois l'autorité de certification suivante ajoutée, AWS met à jour les composants gérés de votre cluster EKS (le plan de contrôle, les instances en mode automatique EKS et les nœuds AWS Fargate) afin de reconnaître et de faire confiance aux deux autorités de certification. Vous pouvez suivre l'évolution de cette situation grâce à l'état de distribution de la CA. L'autorité de certification suivante ne peut pas être activée tant que la distribution n'est pas terminée.

Une fois que nous avons terminé la distribution de CA aux composants gérés, vous êtes responsable de la mise à jour de deux groupes : les nœuds de travail que vous gérez (mode automatique non-EKS, non-Fargate) et les clients externes pour qu'ils fassent confiance à l'autorité de certification successeur. Cela garantit qu'ils continueront à se connecter au serveur API après l'activation de l'autorité de certification suivante. Si aucun composant n'est mis à jour avant l'activation de l'autorité de certification suivante, la restauration de l'autorité de certification est disponible pour rétablir la connectivité pendant que vous effectuez les mises à jour restantes.

Étape 3 : activer l'autorité de certification suivante

Une fois que nous avons terminé la distribution de l'autorité de certification du successeur à tous les composants AWS gérés dans EKS, l'autorité de certification du successeur peut être activée. Nous vous recommandons d'activer la nouvelle autorité de certification selon votre propre calendrier. Donnez-vous suffisamment de temps pour découvrir et mettre à jour les nœuds de travail que vous gérez et les clients externes afin qu'ils fassent confiance à l'autorité de certification qui vous succédera. Après l'activation de l'autorité de certification remplaçante, le cluster EKS émet des certificats signés par l'autorité de certification suivante. L'autorité de certification sortante reste fiable mais n'est plus utilisée pour la signature. Une fenêtre de restauration est disponible pendant une période limitée après l'activation, vous permettant de revenir à l'autorité de certification sortante si nécessaire. La restauration est traitée en détail dans une section ultérieure.

Vous pouvez activer vous-même l'autorité de certification suivante lorsque vous êtes certain que les nœuds de travail que vous gérez et les clients ont été mis à jour. Si vous ne le faites pas, nous activerons automatiquement l'autorité de certification suivante à l'approche de la date limite d'expiration.

La période de double confiance

Le délai entre l'ajout d'une autorité de certification remplaçante (étape 1) et le retrait de l'autorité de certification sortante est appelé période de double confiance. Pendant ce temps, le cluster EKS fait confiance aux deux autorités de certification simultanément. C'est ce qui rend la rotation non perturbatrice : les composants peuvent être mis à jour de manière incrémentielle car le cluster EKS accepte les certificats signés par l'une ou l'autre des autorités de certification.

La période de double confiance vous donne le temps d'identifier et de mettre à jour tous les nœuds de travail que vous gérez et les clients externes sans avoir à coordonner toutes les modifications simultanément.

Il est important de comprendre comment l'activation de l'autorité de certification suivante affecte la connectivité. Lorsqu'un client se connecte au serveur API, il vérifie l'identité du serveur en vérifiant que le certificat du serveur a été signé par une autorité de certification de confiance.

Une fois l'autorité de certification suivante activée, le serveur d'API présente son certificat signé par l'autorité de certification suivante. Les clients qui ont mis à jour leur offre de confiance pour inclure l'autorité de certification qui lui succédera procéderont à la vérification et se connecteront normalement. Les clients qui n'ont pas mis à jour leur Trust Bundle ne reconnaîtront pas le certificat du serveur et ne pourront pas établir de connexion.

Le schéma suivant montre le flux de connexion TLS après l'activation de l'autorité de certification suivante.

C'est pourquoi il est important de mettre à jour les nœuds de travail et les clients externes avant l'activation de l'autorité de certification suivante : ils ont besoin de l'autorité de certification remplaçante dans leur bundle de confiance pour vérifier l'identité du serveur d'API et se connecter. La période de double confiance et l'annulation du CA vous donnent le temps et le filet de sécurité nécessaires pour y parvenir.

Modèle de responsabilité partagée

La rotation des CA dans Amazon EKS suit le même modèle de responsabilité partagée qui s'applique de manière générale à tous AWS. AWS est responsable de la sécurité et de la disponibilité de l'infrastructure cloud, et vous êtes responsable de la sécurité et de la configuration de vos charges de travail au sein de celle-ci. Pour plus d'informations sur la manière dont la responsabilité partagée s'applique à Amazon EKS, consultez les meilleures pratiques de sécurité d'EKS.

Dans le contexte de la rotation des CA, cela signifie :

AWS est responsable de

Vous êtes responsable de

Nous ne pouvons pas effectuer ces actions en votre nom. Les clients externes existent en dehors des limites AWS opérationnelles. Les nœuds de travail qui ne sont pas gérés par EKS Auto Mode ou Fargate ont leur configuration CA Trust définie au moment du lancement ou via des processus d'amorçage que vous êtes le seul à contrôler. Cela est cohérent avec le fonctionnement de la confiance TLS : le client possède son propre magasin de confiance, et seul son administrateur peut le mettre à jour.

Les sections qui suivent sont détaillées de chaque côté : ce AWS qui vous convient et ce que vous devez faire, ainsi que des instructions étape par étape sur la façon de procéder.

Quoi AWS fait pour toi

AWS gère les éléments suivants tout au long du cycle de vie de rotation CA pour votre cluster EKS :

Création automatique d'une autorité de certification

Si vous n'ajoutez pas d'autorité de certification de remplacement sur votre propre calendrier, nous en ajouterons automatiquement une lorsque l'autorité de certification sortante de votre cluster EKS approche de son expiration. Cela garantit que le processus de rotation commence avec suffisamment de temps pour que vous puissiez découvrir et informer vos clients avant la date limite d'expiration.

mises à jour du plan de contrôle

Nous mettons automatiquement à jour le plan de contrôle du cluster EKS pour qu'il fasse confiance à l'autorité de certification qui lui succédera. Après l'activation de l'autorité de certification remplaçante, le plan de contrôle émet des certificats signés par l'autorité de certification suivante. Aucune action de votre part n'est requise pour le plan de contrôle.

Mises à jour du mode EKS Auto et de Fargate

Nous mettons automatiquement à jour les nœuds EKS Auto Mode et les pods Fargate pour faire confiance à la nouvelle autorité de certification. Ces composants sont entièrement gérés par nos soins et ne nécessitent aucune action de votre part pendant la rotation du CA.

Mises à jour des fonctionnalités d'

Nous mettons automatiquement à jour les fonctionnalités EKS (AWS contrôleurs pour Kubernetes (ACK), Argo CD et kro (Kube Resource Orchestrator)) pour faire confiance à l'autorité de certification qui nous succédera. Ces ressources gérées communiquent avec le serveur d'API de votre cluster et sont mises à jour dans le cadre du processus de distribution de CA. Aucune action de votre part n'est requise pour les ressources gérées dans EKS Capabilities. Pour plus d'informations, consultez la section Capacités EKS.

Suivi de l'état de distribution

Au fur et à mesure que nous mettons à jour les composants gérés de votre cluster EKS, vous pouvez suivre la progression de l'état de distribution de l'autorité de certification. Cela vous indique si nous avons terminé notre partie de la rotation. L'autorité de certification suivante ne peut pas être activée tant que la distribution n'est pas terminée.

Built-in mesures de sauvegarde

Nous avons intégré des dispositifs de protection pour protéger votre cluster EKS pendant la rotation :

Ces mesures de protection garantissent que la disponibilité du cluster EKS est préservée tout au long du cycle de vie de rotation, que vous agissiez ou non.

Notifications

Nous vous informons à chaque étape du cycle de vie des rotations CA. Les notifications sont envoyées via AWS Health, Cluster Insights et par e-mail. Chaque notification vous indique ce qui s'est passé, quelle action (le cas échéant) est requise de votre part et où se situe votre cluster EKS dans le calendrier de rotation.

Vous pouvez également configurer vos propres notifications à l'aide d'Amazon EventBridge pour intégrer les événements de rotation de CA à vos flux de travail de surveillance et d'alerte existants.

Ce que vous devez faire (et pourquoi)

Pour réussir la rotation des CA, vous devez mettre à jour les composants qui AWS ne peuvent pas être atteints en votre nom. Ils se répartissent en deux catégories :

Clientèle externe

Tout système qui se connecte au serveur d'API de votre cluster EKS depuis l'extérieur du cluster. Cela inclut les postes de travail des développeurs, les CI/CD pipelines (Jenkins, GitHub Actions GitLab, ArgoCD), les outils de surveillance et d'observabilité, les scripts d'automatisation et toute application utilisant un kubeconfig pour communiquer avec le serveur API.

Ces systèmes conservent chacun leur propre configuration de confiance. Lorsque l'autorité de certification suivante est activée, le serveur d'API présente les certificats signés par l'autorité de certification suivante. La mise à jour de ces clients pour qu'ils fassent confiance à l'autorité de certification remplaçante avant l'activation de l'autorité de certification suivante garantit le maintien de la connectivité. Si un client est oublié, CA Rollback peut rétablir l'accès pendant que vous terminez la mise à jour.

Nœuds de travail (mode automatique non EKS, non Fargate)

Les nœuds de travail qui ne sont pas gérés par EKS Auto Mode ou Fargate ont leur configuration CA Trust définie au moment du lancement ou via le processus d'amorçage de kubelet. Ces nœuds doivent être actualisés pour faire confiance à l'autorité de certification qui leur succédera. L'action requise dépend du type de nœud de travail :

Groupes de nœuds gérés

Effectuez une mise à jour de la version d'un groupe de nœuds, ce qui déclenche un remplacement progressif des nœuds. Les nouveaux nœuds démarrent automatiquement avec la configuration CA Trust mise à jour.

Karpenter-controlled nœuds

Si la détection de dérive est activée, Karpenter fera défiler les nœuds dans la fenêtre de dérive configurée et les nouveaux nœuds choisiront la CA qui lui succédera sans action manuelle. Si la détection de dérive est désactivée ou définie sur une longue fenêtre, traitez ces nœuds de la même manière que des nœuds autogérés.

Self-managed nœuds

Remplacez les nœuds pour qu'ils démarrent avec la configuration CA Trust mise à jour. Cela implique généralement la mise à jour du modèle de lancement avec les données CA mises à jour et le déclenchement d'un remplacement progressif via votre groupe Auto Scaling.

Nœuds hybrides

Mettez à jour la configuration de confiance sur chaque nœud hybride pour inclure l'autorité de certification suivante. Le processus spécifique dépend de la manière dont vos nœuds hybrides ont été démarrés et de la manière dont leur configuration de confiance est gérée.

Vous pouvez identifier les types de nœuds de travail qui s'exécutent dans votre cluster EKS à l'aide de Cluster Insights. Des instructions détaillées étape par étape pour la mise à jour de chaque type sont fournies dans une section ultérieure.

Nous proposons CA Rollback comme filet de sécurité si des nœuds de travail sont manqués. Cependant, la mise à jour de tous les nœuds de travail avant l'activation de l'autorité de certification suivante permet d'éviter totalement les interruptions de connectivité. Les nœuds qui n'ont pas été mis à jour avant l'activation de l'autorité de certification suivante perdront leur connectivité au serveur d'API du cluster EKS jusqu'à ce qu'ils soient remplacés ou qu'une restauration de l'autorité de certification soit effectuée.

Pourquoi tu es la seule à pouvoir le faire

Les clients externes existent en dehors des limites AWS opérationnelles. Un CI/CD pipeline s'exécutant sur votre réseau d'entreprise, l'ordinateur portable d'un développeur, un outil de surveillance hébergé sur site : AWS aucun mécanisme ne permet d'accéder à ces systèmes et de mettre à jour leur configuration de confiance.

Non-EKS La configuration de confiance des nœuds de travail en mode automatique est contrôlée par le biais de modèles de lancement, de scripts de données utilisateur ou de processus d'amorçage dont vous êtes propriétaire. Leur mise à jour nécessite le remplacement des nœuds ou la modification de leur configuration, deux actions au sein de votre infrastructure.

Il s'agit d'une contrainte du modèle de confiance TLS utilisé par Kubernetes aujourd'hui. Il n'existe aucun mécanisme au niveau du protocole permettant au serveur d'API de demander si un client a mis à jour son bundle de confiance. Le serveur ne peut présenter son certificat que lorsqu'un client se connecte. Si le client fait confiance à l'autorité de certification qui l'a signé, la connexion aboutit. Si ce n'est pas le cas, il échoue. Il n'existe aucun chemin de vérification préalable à l'activation qui permettrait AWS de confirmer l'état de préparation de vos composants en votre nom.

Quand commencer

Commencez à identifier vos clients externes le plus tôt possible. Il s'agit de l'étape la plus chronophage de la rotation des autorités de certification, en particulier dans les environnements où plusieurs équipes déploient indépendamment des charges de travail sur le cluster EKS. Plus vous commencez à découvrir les clients tôt, plus vous avez de temps pour coordonner les mises à jour entre les équipes sans pression.

Des instructions détaillées sur la façon de mettre à jour chaque type de nœud client et de serveur sont fournies dans les sections qui suivent.

Conditions préalables

Avant de démarrer la rotation CA, vérifiez les points suivants :

Aucune autorisation IAM supplémentaire n'est requise au-delà de celles nécessaires pour gérer votre cluster EKS. Si vous pouvez appeler les API EKS pour votre cluster EKS aujourd'hui, vous pouvez effectuer une rotation CA.

Prise en main

Vous pouvez effectuer une rotation CA à l'aide de l' AWS interface de ligne de commande ou de la console Amazon EKS. Assurez-vous que vous utilisez la version 2.x ou ultérieure de la AWS CLI (aws --versionpour vérifier).

Utilisation de AWS INTERFACE DE LIGNE DE COMMANDE (CLI)

La procédure pas à pas suivante couvre le processus de rotation CA de bout en bout à l'aide de la AWS CLI et des API EKS.

Étape 1 : Vérifiez votre CA active

Afficher l'autorité de certification active sur votre cluster EKS.

aws eks list-certificate-authorities --cluster-name my-cluster --region us-west-2

Sortie attendue :

{
    "certificateAuthorities": [
        {
            "id": "a1b2c3d4-5678-90ab-cdef-example11111",
            "createdAt": "2024-01-15T10:30:00-07:00",
            "createdBy": "EKS",
            "activatedAt": "2024-01-15T10:30:00-07:00",
            "activatedBy": "EKS",
            "signingStatus": "IN_USE",
            "distributionStatus": "COMPLETE"
        }
    ]
}

Cela montre l'autorité de certification qui a été créée lors de la création de votre cluster EKS. Il est actuellement utilisé (signature de certificats) et sa distribution est terminée (tous les composants AWS gérés dans EKS lui font confiance).

Étape 2 : Afficher les détails de l'autorité de certification et son expiration

aws eks describe-certificate-authority --cluster-name my-cluster --certificate-authority-id a1b2c3d4-5678-90ab-cdef-example11111 --region us-west-2

Sortie attendue :

{
    "certificateAuthority": {
        "id": "a1b2c3d4-5678-90ab-cdef-example11111",
        "createdAt": "2024-01-15T10:30:00-07:00",
        "createdBy": "EKS",
        "activatedAt": "2024-01-15T10:30:00-07:00",
        "activatedBy": "EKS",
        "signingStatus": "IN_USE",
        "distributionStatus": "COMPLETE",
        "validity": {
            "notBefore": "2024-01-15T10:30:00-07:00",
            "notAfter": "2029-01-14T10:30:00-07:00"
        },
        "rollbackAvailable": false
    }
}

Le validity bloc indique quand l'autorité de certification a été créée (notBefore) et quand elle expire (notAfter). rollbackAvailableindique si vous pouvez revenir à une autorité de certification précédente après l'activation de la nouvelle autorité de certification. Pour l'autorité de certification initiale créée avec votre cluster EKS, cela sera false dû au fait qu'il n'existe aucune autorité de certification précédente à laquelle revenir.

Étape 3 : Ajouter une autorité de certification de remplacement

aws eks create-certificate-authority --cluster-name my-cluster --region us-west-2

Cela ajoute une autorité de certification successeur à votre cluster EKS. La réponse inclut un élément updateId que vous pouvez utiliser pour suivre les progrès.

Étape 4 : suivre la mise à jour

aws eks describe-update --name my-cluster --update-id a1b2c3d4-update-id --region us-west-2

Attendez que l'état de la mise à jour soit atteintSuccessful.

Étape 5 : Vérifier l'état de distribution

aws eks list-certificate-authorities --cluster-name my-cluster --region us-west-2

Vous devriez maintenant voir deux CA. L'autorité de certification qui lui succédera distributionStatus aura mis IN_PROGRESS à jour tous les composants gérés de votre cluster EKS signingStatus: NOT_USED et progressera une COMPLETE fois qu' AWS elle aura mis à jour tous les composants gérés.

Ne poursuivez pas tant que le statut de distribution de l'autorité de certification suivante n'est pas atteintCOMPLETE.

Étape 6 : mettez à jour votre kubeconfig

aws eks update-kubeconfig --name my-cluster --region us-west-2

Cela met à jour votre kubeconfig local pour qu'il fasse confiance aux deux autorités de certification. Après cela, vos commandes kubectl continueront de fonctionner après l'activation de l'autorité de certification suivante.

Étape 7 : mettez à jour les nœuds de travail que vous gérez et les clients externes

Ceci est traité en détail dans la section suivante. Une fois que tous les nœuds de travail que vous gérez et les clients externes ont été mis à jour pour faire confiance à l'autorité de certification suivante, passez à l'activation.

Étape 8 : Activez l'autorité de certification suivante

aws eks activate-certificate-authority --cluster-name my-cluster --certificate-authority-id <successor-ca-id> --region us-west-2

Après l'activation de l'autorité de certification remplaçante, votre cluster EKS émet des certificats signés par l'autorité de certification suivante. Vérifiez la connectivité pour vous assurer que tous les composants fonctionnent comme prévu.

Utilisation de la console Amazon EKS

La console Amazon EKS propose une expérience guidée pour la rotation des CA. Vous pouvez consulter l'état de votre autorité de certification, ajouter une autorité de certification de remplacement, suivre la progression de la distribution et activer l'autorité de certification de remplacement directement depuis la console.

L'image suivante montre la vue des détails de l'autorité de certification dans la console Amazon EKS pendant une rotation active. L'autorité de certification active et l'autorité de certification qui lui succède sont toutes deux affichées avec leur statut de signature, leur date d'expiration et le nombre de jours restant avant expiration.

L'image suivante montre l'affichage de la progression de la rotation dans la console Amazon EKS. Chaque étape du processus de rotation est affichée avec son état actuel, y compris l'ajout, la distribution, la mise à jour des nœuds de travail et des clients externes, l'activation et la suppression de l'autorité de certification sortante.

Mettre à jour vos clients Kubernetes

Une fois que l'autorité de certification remplaçante a été ajoutée et AWS a terminé la distribution aux composants gérés de votre cluster EKS (distributionStatus: COMPLETE), vous devez mettre à jour vos propres composants pour faire confiance à l'autorité de certification suivante. Dans ce contexte, un « client » est tout système qui se connecte au serveur d'API de votre cluster EKS. Cela inclut votre configuration kubectl locale, vos CI/CD pipelines, vos outils de surveillance, vos scripts d'automatisation et vos nœuds de travail.

Les données d'autorité de certification mises à jour pour votre cluster EKS (qui contient désormais à la fois les autorités de certification actuelles et les suivantes) peuvent être récupérées à l'aide de :

aws eks describe-cluster --name my-cluster --region us-west-2 --query 'cluster.certificateAuthority.data' --output text

Utilisez cette valeur pour mettre à jour la configuration de confiance de chaque type de client dans les sous-sections suivantes.

Kubeconfig (postes de travail pour développeurs, CI/CD pipelines, automatisation)

Exécutez la commande suivante pour mettre à jour votre kubeconfig local :

aws eks update-kubeconfig --name my-cluster --region us-west-2

Cela permet de récupérer automatiquement les dernières données CA et de mettre à jour votre kubeconfig. Tout système utilisant ce kubeconfig fera confiance aux deux autorités de certification.

Pour les CI/CD pipelines et les automatismes qui génèrent leur propre kubeconfig (par exemple, en utilisant directement les API EKS ou en stockant kubeconfig en tant que secret), mettez à jour le certificate-authority-data champ avec la valeur extraite. describe-cluster

Groupes de nœuds gérés

Effectuez une mise à jour de la version d'un groupe de nœuds pour déclencher un remplacement progressif des nœuds :

aws eks update-nodegroup-version --cluster-name my-cluster --nodegroup-name my-nodegroup --region us-west-2

Les nouveaux nœuds démarrent automatiquement avec les données CA mises à jour. Le remplacement progressif garantit le remplacement des nœuds un par un sans perturber les charges de travail en cours d'exécution.

Si vous gérez vos groupes de nœuds via Terraform ou CloudFormation, la rotation CA ne crée pas de dérive dans votre état IaC. Le cycle de vie de l'autorité de certification est géré via des API EKS dédiées qui sont distinctes de la configuration des ressources de votre cluster. Pour plus de détails sur la manière dont la rotation de CA interagit avec l'infrastructure en tant que code, consultez la section Infrastructure en tant que code.

Modèle de lancement personnalisé avec une AMI personnalisée

Si votre groupe de nœuds est déployé avec une AMI personnalisée, AWS ne fusionne pas les données utilisateur. Vous êtes responsable de fournir la configuration d'amorçage correcte, y compris le bundle CA Trust mis à jour. La rotation de l'autorité de certification ne met pas à jour vos données utilisateur à votre place, et un nœud sans autorité de certification successeur ne parvient pas à rejoindre le cluster.

Vérifiez que les nœuds s'exécutent sur le modèle de lancement mis à jour

Avant de procéder à l'activation, vérifiez que tous les nœuds de votre groupe de nœuds géré fonctionnent avec la dernière version du modèle de lancement. Cette version doit contenir le pack CA Trust mis à jour.

Karpenter-controlled nœuds

Si la détection de dérive est activée dans votre Karpenter NodePool, Karpenter détectera automatiquement que les nœuds fonctionnent avec des données CA obsolètes et les répercutera dans la fenêtre de perturbation configurée. Les nouveaux nœuds récupéreront l'autorité de certification qui lui succédera sans action manuelle.

Vérifiez que la détection de dérive est activée dans votre NodePool configuration :

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    budgets:
      - nodes: "10%"
  template:
    spec:
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default

S'il disruption est configuré avec une politique de consolidation, la détection de dérive est active par défaut. Karpenter remplacera les nœuds qui ont dérivé de l'état souhaité, ce qui inclut les modifications apportées aux données CA.

Si la détection de dérive est activée, vérifiez que votre budget d'interruption permet de remplacer tous les Karpenter-controlled nœuds avant la date d'activation de l'autorité de certification suivante. Si le budget est trop restreint (par exemple, une fenêtre de maintenance étroite avec un faible pourcentage de remplacement), il se peut que tous les nœuds ne soient pas remplacés à temps.

Si la détection de dérive est désactivée ou si vos budgets d'interruption limitent les remplacements à une fenêtre dépassant votre calendrier de rotation, vous pouvez déclencher manuellement le remplacement des nœuds en bouclant et en vidant les nœuds :

kubectl cordon <node-name>
kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data

Karpenter fournira un nœud de remplacement qui démarrera avec les données CA mises à jour.

Self-managed nœuds

Pour les nœuds autogérés, vous devez mettre à jour les données de l'autorité de certification dans le modèle de lancement ou le script de données utilisateur que vos nœuds utilisent lors du démarrage :

Les nouveaux nœuds démarreront avec les données de CA mises à jour et feront confiance à la fois aux autorités de certification actuelles et futures.

AWS Capsules Fargate (type de lancement EKS Fargate)

AWS Les pods Fargate de votre cluster EKS fonctionnent différemment des autres modes de lancement du plan de données EKS (groupes de nœuds gérés, nœuds autogérés, Karpenter-controlled nœuds).

Lorsqu'un pod se connecte au serveur API, deux choses se produisent : le pod s'authentifie à l'aide de son jeton de compte de service (prouvant son identité auprès du serveur API), et le pod vérifie l'identité du serveur API en vérifiant que le certificat du serveur a été signé par une autorité de certification en laquelle il a confiance. Les données CA stockées dans l'environnement du pod sont à l'origine de cette vérification. Si le serveur API commence à présenter des certificats signés par une autorité de certification remplaçante à laquelle le pod n'a pas confiance, ce dernier rejettera la connexion.

Dans les autres modes de lancement du plan de données EKS (groupes de nœuds gérés, nœuds autogérés, Karpenter-controlled nœuds), les données CA résident sur le nœud. Lorsque vous remplacez le nœud, le nouveau nœud démarre avec les données CA mises à jour. Les pods planifiés sur ce nouveau nœud reçoivent les données CA mises à jour, ce qui leur permet de vérifier le serveur API, quelle que soit l'autorité de certification qui a signé son certificat.

Dans Fargate, chaque pod s'exécute dans son propre environnement informatique dédié avec son propre processus Kubelet. Ce kubelet démarre avec les données CA au moment de la création du pod. Il n'y a aucun nœud partagé en dessous et vous n'avez pas d'accès direct au calcul sous-jacent.

Aucune action du client n'est requise pour les nœuds AWS Fargate dans EKS pendant la rotation de CA. AWS recycle naturellement les pods dans les nœuds Fargate grâce à son processus de patching. Après l'ajout d'un CA successeur, les capsules Fargate préexistantes sont recyclées dans le cadre de ce processus. Ils feront confiance à l'autorité de certification qui leur succédera sans aucune action de votre part. Étant donné que l'AC successeur AWS est ajouté bien avant le calendrier d'activation de toute autorité de certification AWS initiée dans EKS, les pods Fargate auront été recyclés et feront confiance à l'autorité de certification remplaçante au moment de l' AWS activation de l'autorité de certification suivante. Il existe une protection intégrée qui empêche l'activation du système de certification successeur tant que les capsules Fargate n'ont pas terminé le recyclage.

Cela signifie que les deux options de plan de données géré (EKS Auto Mode et Fargate) pour un cluster EKS offrent la même expérience utilisateur pour la rotation CA : aucune action du client n'est requise pour vos nœuds de travail. Vous êtes toujours responsable de la mise à jour de tous les clients externes qui se connectent au serveur API.

Il s'agit d'un étui exceptionnel. Compte tenu du calendrier de rotation (l'autorité de certification remplaçante a été ajoutée des années avant l'expiration), le cycle naturel de mise à jour s'achèvera bien avant l'activation de l'autorité de certification remplaçante dans la grande majorité des scénarios. La protection existe à titre de mesure préventive dans le cas peu probable où un client tenterait une activation anticipée.

Clients externes (outils de surveillance, intégrations tierces)

Toute application ou outil qui se connecte au serveur d'API de votre cluster EKS à l'aide d'une configuration kubeconfig ou certificate trust doit être mis à jour avec les données CA mises à jour. Cela inclut notamment les éléments suivants :

Pour chacun d'entre eux, remplacez les données CA stockées par la valeur mise à jour dedescribe-cluster.

Comment vérifier qu'un client a été mis à jour

Après avoir mis à jour un client, vérifiez qu'il peut toujours communiquer avec le serveur API :

kubectl get nodes

Si la commande aboutit, votre kubeconfig fait confiance aux données CA actives. Après l'activation de l'autorité de certification suivante, exécutez la même commande pour confirmer la continuité de la connectivité.

Infrastructure en tant que code

Vous pouvez effectuer une rotation CA parallèlement à votre infrastructure en tant que code (IaC) existante sans créer de dérive ni nécessiter de modifications de vos configurations IaC.

Pourquoi la rotation CA n'affecte pas l'état de votre IaC

Le cycle de vie de l'autorité de certification est géré via des API EKS dédiées (create-certificate-authorityactivate-certificate-authority,,delete-certificate-authority) totalement distinctes de la configuration des ressources du cluster EKS. Que la rotation CA soit initiée par vous ou automatiquement par AWS, aucune propriété suivie par votre outillage IaC sur la ressource du cluster EKS n'est modifiée.

Autrement dit :

Le certificateAuthority.data champ renvoyé par describe-cluster est une sortie en lecture seule. Il reflète le bundle de confiance combiné actuel (les deux CA pendant la période de double confiance) mais n'est pas une propriété configurable. Les outils IaC ne le considèrent pas comme quelque chose à réconcilier.

Les champs d'attribution (createdBy,activatedBy) de chaque enregistrement CA vous permettent de faire la distinction entre les opérations que vous avez initiées et les opérations AWS initiées automatiquement, ce qui prend en charge les flux de travail d'audit et de gestion des modifications.

Utilisation CloudFormation avec la rotation CA

La rotation de l'autorité de certification peut être déclenchée CloudFormation en utilisant une WriteOnly propriété sur la AWS::EKS::Cluster ressource. Cette propriété déclenche l'activation mais n'est pas stockée dans l'état de la pile. Par conséquent, les mises à jour ultérieures de la pile sans elle ne tentent pas de revenir en arrière ou de se désactiver.

# Phase 1: Add to existing stack that manages your cluster
Resources:
    NewCA:
        Type: AWS::EKS::CertificateAuthority
        Properties:
            ClusterName: my-cluster

    MyCluster:
        Type: AWS::EKS::Cluster
        Properties:
            Name: my-cluster

Cette première mise à jour de la pile ajoute une autorité de certification successeur à votre cluster. Attendez que le statut de distribution de l'autorité de certification suivante soit atteint COMPLETE avant de continuer.

# Phase 2: After distribution completes, update your existing Cluster resource to activate
Resources:
    NewCA:
        Type: AWS::EKS::CertificateAuthority
        Properties:
            ClusterName: my-cluster

    # Update your existing Cluster resource to activate
    MyCluster:
        Type: AWS::EKS::Cluster
        Properties:
            Name: my-cluster
            ActiveCertificateAuthorityId: !GetAtt NewCA.Id

Cette deuxième mise à jour de la pile déclenche l'activation de la CA qui lui succède. Comme il ActiveCertificateAuthorityId s'agit d'une WriteOnly propriété, elle n'est pas renvoyée lors de la lecture et ne CloudFormation détectera pas de dérive si l'autorité de certification active change en dehors de CloudFormation (par exemple, via une activation automatique par AWS).

Important : L' CloudFormation intégration de la rotation CA suit un schéma différent de celui CloudFormation des ressources classiques. Une autorité de certification dans EKS n'est pas une ressource indépendante dotée de son propre ARN. Elle fait partie du cycle de vie des certificats du cluster et est autorisée via le cluster lui-même, de la même manière qu'une politique de rôle IAM est autorisée via son rôle parent (AWS::IAM::RolePolicy) ou qu'une association EIP est autorisée via son instance (AWS::EC2::EIPAssociation). Les clients qui gèrent la rotation de CA CloudFormation doivent être conscients de cette distinction.

Groupes de nœuds gérés et IaC

L'exécution d'une mise à jour de la version d'un groupe de nœuds pour actualiser les nœuds avec la configuration CA Trust mise à jour est une action opérationnelle. Les nouveaux nœuds démarrent automatiquement avec les données CA Trust actives du cluster. Si vos modèles IaC ne codent pas en dur les données CA dans les modèles de lancement ou les données utilisateur, aucune modification de modèle n'est requise.

Restauration CA

Après avoir activé une autorité de certification remplaçante, vous pouvez revenir à l'autorité de certification précédente si vous découvrez des problèmes de connectivité avec les nœuds de travail que vous gérez (mode automatique non EKS, non Fargate) ou avec des clients externes. La restauration réactive l'autorité de certification précédente en tant qu'autorité de signature pour votre cluster EKS.

Quand CA Rollback est disponible

La restauration de l'autorité de certification est disponible après l'activation de l'autorité de certification à condition que :

Vous pouvez vérifier si CA rollback est disponible à tout moment à l'aide du rollbackAvailable champ renvoyé par describe-certificate-authority :

aws eks describe-certificate-authority --cluster-name my-cluster --certificate-authority-id <ca-id> --region us-west-2

{
    "certificateAuthority": {
        "id": "a1b2c3d4-5678-90ab-cdef-example22222",
        "signingStatus": "IN_USE",
        "distributionStatus": "COMPLETE",
        "rollbackAvailable": true
    }
}

Lorsque CA Rollback n'est pas disponible

La restauration CA n'est pas disponible après l'activation automatique finale. Si l' AWS autorité de certification suivante est activée pour la dernière fois (45 jours avant l'expiration de l'autorité de certification), la rotation doit se poursuivre. L'activation automatique finale ne se produit que si la première activation automatique a été précédemment annulée. Il s'agit d'une protection de dernier recours pour garantir que le cluster EKS n'arrive pas à expiration en tant qu'autorité de certification valide.

Comment revenir en arrière

Pour revenir en arrière, réactivez l'ancienne autorité de certification :

aws eks activate-certificate-authority --cluster-name my-cluster --certificate-authority-id <previous-ca-id> --region us-west-2

Que se passe-t-il lors de la restauration de CA

Quand faut-il envisager la restauration de CA ?

La restauration de l'autorité de certification est un mécanisme de sécurité destiné aux situations où l'activation de l'autorité de certification suivante révèle un problème de connectivité que vous n'avez pas détecté auparavant :

Après l'annulation, vous conservez la totalité de la période de double confiance pour identifier et résoudre le problème avant de réactiver l'autorité de certification suivante.

Restauration sans restauration CA

Si vous activez l'autorité de certification suivante avant de mettre à jour vos groupes de nœuds gérés et que la fenêtre de restauration de l'autorité de certification n'est plus disponible (par exemple, après la date limite finale d'activation automatique), vous pouvez effectuer une restauration en effectuant une mise à jour continue des groupes de nœuds concernés. Cependant, la tentative initiale de mise à jour continue échouera car les nœuds déconnectés ne peuvent pas recevoir de commandes d'expulsion de pods depuis le serveur API.

Étapes de restauration

Considérations et restrictions

Disponibilité par région

La rotation CA est disponible dans toutes les régions AWS commerciales où Amazon EKS est pris en charge.

Deux autorités de certification au maximum

Un cluster EKS peut avoir au maximum deux autorités de certification à tout moment : l'autorité de certification active et une autorité de certification qui lui succède. Vous ne pouvez pas ajouter une deuxième autorité de certification remplaçante tant que la rotation précédente n'est pas terminée.

Aucune révocation de certificat

La rotation des autorités de certification ne permet pas de révoquer des certificats individuels. Cela est cohérent avec Kubernetes en amont, qui n'implémente pas la révocation des certificats (CRL ou OCSP). La rotation remplace l'ensemble de l'autorité de certification, ce qui invalide naturellement tous les certificats signés par l'autorité de certification sortante une fois celle-ci supprimée du bundle de confiance.

AWS-les CA ajoutées ne peuvent pas être supprimées

Si une autorité de certification de remplacement a été ajoutée AWS automatiquement, vous ne pouvez pas la supprimer. Cette protection garantit que le processus de rotation ne peut pas être interrompu par une suppression accidentelle. Customer-appended Les autorités de certification peuvent être supprimées tant qu'il ne s'agit pas de l'autorité de certification signataire active.

Période de validité CA

L'autorité de certification d'origine créée avec votre cluster a une période de validité de 10 ans. Les CA successeurs créées dans le cadre du processus de rotation ont une période de validité de 5 ans. Toutes les futures CA de votre cluster suivront la période de validité de 5 ans. Vérifiez l'expiration de votre CA à l'aide dedescribe-certificate-authority.

Taille des données utilisateur EC2 en cas de double confiance

Pendant la période de double confiance, la taille du bundle de confiance de votre cluster augmente en raison de la présence de deux certificats CA (environ 2,8 Ko combinés, ou environ 1,9 Ko avec la compression gzip). Pour les nœuds de travail où des données utilisateur personnalisées sont fournies dans les modèles de lancement EC2, vérifiez que la taille totale de vos données utilisateur ne dépasse pas la limite de 16 Ko de données utilisateur EC2. Si vos données utilisateur existantes sont proches de cette limite, l'ajout d'une deuxième autorité de certification peut entraîner l'échec de la création du modèle de lancement et empêcher le provisionnement de nouveaux nœuds. Envisagez de compresser le contenu de vos données utilisateur à l'aide de gzip pour en réduire la taille.

Mises à niveau des versions pendant la rotation de CA

Les mises à niveau des versions du cluster EKS et la rotation du CA sont des opérations indépendantes. Cependant, vous ne pouvez pas exécuter les deux simultanément. Si une opération de rotation de l'autorité de certification est en cours, une mise à niveau de version sera rejetée jusqu'à ce que l'opération de certification soit terminée, et vice versa.

Apportez votre propre CA (BYOCA)

L'utilisation de votre propre autorité de certification AWS privée pour sauvegarder les certificats de votre cluster EKS n'est actuellement pas prise en charge.

Questions fréquentes (FAQ)

Comment démarrer avec CA Rotation ?

Pour commencer, lancez aws eks list-certificate-authorities --cluster-name my-cluster pour afficher votre autorité de certification active et son expiration. Si vous êtes prêt à commencer la rotation, exécutez aws eks create-certificate-authority --cluster-name my-cluster pour ajouter une autorité de certification de remplacement. Le processus complet, étape par étape, est décrit dans la section Démarrage. Vous pouvez également effectuer une rotation CA via la console Amazon EKS.

Y a-t-il des coûts associés à la rotation des CA ?

Non. La rotation CA est disponible sans frais supplémentaires pour tous les clusters EKS.

Que se passe-t-il si je ne fais pas alterner mon CA avant son expiration ?

Nous avons mis en place des mesures de protection automatiques qui empêchent votre cluster EKS d'atteindre l'expiration de l'autorité de certification sans qu'une autorité de certification valide ne soit en place. Si vous n'initiez pas vous-même la rotation de l'autorité de certification, nous ajouterons et activerons automatiquement une autorité de certification remplaçante avant l'expiration, afin de garantir la disponibilité de votre cluster.

Cependant, pour réussir la rotation, vous devez également mettre à jour les nœuds de travail que vous gérez (mode automatique non EKS, non Fargate) et les clients externes afin qu'ils fassent confiance à l'autorité de certification qui succédera. Si ces composants ne sont pas mis à jour avant l'activation de l'autorité de certification suivante, ils perdront leur connectivité au serveur API.

Dans Kubernetes, si une autorité de certification ne fait pas l'objet d'une rotation avant son expiration, tous les certificats signés par cette autorité de certification deviennent invalides. Le serveur API n'est plus joignable par aucun client et le cluster devient indisponible.

De combien de temps me reste-t-il pour terminer la rotation CA ?

Le temps total nécessaire pour terminer la rotation des CA dépend à la fois des mesures de protection AWS automatisées et de votre propre processus de mise à jour.

AWS fournit des délais définitifs pour ce qu'il gère. Une autorité de certification de remplacement est ajoutée environ 2 ans avant l'expiration de votre autorité de certification sortante. Si vous n'activez pas vous-même l'autorité de certification suivante, nous l'activerons automatiquement environ 6 mois avant son expiration. Si vous revenez en arrière après l'activation automatique, nous effectuerons une dernière activation automatique 45 jours avant l'expiration. Ces mesures de protection garantissent que votre cluster EKS reste disponible, que vous agissiez ou non.

Une rotation réussie de l'autorité de certification dépend également de la mise à jour des nœuds de travail que vous gérez (mode automatique non EKS, non Fargate) et des clients externes pour qu'ils fassent confiance à l'autorité de certification suivante avant l'activation de l'autorité de certification suivante. Le temps nécessaire dépend de la configuration du nœud de travail de votre plan de données, de l'empreinte de votre client externe et du temps qu'il vous faut pour effectuer la découverte et les mises à jour de ces composants.

La rotation de CA entraîne-t-elle une interruption de service pour mon cluster ?

Non. Votre cluster EKS reste disponible tout au long du cycle de vie de rotation de CA. Le plan de contrôle continue de répondre aux demandes à chaque étape. Pendant la période de double confiance, les autorités de certification sortantes et les autorités de certification suivantes sont approuvées simultanément, ce qui permet de mettre à jour les composants de manière incrémentielle sans interrompre les opérations du cluster. Si vous êtes revenu à l'autorité de certification précédente en raison de la découverte de problèmes côté client, effectuez un AWS dernier report environ 45 jours avant l'expiration de l'autorité de certification sortante à titre de mesure de sauvegarde.

Il est important de faire la distinction entre le cluster EKS (plan de contrôle) et les composants de votre plan de données. Le plan de commande est entièrement géré par AWS et reste disponible tout au long de la rotation.

Pour EKS Auto Mode et Fargate, AWS met automatiquement à jour les nœuds de travail. Il n'y a aucun risque de perte de connectivité pour vos nœuds de travail dans ces modes de lancement du plan de données. Vous êtes toujours responsable de la mise à jour de tous les clients externes qui se connectent au serveur API.

Pour les groupes de nœuds gérés, les nœuds autogérés, les Karpenter-controlled instances (sans détection de dérive activée) et les nœuds hybrides, vous êtes responsable du remplacement ou de la mise à jour de ces nœuds avant l'activation de l'autorité de certification suivante. S'ils ne sont pas remplacés, ces nœuds perdront leur connectivité au plan de contrôle après l'activation du CA successeur, même si le plan de contrôle lui-même reste pleinement opérationnel.

Mes charges de travail seront-elles perturbées pendant la rotation des CA ?

Les charges de travail en cours d'exécution (modules) ne sont pas perturbées par la rotation de l'AC elle-même. Les pods communiquent entre eux via le réseau du cluster, qui n'est pas affecté par un changement de CA. L'autorité de certification est utilisée pour la communication entre les composants et le serveur API, et non pour le trafic de module à module.

Si vos nœuds de travail doivent être remplacés dans le cadre de leur mise à jour pour faire confiance à l'autorité de certification suivante (par exemple, des groupes de nœuds gérés effectuant une mise à jour continue ou Karpenter remplaçant des nœuds dérivés), les pods de ces nœuds seront reprogrammés dans le cadre du processus normal de remplacement des nœuds. Il s'agit du comportement standard de Kubernetes lors du remplacement des nœuds, et non d'un effet secondaire de la rotation de l'autorité de certification. Assurez-vous que les budgets d'interruption des pods (PDB) sont configurés pour les charges de travail critiques afin de contrôler la manière dont les pods sont expulsés lors du remplacement des nœuds.

Quand expirera l'autorité de certification de mon cluster ?

Vous pouvez vérifier la date d'expiration de l'autorité de certification de votre cluster à l'aide de l' AWS interface de ligne de commande, des API EKS ou de la console Amazon EKS. Par exemple, vous pouvez exécuter les opérations suivantes :

aws eks describe-certificate-authority --cluster-name my-cluster --certificate-authority-id <ca-id> --region us-west-2 --query 'certificateAuthority.validity.notAfter'

Vous pouvez trouver l'identifiant de votre autorité de certification en courantaws eks list-certificate-authorities --cluster-name my-cluster.

Quelle est la durée de validité du CA de mon cluster ?

L'autorité de certification d'origine créée avec votre cluster a une période de validité de 10 ans. Les CA successeurs créées dans le cadre du processus de rotation ont une période de validité de 5 ans. Toutes les futures CA de votre cluster suivront la période de validité de 5 ans. Vous pouvez vérifier l'expiration de votre CA à l'aide dedescribe-certificate-authority.

Puis-je initier moi-même une rotation CA avant ? AWS est-ce automatique ?

Oui. Vous pouvez ajouter une autorité de certification de remplacement à tout moment à l'aide aws eks create-certificate-authority --cluster-name my-cluster de. Vous n'avez pas besoin d'attendre AWS pour lancer la rotation. Commencer tôt vous donne plus de temps pour identifier et mettre à jour vos nœuds de travail et vos clients externes selon votre propre calendrier.

Puis-je revenir en arrière après avoir activé une autorité de certification remplaçante ?

Oui, la restauration de l'autorité de certification est disponible après l'activation de l'autorité de certification suivante tant que la fenêtre de restauration n'est pas expirée. CA rollback réactive l'autorité de certification précédente en tant qu'autorité de signature. Il n'est pas disponible après l'activation automatique finale (45 jours avant l'expiration du CA). Vous pouvez vérifier le rollbackAvailable champ de votre autorité de certification à l'aide dedescribe-certificate-authority. Consultez la section CA Rollback pour plus de détails.

Comment savoir s'il est possible d'activer la nouvelle autorité de certification en toute sécurité ?

Vous pouvez activer l'autorité de certification suivante en toute sécurité lorsque tous les nœuds de travail que vous gérez (mode automatique autres que EKS, non Fargate) et les clients externes ont été mis à jour pour faire confiance à l'autorité de certification suivante. Vous pouvez le vérifier en confirmant que chaque client peut communiquer avec succès avec le serveur API à l'aide de la configuration de confiance mise à jour. AWS ne fournit pas un seul indicateur indiquant que tous les clients sont prêts, car il ne peut pas accéder à vos systèmes externes. Commencez le processus de découverte tôt pour vous donner le temps d'identifier tous les clients.

Comment puis-je suivre la progression de la rotation des CA sur plusieurs clusters ?

Vous pouvez le faire par programmation à l'aide de la AWS CLI ou de l'API EKS. À utiliser aws eks list-certificate-authorities pour chaque cluster. Les champs suivants fournissent une connaissance de la situation pour la surveillance au niveau de la flotte :

L'exemple de script suivant vérifie l'état de rotation de l'autorité de certification sur une liste de clusters :

#!/bin/bash
CLUSTERS=("cluster-1" "cluster-2" "cluster-3")
REGION="us-west-2"

for CLUSTER in "${CLUSTERS[@]}"; do
  echo "--- $CLUSTER ---"
  aws eks list-certificate-authorities \
    --cluster-name "$CLUSTER" \
    --region "$REGION" \
    --query 'certificateAuthorities[].{Id:id,Signing:signingStatus,Distribution:distributionStatus,Expiry:validity.notAfter}' \
    --output table
done

Vous pouvez étendre cette option pour couvrir plusieurs régions et comptes, et filtrer les clusters auxquels une autorité de certification successeure a été ajoutée, qui attendent votre action ou qui approchent de la date limite d'activation automatique.

Les notifications sont également envoyées par cluster via AWS Health et par e-mail à chaque étape du cycle de vie de la rotation.

Que se passe-t-il si j'active l'autorité de certification suivante avant de mettre à jour tous mes clients ?

Tout client qui n'a pas été mis à jour pour faire confiance à l'autorité de certification qui lui succédera perdra sa connectivité au cluster EKS. Après l'activation de l'autorité de certification remplaçante, le serveur d'API présente les certificats signés par l'autorité de certification suivante. Les clients qui ne lui font pas confiance échoueront lors de leur vérification TLS et ne pourront pas se connecter. Dans ce cas, vous pouvez revenir à l'autorité de certification précédente (si la fenêtre de restauration est toujours disponible) pour rétablir la connectivité pendant que vous corrigez les clients restants.

Que se passe-t-il si je dépasse la date limite d'expiration du CA ?

AWS empêche que cela ne se produise. Les protections automatiques garantissent que votre cluster EKS n'atteindra pas l'expiration de l'autorité de certification sans qu'une autorité de certification valide ne soit en place. Si vous ne l'avez pas encore fait, nous ajouterons une nouvelle autorité de certification et l'activerons automatiquement environ 6 mois avant l'expiration. Si vous êtes revenu en arrière après la première activation automatique, AWS effectue une dernière reconduction 45 jours avant l'expiration. Votre cluster restera disponible.

Toutefois, si les nœuds de travail que vous gérez (mode automatique autres que EKS, non Fargate) et les clients externes n'ont pas été mis à jour pour faire confiance à l'autorité de certification suivante au moment de l'activation automatique, ces composants perdront leur connectivité au serveur API.

Puis-je perdre l'accès à mon cluster pendant la rotation de l'AC ?

Votre cluster EKS (plan de contrôle) reste disponible tout au long du cycle de vie de rotation de CA. AWS les mesures de protection garantissent que le cluster lui-même ne devient pas indisponible.

Cependant, les clients individuels que vous gérez peuvent perdre l'accès s'ils ne sont pas mis à jour pour faire confiance à l'autorité de certification suivante avant l'activation de cette dernière. Par exemple, si votre kubeconfig, votre CI/CD pipeline ou votre outil de surveillance ne fait toujours référence qu'à l'autorité de certification sortante, ces clients ne pourront pas se connecter une fois l'autorité de certification suivante activée. Dans ce cas, CA Rollback peut rétablir l'accès pendant que vous mettez à jour les clients concernés.

Dois-je redémarrer mes pods ?

Les modules de charge de travail en cours d'exécution ne sont pas directement affectés par la rotation du CA. Le kubelet de chaque nœud gère les communications avec le serveur d'API, de sorte que les modules de charge de travail continueront à fonctionner sans interruption tant que vos nœuds seront mis à jour. Cependant, les contrôleurs et les opérateurs intégrés au cluster qui utilisent client-go pour communiquer avec le serveur d'API devront peut-être être redémarrés après l'activation de l'autorité de certification successeur, car client-go ne relit pas dynamiquement le bundle CA trust. Pour les nœuds AWS Fargate en particulier, AWS gère la mise à jour automatiquement via le processus naturel de recyclage des pods.

Mon pack Trust sera-t-il modifié pendant la rotation ?

Oui. Pendant la rotation de l'autorité de certification, le bundle de confiance de votre cluster contiendra deux autorités de certification simultanément : l'autorité de certification sortante et l'autorité de certification suivante. Ce comportement est attendu pendant la période de double confiance et c'est ainsi que le processus de rotation maintient la connectivité pour tous les composants.

Les applications et les clients doivent être configurés de manière à faire confiance à un bundle CA plutôt qu'à un seul certificat CA. L'épinglage de l'autorité de certification (validation stricte par rapport à une seule autorité de certification) n'est pas recommandé, car cela provoquera des échecs lors de la mise à jour du bundle de confiance. Cela s'applique à toute configuration TLS côté client qui se connecte au serveur d'API de votre cluster EKS.

Pourquoi le calendrier de mes notifications est-il différent de celui décrit dans cette documentation ?

Si votre cluster a été créé en 2018-2019, il recevra des notifications automatisées selon un calendrier ajusté. Votre première notification inclura les dates pertinentes et les prochaines étapes spécifiques à votre cluster. Les jalons de notification standard sont calculés par rapport à la date d'expiration de l'autorité de certification de votre cluster. Pour les clusters de cette plage, ces dates calculées précèdent la disponibilité de cette fonctionnalité. Un calendrier ajusté est donc appliqué.