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 (CA) pour chaque cluster d'utilisateur et utilise des certificats CA pour émettre des certificats d'entité finale supplémentaires pour les composants système. Le cluster d'administrateur gère la distribution des certificats CA publics et des paires de clés de certificats d'entité finale aux composants 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.

En outre, vous utilisez peut-être 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, au cluster et au proxy frontal mentionnés 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 redémarre le serveur d'API, les autres processus du plan de contrôle et chaque nœud du cluster à plusieurs reprises. 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, vous devez vous attendre à ce que les charges de travail soient redémarrées et replanifiées. Vous devez également vous attendre à de brèves périodes de temps d'arrêt 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 qu'une rotation d'autorité de certification a démarré, vous ne pouvez pas la mettre en veille ni effectuer un rollback.
Une rotation des autorités de certification peut prendre un temps considérable, 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_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 des autorités 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 des 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 le 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 des autorités 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 des autorités 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, vous devez obtenir un nouveau fichier kubeconfig de cluster d'utilisateur à partir du cluster d'administrateur. En effet, la rotation des autorités de certification révoque l'autorité de certification sur laquelle était basé l'ancien fichier kubeconfig.

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

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. 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, mais pas les autorités de certification. 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 10 heures suivant une mise à niveau du cluster d'utilisateur. Dans ce cas, 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:

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 la rotation des autorités de certification, contactez l'assistance Google et fournissez le résultat gkectl diagnose.