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 nouvel ensemble d'autorités de certification pour chaque cluster d'utilisateur et utilise ces certificats pour émettre des certificats d'entité finale 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 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 d'entité finale 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 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 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, 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_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 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

Affichez 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

Une fois la rotation des autorités de certification terminée, 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

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 tous deux cinq ans à compter de la date de création du cluster. 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 cinq ans, 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.