GKE sur Bare Metal utilise des certificats et des clés privées pour authentifier et chiffrer les connexions entre les composants système des clusters. L'autorité de certification du cluster gère ces certificats et clés. Lorsque vous exécutez la commande bmctl update credentials certificate-authorities rotate, GKE sur une solution Bare Metal effectue les actions suivantes:
Crée et importe de nouvelles autorités de certification de cluster pour l'autorité de certification de cluster, l'autorité de certification d'etcd et l'autorité de certification de proxy frontal dans l'espace de noms du cluster d'utilisateur au sein du cluster d'administrateur.
Les contrôleurs de cluster d'administrateur remplacent les autorités de certification du cluster d'utilisateur par celles nouvellement générées.
Les contrôleurs de cluster d'administrateur distribuent les nouveaux certificats d'autorité de certification publique et les paires de clés de certificat du serveur aux composants du système de cluster d'utilisateur.
Pour maintenir une communication sécurisée entre les clusters, faites tourner régulièrement l'autorité de certification de votre cluster d'utilisateur chaque fois qu'il existe une brèche de sécurité possible.
Avant de commencer
Avant d'effectuer la rotation de votre autorité de certification de votre cluster, planifiez en fonction des conditions et des impacts suivants :
Assurez-vous que les clusters d'administrateur et d'utilisateur sont à la version 1.9.0 ou ultérieure avant de démarrer la rotation de l'autorité de certification.
La rotation des autorités de certification est incrémentielle, ce qui permet aux composants système de communiquer pendant la rotation.
Le processus de rotation de l'autorité de certification redémarre le serveur d'API, les processus du plan de contrôle et les pods du cluster d'utilisateur.
Les charges de travail vont redémarrer et être replanifiées lors de la rotation des autorités de certification.
Pour les configurations de cluster à haute disponibilité, attendez-vous à de brèves périodes d'indisponibilité du plan de contrôle lors de la rotation de l'autorité de certification.
Les opérations de gestion des clusters ne sont pas autorisées lors de la rotation de l'autorité de certification.
La durée de la rotation des autorités de certification dépend de la taille de votre cluster. Par exemple, la rotation des autorités de certification peut prendre près de deux heures pour un cluster comportant un plan de contrôle et 50 nœuds de calcul.
Limites
La fonctionnalité de rotation des autorités de certification présente les limitations suivantes :
La rotation des autorités de certification ne met pas à jour les certificats émis manuellement par un administrateur, même si l'autorité de certification du cluster signe les certificats. Mettez à jour et redistribuez les certificats émis manuellement une fois la rotation de l'autorité de certification du cluster d'utilisateur terminée.
Une fois démarrée, la rotation de l'autorité de certification ne peut pas être suspendue ou annulée.
Démarrer une rotation des autorités de certification de cluster
Utilisez la commande suivante pour démarrer le processus de rotation de l'autorité de certification :
bmctl update credentials certificate-authorities rotate --cluster CLUSTER_NAME \
--kubeconfig KUBECONFIG
Remplacez les éléments suivants :
CLUSTER_NAME: nom du cluster pour lequel vous souhaitez alterner les autorités de certification.KUBECONFIG: chemin d'accès au fichier kubeconfig du cluster d'administrateur. Pour les clusters autogérés, ce fichier est le fichier kubeconfig du cluster.
La commande bmctl se ferme après la rotation de l'autorité de certification et la génération d'un nouveau fichier kubeconfig. Le chemin d'accès standard pour le fichier kubeconfig est bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-kubeconfig.
Résoudre les problèmes liés à la rotation des autorités de certification de cluster
La commande bmctl update credentials affiche la progression de la rotation de l'autorité de certification.
Le fichier update-credentials.log associé est enregistré dans le répertoire horodaté suivant :
bmctl-workspace/CLUSTER_NAME/log/update-credentials-TIMESTAMP