Anthos Clusters on VMware (GKE On-Prem) utilise des certificats et des clés privées pour authentifier et chiffrer les connexions entre les composants système des clusters d'utilisateur. Le cluster d'administrateur crée un nouvel ensemble d'autorités de certification pour chaque cluster d'utilisateur et utilise ces certificats pour émettre des certificats "leaf" supplémentaires pour les composants du système. Le cluster d'administrateur gère la distribution des certificats CA publics et des paires de clés de certificat "leaf" aux composants système pour établir leur communication sécurisée.
La fonctionnalité de rotation des autorités de certification du cluster d'utilisateur vous permet de déclencher une rotation des certificats système principaux dans un cluster d'utilisateur. Lors d'une rotation, le cluster d'administrateur remplace les autorités de certification système principales du cluster d'utilisateur par des autorités de certification nouvellement générées, et distribue les nouveaux certificats des autorités de certification publiques et les paires de clés de certificat de feuille aux composants système du cluster d'utilisateur. La rotation se déroule de manière incrémentielle, de sorte que les composants système puissent continuer à communiquer pendant la rotation. Notez toutefois que les charges de travail et les nœuds seront redémarrés pendant la rotation.
Il existe trois autorités de certification système gérées par le cluster d'administrateur pour chaque cluster d'utilisateur :
- 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. Cette autorité de certification est autosignée.
- 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). Cette autorité de certification est autosignée.
- L'autorité de certification de proxy frontal sécurise la communication avec des API agrégées. Cette autorité de certification est autosignée.
Vous pouvez également utiliser une autorité de certification d'organisation pour signer le certificat configuré par l'option authentication.sni.
Cette autorité de certification et le certificat SNI sont utilisés pour diffuser l'API Kubernetes aux clients en dehors du cluster. Vous gérez cette autorité de certification et générez manuellement le certificat SNI. Ni cette autorité de certification ni le certificat SNI ne sont affectés par la fonctionnalité de rotation des autorités de certification du cluster d'utilisateur.
Limites
- La fonctionnalité de rotation des autorités de certification de cluster d'utilisateur est compatible avec Anthos clusters on VMware version 1.8 et ultérieures.
- La fonctionnalité de rotation des autorités de certification du cluster d'utilisateur est spécifiquement limitée aux autorités de certification etcd, cluster et proxy frontal mentionnées dans la présentation. Elle n'effectue pas une rotation de votre autorité de certification "org". La fonctionnalité de rotation des autorités de certification de cluster d'utilisateur est également limitée aux certificats émis automatiquement par Anthos clusters on VMware. 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 lorsque vous n'utilisez pas de configuration haute disponibilité.
- Les fichiers kubeconfig et de configuration d'authentification du cluster d'utilisateur pour la connexion aux clusters d'utilisateur doivent être mis à jour et redistribués manuellement après une rotation des autorités de certification. En effet, une rotation des autorités de certification révoque nécessairement l'ancienne autorité de certification. Ces identifiants ne seront donc plus authentifiés.
- Une fois lancée, la rotation des autorités de certification 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.
Comment effectuer une rotation des autorités de certification
Vous pouvez démarrer une rotation des autorités de certification et afficher l'état actuel de la rotation en exécutant les commandes gkectl ci-dessous.
Effectuer une rotation des certificats CA
Pour déclencher une rotation des autorités de certification, exécutez la commande suivante.
gkectl update credentials certificate-authorities rotate \ --config USER_CONFIG_FILE \ --kubeconfig ADMIN_KUBECONFIG_FILE
Où :
- USER_CONFIG_FILE est le chemin d'accès au fichier de configuration du cluster d'utilisateur pour lequel vous souhaitez effectuer la rotation des autorités de certification.
- ADMIN_KUBECONFIG_FILE est le chemin d'accès au fichier kubeconfig permettant de se connecter au cluster d'administrateur qui gère le cluster d'utilisateur.
Si la rotation de l'autorité de certification s'effectue correctement, un message semblable aux lignes suivantes 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
Afficher l'état de la rotation de l'autorité de certification
Pour afficher l'état d'une rotation des autorités de certification, exécutez la commande suivante. Cette commande renvoie la valeur de CAVersion, un entier que le système incrémente automatiquement pour différencier les autorités de certification utilisées avant et après chaque rotation des autorités de certification, un état (True ou False) qui indique si la rotation de l'autorité de certification est terminée, et un message décrivant la valeur de CAVersion qui est actuellement utilisée par chaque composant du système.
gkectl update credentials certificate-authorities status \ --config USER_CONFIG_FILE \ --kubeconfig ADMIN_KUBECONFIG_FILE
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
Une fois la rotation des autorités de certification terminée, un nouveau fichier kubeconfig du cluster d'utilisateur doit être téléchargé à partir du cluster d'administrateur pour remplacer l'ancien fichier kubeconfig qui a été précédemment utilisé pour la connexion aux clusters d'utilisateur. En effet, la rotation des autorités de certification révoque l'ancienne autorité de certification sur laquelle l'ancien fichier kubeconfig était basé. Exécutez la commande suivante une fois la rotation des autorités de certification terminée pour télécharger le nouveau fichier kubeconfig :
kubectl --kubeconfig ADMIN_KUBECONFIG_FILE get secret admin \
-n USER_CLUSTER_NAME -o jsonpath='{.data.admin\.conf}' \
| base64 --decode > USER_CLUSTER_NAME-kubeconfig
Si des fichiers kubeconfig supplémentaires ont été émis manuellement à d'autres utilisateurs du cluster, ils doivent également être mis à jour.
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. Suivez les instructions des liens suivants pour mettre à jour et redistribuer ces fichiers après la rotation des autorités de certification :
- S'authentifier avec OIDC
- Assurer l'authentification avec OIDC et AD FS
- Assurer l'authentification à l'aide d'OIDC et de Google
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 obtenir des instructions sur l'exécution du diagnostic gkectl sur un cluster d'utilisateur, consultez la section 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.