Vous pouvez effectuer une rotation des autorités de certification (CA) du système principal dans un cluster d'utilisateur Google Distributed Cloud pour les renouveler avant leur expiration. Lors d'une rotation, le cluster d'administrateur remplace les autorités de certification du cluster d'utilisateur par des autorités de certification nouvellement générées, puis distribue les certificats et les paires de clés que les nouvelles autorités de certification émettent aux composants système. La rotation est incrémentielle, de sorte que les composants système puissent continuer à communiquer, mais les charges de travail et les nœuds sont redémarrés. Pour effectuer une rotation des autorités de certification dans un cluster d'administrateur, consultez Effectuer une rotation des certificats CA de cluster d'administrateur.
À propos des autorités de certification de cluster d'utilisateur
Le cluster d'administrateur gère trois autorités de certification système autosignées pour chaque cluster d'utilisateur. Chaque autorité de certification émet des certificats, appelés certificats d'entité finale, pour les composants système individuels, qui les utilisent pour authentifier et chiffrer leurs connexions :
- L'autorité de certification etcd sécurise la communication du serveur d'API vers les instances dupliquées etcd, ainsi que le trafic entre les instances dupliquées etcd.
- L'autorité de certification du cluster sécurise la communication entre le serveur d'API et tous les clients internes de l'API Kubernetes (kubelets, contrôleurs, programmeurs).
- L'autorité de certification de proxy frontal sécurise la communication avec des API agrégées.
Vous pouvez également utiliser une autorité de certification d'organisation pour signer le certificat configuré par l'option authentication.sni, qui diffuse l'API Kubernetes aux clients en dehors du cluster. Vous gérez cette autorité de certification et générez le certificat SNI manuellement. La rotation des autorités de certification du cluster d'utilisateur n'affecte pas l'autorité de certification de l'organisation ni le certificat SNI.
Limites
Notez la limitation suivante concernant les clusters avancés :
- Version 1.31 : la rotation des autorités de certification n'est pas compatible avec les clusters avancés.
- Version 1.32 et ultérieures : la rotation des autorités de certification est compatible avec les clusters avancés, mais il existe quelques différences mineures, indiquées le cas échéant dans ce document.
La rotation des certificats CA est limitée aux autorités de certification etcd, cluster et proxy frontal mentionnées précédemment.
La rotation des certificats CA est limitée aux certificats émis automatiquement par Google Distributed Cloud. Elle ne met pas à jour les certificats émis manuellement par un administrateur, même s'ils sont signés par les autorités de certification du système.
Une rotation des autorités de certification doit redémarrer le serveur d'API, d'autres processus du plan de contrôle, ainsi que chaque nœud du cluster plusieurs fois. Chaque étape d'une rotation des autorités de certification se déroule de la même manière qu'une mise à niveau de cluster. Bien que le cluster d'utilisateur reste opérationnel pendant la rotation des autorités de certification, attendez-vous à ce que les charges de travail soient redémarrées et replanifiées. Vous pouvez également vous attendre à de courtes périodes d'interruption du plan de contrôle si votre cluster d'utilisateur ne dispose pas d'un plan de contrôle à haute disponibilité.
Vous devez mettre à jour le fichier kubeconfig du cluster d'utilisateur et les fichiers de configuration d'authentification après une rotation des autorités de certification. Cela est dû au fait que l'ancien certificat du cluster a été révoqué et que les identifiants du fichier kubeconfig ne fonctionneront plus.
Une fois qu'une rotation des autorités de certification est démarrée, elle ne peut pas être suspendue ni annulée.
Une rotation des autorités de certification peut prendre un certain temps, en fonction de la taille du cluster d'utilisateur.
Effectuer une rotation des autorités de certification
Lancez la rotation :
gkectl update credentials certificate-authorities rotate \ --config USER_CLUSTER_CONFIG \ --kubeconfig ADMIN_CLUSTER_KUBECONFIGRemplacez les éléments suivants :
USER_CLUSTER_CONFIG : chemin d'accès au fichier de configuration du cluster d'utilisateur
ADMIN_CLUSTER_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur
Le comportement de la commande varie selon que le cluster avancé est activé ou non :
Désactivée
Si le cluster avancé n'est pas activé sur le cluster, la commande est asynchrone, démarre la rotation des autorités de certification, puis se ferme. Vous n'avez pas besoin de surveiller le résultat de la commande pendant toute la durée de la rotation des autorités de certification. Vous pouvez plutôt vérifier régulièrement la progression en exécutant la commande gkectl update credentials certificate-authorities status.
Si la rotation de l'autorité de certification démarre correctement, un message semblable à celui-ci s'affiche :
successfully started the CA rotation with CAVersion 2, use gkectl update credentials certificate-authorities status command to view the current state of CA rotation
Si une rotation de l'autorité de certification est déjà en cours, un message d'erreur semblable à celui-ci s'affiche :
Exit with error: admission webhook "vonpremusercluster.onprem.cluster.gke.io" denied the request: requests must not modify CAVersion when cluster is not ready: ready condition is not true: ClusterCreateOrUpdate: Creating or updating user cluster control plane workloads
Pour afficher l'état de la rotation :
gkectl update credentials certificate-authorities status \
--config USER_CLUSTER_CONFIG \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG
La commande ci-dessus indique la valeur CAVersion, qui est un entier que le système incrémente automatiquement pour différencier les autorités de certification utilisées avant et après une rotation. La commande signale également un état (True ou False) qui indique si la rotation de l'autorité de certification est terminée, ainsi qu'un message décrivant le CAVersion actuellement utilisé par chaque composant du système.
Si la rotation de l'autorité de certification est déjà terminée, un message de ce type s'affiche :
State of CARotation with CAVersion 2 is - status: True, reason: CARotationCompleted, message: Control plane has CA bundle [2], certs from CA 2, CA 2 is CSR signer. Data plane has CA bundle [2], CA 2 was CSR signer at last restart.
Si la rotation de l'autorité de certification est toujours en cours, un message semblable à celui-ci s'affiche :
State of CARotation with CAVersion 2 is - status: False, reason: CARotationProgressed, message: Control plane has CA bundle [1 2], certs from CA 2, CA 1 is CSR signer. Data plane has CA bundle [1 2], CA 1 was CSR signer at last restart.
Mettre à jour les identifiants du cluster d'utilisateur
Sur les clusters pour lesquels le cluster avancé n'est pas activé, vous devez obtenir un nouveau fichier kubeconfig du cluster d'utilisateur à partir du cluster d'administrateur. En effet, la rotation des autorités de certification révoque l'ancienne autorité de certification sur laquelle l'ancien fichier kubeconfig était basé.
Obtenez un nouveau fichier kubeconfig :
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secret admin \
-n USER_CLUSTER_NAME -o jsonpath='{.data.admin\.conf}' \
| base64 --decode > USER_CLUSTER_NAME-kubeconfig
Activé
Si le cluster avancé est activé, la commande gkectl update credentials
certificate-authorities rotate est synchrone. La commande génère des messages d'état au poste de travail administrateur à mesure que la rotation des CA progresse.
Une fois la rotation de l'autorité de certification terminée, la commande se ferme et un nouveau fichier kubeconfig est automatiquement généré. Le résultat de la commande fournit le nom du nouveau fichier kubeconfig et ressemble à ce qui suit :
Beginning CA rotation with generated CA ... Successfully rotated CA for user cluster "USER_CLUSTER_NAME". The kubeconfig file "/home/ubuntu"/USER_CLUSTER_NAME-kubeconfig" has been updated.
Le nouveau fichier kubeconfig se trouve dans le même répertoire que le fichier kubeconfig du cluster d'administrateur que vous avez spécifié dans la commande. Le nom du nouveau fichier kubeconfig est USER_CLUSTER_NAME-kubeconfig.
Distribuer le nouveau fichier kubeconfig
Distribuez le nouveau fichier kubeconfig à toutes les personnes qui l'utilisent pour interagir avec le cluster.
Mettre à jour les fichiers de configuration d'authentification
Une fois la rotation des autorités de certification terminée, les fichiers de configuration d'authentification doivent être mis à jour et redistribués. Pour en savoir plus, consultez Gérer l'identité des utilisateurs.
Rotation des certificats du plan de contrôle
Sans rotation, les autorités de certification du cluster d'utilisateur et les certificats du plan de contrôle expirent tous deux dix ans à compter de la date de création du cluster (pour les versions antérieures à la version 1.36.100, ces certificats expirent après cinq ans). Les certificats du plan de contrôle du cluster d'utilisateur sont automatiquement alternés dans les dix heures suivant la mise à niveau de chaque cluster d'utilisateur, mais les autorités de certification ne le sont pas automatiquement. En d'autres termes, une rotation des autorités de certification doit être effectuée au moins une fois tous les dix ans (cinq ans pour les versions antérieures à la version 1.36.100), en plus des mises à niveau de version habituelles.
Pour éviter l'indisponibilité d'un cluster d'utilisateur, les certificats du plan de contrôle sont alternés dans les dix heures suivant une mise à niveau du cluster d'utilisateur. Lorsque cela se produit, un message s'affiche dans l'état de rotation de l'autorité de certification du cluster d'utilisateur.
Pour afficher la dernière version vers laquelle un cluster d'utilisateur a été mis à niveau lors de la rotation des certificats du plan de contrôle, procédez comme suit :
gkectl update credentials certificate-authorities status \ --config USER_CLUSTER_CONFIG \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG
Les informations apparaissent à la fin du champ message dans les dix heures suivant une mise à niveau. Exemple :
Last Leaf Certificates Rotation Version: 1.16.0-gke.0.
Résoudre les problèmes liés à la rotation des autorités de certification
La commande gkectl diagnose permet de vérifier l'état attendu d'une rotation des autorités de certification terminée par rapport à un cluster d'utilisateur. Pour savoir comment exécuter gkectl diagnose sur un cluster d'utilisateur, consultez la page Diagnostiquer les problèmes de cluster.
Si vous rencontrez des problèmes avec une rotation des autorités de certification, contactez l'assistance Google et fournissez la sortie gkectl diagnose.