Cette page explique comment faire tourner les identifiants de votre cluster GKE. Planifier et faire tourner régulièrement les identifiants de votre cluster est essentiel pour maintenir vos clusters dans un état opérationnel. Sur cette page, vous allez apprendre à effectuer des rotations d'identifiants. Vous découvrirez également les bonnes pratiques à suivre pour planifier des rotations régulières.
Cette page s'adresse aux spécialistes de la sécurité chargés du cycle de vie des identifiants sur les clusters GKE. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenu Google Cloud , consultez la section Rôles utilisateur et tâches courantes de l'utilisateur dans GKE Enterprise.
À propos des rotations d'identifiants dans GKE
L'autorité de certification (CA) racine du cluster a une durée de vie limitée. Lorsque l'autorité de certification expire, tous les identifiants signés par l'autorité de certification ne sont plus valides, y compris le certificat client du cluster (du champ d'API MasterAuth
), la clé et le certificat du serveur d'API, ainsi que les certificats client kubelet.
La durée de validité des identifiants de votre cluster dépend de la date à laquelle vous avez créé le cluster ou de la date à laquelle vous avez effectué la dernière rotation de vos identifiants. Pour en savoir plus, consultez la durée de validité des identifiants.
Vous pouvez effectuer une rotation des identifiants pour révoquer et émettre de nouveaux identifiants pour votre cluster. Cette opération entraîne la rotation de la clé privée de l'autorité de certification du cluster et nécessite de recréer des nœuds pour utiliser de nouveaux identifiants. Vous devez démarrer et terminer une rotation des identifiants pour votre cluster avant l'expiration de vos identifiants actuels. Notez en outre que la rotation des identifiants entraîne également une rotation des adresses IP.
Quand effectuer une rotation des identifiants
Vous devez effectuer des rotations des identifiants régulièrement et avant la date d'expiration de vos identifiants actuels. Les rotations d'identifiants nécessitent la recréation de nœuds pour utiliser les nouveaux identifiants, ce qui peut perturber les charges de travail en cours d'exécution. Planifiez les périodes de maintenance et effectuez les rotations pendant les intervalles de maintenance afin d'éviter les temps d'arrêt inattendus des charges de travail ou les clients API qui ne répondent pas en dehors du cluster.
Pour en savoir plus sur l'impact de la disponibilité de la maintenance sur la rotation des identifiants de cluster et sur le type de perturbation que votre cluster subit lors des étapes d'une rotation, consultez la ligne sur la rotation des identifiants dans le tableau des modifications manuelles qui recréent les nœuds à l'aide d'une stratégie de mise à niveau des nœuds et respectent les règles de maintenance. GKE dépend de la disponibilité des ressources pour mettre à jour les nœuds. Pour en savoir plus sur les mises à jour de nœuds, consultez Planifier les perturbations liées aux mises à jour de nœuds.
Durée de vie des identifiants du cluster
La durée de vie des identifiants du cluster dépend généralement de la date de création du cluster ou de la date à laquelle les identifiants ont été remplacés pour la dernière fois:
- Les clusters créés avant environ octobre 2021 ont une durée de vie de l'autorité de certification de cinq ans.
- Les clusters créés après environ octobre 2021 ont une durée de vie de 30 ans.
- Les clusters qui ont été remplacés après janvier 2022 ont une durée de vie de 30 ans.
Rechercher les clusters dont les identifiants arrivent à expiration ou ont expiré
Si les identifiants de votre cluster expirent dans les 180 prochains jours ou ont déjà expiré, GKE fournit des conseils sous forme d'insight et de recommandation pour expliquer qu'il est nécessaire d'effectuer une rotation des identifiants pour ce cluster. Ces conseils incluent la date d'expiration des identifiants. Vous pouvez les consulter dans la console Google Cloud . Vous pouvez également afficher ces conseils en utilisant la gcloud CLI ou l'API Recommender en spécifiant le sous-type CLUSTER_CA_EXPIRATION
.
Si vous recevez un insight et une recommandation pour un cluster, vous devez effectuer une rotation des identifiants. Sinon, GKE lance automatiquement une rotation des identifiants dans les 30 jours suivant la date d'expiration de l'autorité de certification actuelle, comme expliqué dans la section suivante. Une fois la rotation des identifiants terminée, il peut s'écouler jusqu'à 36 heures avant que l'insight et la recommandation soient résolus.
Règle d'automatisation GKE pour éviter les interruptions de clusters
Pour éviter que votre cluster n'entre dans un état irrécupérable en cas d'expiration de vos identifiants actuels, GKE lance automatiquement une rotation des identifiants dans les 30 jours suivant la date d'expiration de votre autorité de certification actuelle. Par exemple, l'autorité de certification de votre cluster expire le 6 janvier 2024 et vous ne procédez pas à la rotation de vos identifiants avant le 5 décembre 2023. GKE lance une rotation automatique le 7 décembre 2023 ou après cette date, et tente de finaliser cette rotation sept jours après le début de l'opération. Cette rotation automatique est une tentative de dernier recours pour éviter une interruption du cluster. Elle prend en compte les points suivants:
- Les rotations automatiques respectent généralement les intervalles de maintenance ou les exclusions de maintenance. Toutefois, GKE se réserve le droit d'effectuer des étapes dans les 30 jours suivant l'expiration pour faire pivoter les identifiants, quelle que soit la disponibilité de la maintenance. Dans un délai de 30 jours, GKE ignore la disponibilité de la maintenance pour la première étape, à savoir le démarrage de la rotation.
- Si la disponibilité de la maintenance empêche GKE de terminer la rotation initialement, GKE continue de tenter de la terminer jusqu'à la date d'expiration des identifiants, après quoi le cluster devient irrécupérable.
- Une fois la rotation des identifiants terminée, les identifiants arrivant à expiration sont révoqués. Les clients d'API Kubernetes en dehors du cluster, tels que kubectl dans les environnements locaux, ne fonctionneront pas tant que vous n'aurez pas configuré les clients pour qu'ils utilisent les nouveaux identifiants.
- Les recréations de pools de nœuds pendant la rotation peuvent perturber les charges de travail en cours d'exécution.
Avant de commencer
Avant de commencer, effectuez les tâches suivantes :
- Activez l'API Google Kubernetes Engine. Activer l'API Google Kubernetes Engine
- Si vous souhaitez utiliser Google Cloud CLI pour cette tâche, installez puis initialisez gcloud CLI. Si vous avez déjà installé gcloud CLI, assurez-vous de disposer de la dernière version en exécutant la commande
gcloud components update
.
Vérifier la durée de vie des identifiants
Nous vous recommandons de vérifier la durée de vie de vos identifiants avant et après l'exécution d'une rotation des identifiants. Cela vous permet de vous assurer de la validité de l'autorité de certification racine de votre cluster.
Exécutez la commande suivante pour vérifier la durée de vie des identifiants pour un seul cluster :
gcloud container clusters describe CLUSTER_NAME \
--location LOCATION \
--format "value(masterAuth.clusterCaCertificate)" \
| base64 --decode \
| openssl x509 -noout -dates
Le résultat ressemble à ce qui suit :
notBefore=Mar 17 16:45:34 2023 GMT
notAfter=Mar 9 17:45:34 2053 GMT
Si vous exécutez cette commande après avoir lancé une rotation des identifiants, la sortie correspond à la durée de validité de votre certificat d'origine. Ce certificat reste valide jusqu'à ce que vous terminiez la rotation. Une fois la rotation terminée, la durée de validité de votre nouveau certificat est affichée.
Exécutez la commande suivante pour vérifier la durée de vie des identifiants pour tous les clusters d'un projet :
gcloud container clusters list --project PROJECT_ID \
--format="value(name,masterAuth.clusterCaCertificate)" | \
while read -r cluster ca; do \
expiry_date=$(echo -e "$ca" | base64 --decode | openssl x509 -noout -enddate | awk -F'=' '{print $2}'); \
printf "%-40s | %s\n" "$cluster" "$expiry_date" ; \
done | \
column -t | \
awk -F',' 'BEGIN{print "Cluster Name | Certificate Expiry Date"} {print}'
Effectuer une rotation des identifiants
Toute rotation d'identifiants comprend les étapes suivantes:
- Lancement de la rotation : le plan de contrôle commence à diffuser le trafic sur une nouvelle adresse IP en plus de l'adresse IP d'origine. De nouveaux identifiants sont émis pour les charges de travail et le plan de contrôle.
- Recréation des nœuds : GKE recrée les nœuds de cluster afin qu'ils utilisent la nouvelle adresse IP et les nouveaux identifiants, en respectant la disponibilité définie par les intervalles de maintenance et les exclusions. Vous pouvez également recréer manuellement vos nœuds en effectuant une mise à niveau de la version de nœud vers la même version de GKE que celle que les nœuds exécutent déjà.
- Mise à jour des clients API : après avoir lancé la rotation, mettez à jour les clients API du cluster, tels que les ordinateurs de développement utilisant
kubectl
, afin qu'ils puissent communiquer avec le plan de contrôle à l'aide de la nouvelle adresse IP. - Achèvement de la rotation : le plan de contrôle cesse de diffuser le trafic sur l'adresse IP d'origine. Les anciens identifiants sont révoqués, y compris les identifiants statiques existants pour les comptes de service Kubernetes.
Lorsque vous lancez une rotation des identifiants ou que GKE la lance automatiquement, GKE effectue automatiquement ces étapes, y compris en essayant de terminer la rotation. À chaque étape, si l'expiration du cluster est prévue dans plus de 30 jours, GKE respecte la disponibilité de la maintenance. Lors des rotations automatiques avant l'expiration du cluster, GKE se réserve le droit d'ignorer la disponibilité de la maintenance pour éviter que votre cluster ne devienne irrécupérable. Dans les 30 jours, GKE ignore la disponibilité de la maintenance pour la première étape, qui consiste à démarrer la rotation.
Si vous ne terminez pas une rotation des identifiants dans les sept jours suivant son lancement, GKE tente de la terminer à votre place. Si des nœuds de votre cluster utilisent toujours les identifiants précédents, l'opération de finalisation automatique échoue, mais GKE continue de tenter la finalisation jusqu'à ce que les identifiants expirent et que le cluster ne soit plus récupérable. Vous devez planifier de suivre et de terminer manuellement toutes les rotations d'identifiants que vous démarrez. Pour ignorer les bloqueurs de disponibilité de maintenance, exécutez les commandes de chacune des sections suivantes pour déclencher manuellement ces phases du processus de rotation. Ne vous fiez pas à la saisie semi-automatique, qui est une mesure de dernier recours.
Lancer la rotation
Pour lancer une rotation des identifiants, exécutez la commande suivante :
gcloud container clusters update CLUSTER_NAME \
--location LOCATION \
--start-credential-rotation
Cette commande crée de nouveaux identifiants, les transmet au plan de contrôle et configure ce dernier afin qu'il diffuse le trafic sur deux adresses IP (l'adresse IP d'origine et une nouvelle adresse IP).
Recréer des nœuds
Après avoir reconfiguré le serveur d'API pour qu'il assure la diffusion sur une nouvelle adresse IP, GKE met automatiquement à jour vos nœuds afin qu'ils utilisent la nouvelle adresse IP et les nouveaux identifiants, s'il existe une disponibilité pour maintenance. GKE met tous vos nœuds à niveau vers la version de GKE déjà exécutée par les nœuds, ce qui recrée les nœuds. Pour en savoir plus, consultez la page Mises à niveau des pools de nœuds.
Par défaut, GKE effectue automatiquement les rotations des identifiants sept jours après le démarrage de l'opération. Si un intervalle de maintenance actif ou une exclusion dans votre cluster empêche GKE de recréer certains nœuds pendant cette période de sept jours, la rotation des identifiants échoue initialement. Toutefois, GKE continue de tenter de recréer les nœuds et de terminer la rotation jusqu'à ce que la disponibilité de la maintenance lui permette de continuer. Lors d'événements majeurs tels que Google Cloud Next, GKE peut également suspendre les recréations automatiques des nœuds afin d'éviter toute interruption.
Si vous utilisez des exclusions ou des intervalles de maintenance susceptibles d'entraîner une échec de la rotation, mettez à niveau manuellement votre cluster pour forcer la recréation des nœuds :
gcloud container clusters upgrade CLUSTER_NAME \ --location=LOCATION \ --cluster-version=VERSION
Remplacez
VERSION
par la même version de GKE que celle utilisée par le cluster.Pour en savoir plus, consultez la page Modifications manuelles qui respectent les règles de maintenance GKE.
Vérifier la progression de la recréation du pool de nœuds
Pour surveiller l'opération de rotation, exécutez la commande suivante :
gcloud container operations list \ --filter="operationType=UPGRADE_NODES AND status=RUNNING" \ --format="value(name)"
Cette commande renvoie l'ID d'opération de la mise à niveau des nœuds.
Pour interroger l'opération, transmettez l'ID d'opération à la commande suivante :
gcloud container operations wait OPERATION_ID
Les pools de nœuds sont recréés un par un, et chacun possède sa propre opération. Si vous avez plusieurs pools de nœuds, suivez ces instructions pour interroger chaque opération.
Mettre à jour les clients API
Après avoir démarré la rotation des identifiants, vous devez mettre à jour tous les clients API en dehors du cluster (tels que kubectl
sur les ordinateurs de développement), de sorte qu'ils utilisent les nouveaux identifiants et pointent vers la nouvelle adresse IP du plan de contrôle.
Pour mettre à jour vos clients API, exécutez la commande suivante pour chaque client :
gcloud container clusters get-credentials CLUSTER_NAME \
--location LOCATION
Mettre à jour les identifiants du compte de service Kubernetes
Si vous utilisez des identifiants statiques pour ServiceAccounts dans votre cluster, passez aux identifiants éphémères. Si vous terminez la rotation, les identifiants du compte de service existants ne seront plus valides. Si vous ne souhaitez pas utiliser d'identifiants éphémères, veillez à recréer vos identifiants statiques pour tous les comptes de service du cluster une fois la rotation terminée.
Mettre à jour les adresses IP codées en dur et les règles de pare-feu
Si vous avez codé en dur l'adresse IP du plan de contrôle dans votre environnement, ou si vous avez des règles de pare-feu qui ciblent l'adresse IP du plan de contrôle, mettez à jour les adresses vers la nouvelle adresse IP. Si vous terminez la rotation sans mettre à jour les adresses IP dans les applications et les règles de pare-feu, ces ressources peuvent subir des interruptions lorsque GKE cesse de diffuser sur l'adresse IP précédente du plan de contrôle.
Achever la rotation
Après avoir mis à jour les clients API en dehors du cluster, terminez la rotation pour configurer le plan de contrôle afin qu'il diffuse le trafic uniquement avec les nouveaux identifiants et via la nouvelle adresse IP :
gcloud container clusters update CLUSTER_NAME \
--location=LOCATION \
--complete-credential-rotation
Si la rotation des identifiants échoue et renvoie un message d'erreur semblable à celui-ci, consultez Erreur 400 : le pool de nœuds nécessite la recréation :
ERROR: (gcloud.container.clusters.update) ResponseError: code=400, message=Node pool "test-pool-1" requires recreation.
GKE respecte la disponibilité de maintenance lors de la rotation automatique. Toutefois, il peut ignorer cette disponibilité dans les 30 jours suivant l'expiration pour éviter que le cluster ne devienne irrécupérable. Si la rotation échoue initialement et qu'elle a commencé il y a au moins sept jours, GKE tente de la terminer jusqu'à la date d'expiration des identifiants, après quoi le cluster ne peut plus être récupéré.
Étapes suivantes
- Obtenez plus d'informations sur la protection des métadonnées de cluster.
- Apprenez-en plus sur l'objet Secret de Kubernetes.
- Apprenez-en plus sur la rotation de votre adresse IP.