Appliquer une rotation des certificats CA de cluster d'administrateur

Google Distributed Cloud utilise des certificats et des clés privées pour authentifier la communication entre les composants système Kubernetes d'un cluster d'administrateur. Lorsque vous créez un cluster d'administrateur, de nouveaux certificats d'autorités de certification sont créés. Ces certificats racines sont ensuite utilisés pour émettre des certificats de serveur supplémentaires pour les composants système Kubernetes.

Ce guide ne s'applique qu'à la rotation des certificats CA du cluster d'administrateur. Pour les clusters d'utilisateur, consultez la section Appliquer une rotation des certificats CA de cluster d'utilisateur.

Dans un cluster d'administrateur, le système Kubernetes utilise trois certificats CA :

• Le certificat CA etcd sécurise la communication du serveur d'API Kubernetes vers les instances dupliquées etcd, ainsi que la communication entre les instances dupliquées etcd. Ce certificat est autosigné.

• Le certificat CA du cluster sécurise la communication entre le serveur d'API Kubernetes et tous les clients internes de l'API Kubernetes, par exemple le kubelet, le gestionnaire de contrôleurs et le programmeur. Ce certificat est autosigné.

• Le certificat CA de proxy frontal sécurise la communication avec des API agrégées. Ce certificat est autosigné.

Vous pouvez utiliser gkectl pour déclencher une rotation des certificats. Lors d'une rotation, gkectl remplace les certificats CA principaux du cluster d'administrateur par des nouveaux certificats. Ensuite, il distribue les nouveaux certificats CA, les certificats serveur et les clés privées aux composants système du cluster d'administrateur. 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.

Sans rotation, les certificats d'autorité de certification et les certificats du plan de contrôle expirent cinq ans à compter de la date de création du cluster. Les certificats de plan de contrôle sont automatiquement alternés lors d'une mise à niveau du cluster, 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.

Limites

• Notez la limitation suivante avec 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 versions ultérieures: la rotation des autorités de certification est compatible avec les clusters avancés, mais certaines différences mineures sont indiquées dans ce document, le cas échéant.

• Rotation des certificats CA limitée aux certificats etcd, de cluster et de 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.

• La rotation des certificats CA redémarre le serveur d'API Kubernetes, les autres processus de plan de contrôle et chacun des nœuds du cluster d'administrateur à plusieurs reprises. Chaque étape d'une rotation se déroule de la même manière qu'une mise à niveau de cluster. Bien que le cluster d'administrateur et les clusters d'utilisateur gérés par le cluster d'administrateur restent opérationnels lors d'une rotation de certificats, vous devez vous attendre à ce que les charges de travail du cluster d'administrateur soient redémarrées et replanifiées. Vous devez également vous attendre à de brèves interruptions pour le plan de contrôle du cluster d'administrateur et le plan de contrôle du cluster d'utilisateur.

• Vous devez mettre à jour le fichier kubeconfig du cluster d'administrateur pendant le processus de rotation de certificats, puis une nouvelle fois lorsque l'opération de rotation est terminée. 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 lancée, la rotation des certificats CA ne peut pas être annulée.

• La rotation des certificats CA peut prendre beaucoup de temps selon la taille du cluster.

• S'il a été interrompu, le processus de rotation des certificats peut être repris en exécutant à nouveau la même commande. Toutefois, vous devez vous assurer qu'une seule commande de rotation s'exécute à la fois.

Lancer la rotation

Pour lancer la rotation des certificats, exécutez la commande suivante:

gkectl update credentials certificate-authorities rotate \
    --admin-cluster \
    --config ADMIN_CLUSTER_CONFIG \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Remplacez les éléments suivants :

• ADMIN_CLUSTER_CONFIG : chemin d'accès au fichier de configuration du cluster d'administrateur

• ADMIN_CLUSTER_KUBECONFIG : chemin d'accès du fichier kubeconfig du cluster d'administrateur

Le comportement de la commande varie selon que le cluster avancé est activé ou non:

gkectl update credentials certificate-authorities update-kubeconfig \
  --admin-cluster \
  --config ADMIN_CLUSTER_CONFIG \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG

gkectl update credentials certificate-authorities rotate \
  --admin-cluster \
  --complete \
  --config ADMIN_CLUSTER_CONFIG \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG

gkectl update credentials certificate-authorities update-kubeconfig \
  --admin-cluster \
  --config ADMIN_CLUSTER_CONFIG \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Beginning CA rotation with generated CA
...
Successfully rotated CA for admin cluster. The kubeconfig file
"/home/ubuntu/kubeconfig" has been updated.
Done rotating certificate-authorities

Distribuer le nouveau fichier kubeconfig

Distribuez le nouveau fichier kubeconfig du cluster d'administrateur à tous les utilisateurs du cluster.