Clusters Anthos sur VMware devient Google Distributed Cloud (logiciel uniquement) pour VMware. Pour en savoir plus, consultez la présentation du produit.

Cette page a été traduite par l'API Cloud Translation.

Faire tourner les autorités de certification d'un cluster d'utilisateur

Google Distributed Cloud 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 ensemble d'autorités de certification pour chaque cluster d'utilisateur et utilise des certificats CA pour émettre des certificats feuilles 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 d'entité finale aux composants du système afin d'é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 sont redémarrés lors de 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 utilisez peut-être également 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 rotation des certificats CA est limitée aux autorités de certification etcd, aux clusters et aux proxys frontaux mentionnées précédemment.
La rotation des certificats CA est limitée aux certificats émis automatiquement par Google Distributed Cloud. Il ne met pas à jour les certificats émis manuellement par un administrateur, même s'ils sont signés par les autorités de certification système.
Une rotation d'autorités de certification redémarre le serveur d'API, les autres processus du plan de contrôle et 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 lors d'une rotation d'autorité de certification, attendez-vous à ce que les charges de travail soient redémarrées et replanifiées. Attendez-vous également à de brèves périodes d'indisponibilité 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 d'autorité de certification. En effet, l'ancien certificat de cluster est révoqué et les identifiants du fichier kubeconfig ne fonctionnent plus.
Une fois la rotation d'une autorité de certification démarrée, elle ne peut pas être suspendue ni annulée.
La rotation d'une autorité de certification peut prendre beaucoup de temps, selon la taille du cluster d'utilisateur.

Effectuer une rotation de l'autorité de certification

Lancez la rotation :

gkectl update credentials certificate-authorities rotate \
    --config USER_CLUSTER_CONFIG \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Remplacez les éléments suivants :

USER_CLUSTER_CONFIGE: 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

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 d'autorités 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

Affichez l'état de la rotation:
```
gkectl update credentials certificate-authorities status \
    --config USER_CLUSTER_CONFIG \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG
```
La commande précédente indique 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, et un message décrivant quel CAVersion est actuellement utilisé par chaque composant du système.

Si la rotation de l'autorité de certification est déjà terminée, un message semblable à celui-ci 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 de l'autorité de certification terminée, vous devez obtenir un nouveau fichier kubeconfig de cluster d'utilisateur auprès du cluster d'administrateur. En effet, la rotation des autorités de certification révoque l'autorité de certification sur laquelle l'ancien fichier kubeconfig était basé.

Récupérez 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

Distribuez le nouveau fichier kubeconfig à tous les utilisateurs qui l'utilisent pour interagir avec le cluster.

Mettre à jour les fichiers de configuration de l'authentification

Une fois la rotation de l'autorité 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 :

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 cinq ans à compter de la date de création du cluster. Les certificats du plan de contrôle du cluster d'utilisateur sont alternés automatiquement dans les 10 heures suivant chaque mise à niveau du cluster d'utilisateur, mais les autorités de certification ne font pas l'objet d'une rotation automatique. Cela signifie qu'une rotation des autorités de certification doit être effectuée au moins une fois tous les cinq ans, en plus des mises à niveau de version standards.

Pour éviter qu'un cluster d'utilisateur ne devienne indisponible, les certificats du plan de contrôle sont alternés dans les dix heures suivant la mise à niveau du cluster d'utilisateur. Lorsque cela se produit, un message s'affiche dans l'état de rotation des autorités 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 de plan de contrôle:

gkectl update credentials certificate-authorities status \
--config USER_CLUSTER_CONFIG \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG

Les informations apparaissent à la fin du champ message dans les 10 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 la rotation des autorités de certification, contactez l'assistance Google et indiquez la sortie gkectl diagnose.