Appliquer une rotation des certificats CA de cluster d'administrateur
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
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.
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:
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:
Désactivé
La commande gkectl update credentials certificate-authorities rotate démarre et effectue la première moitié de la rotation. La commande est ensuite mise en pause pour vous permettre d'exécuter la commande suivante afin de mettre à jour le fichier kubeconfig.
Mettre à jour le fichier kubeconfig
Une fois la commande gkectl update credentials certificate-authorities rotate en pause, mettez à jour le fichier kubeconfig du cluster d'administrateur. Un nouveau certificat client et un nouveau certificat CA sont alors placés dans le fichier kubeconfig. L'ancien certificat client est supprimé du fichier kubeconfig et l'ancien certificat CA reste dans le fichier kubeconfig.
Exécutez la commande suivante pour appliquer la deuxième moitié de la procédure. La commande ne sera exécutée que lorsque gkectl aura vérifié que le fichier kubeconfig mis à jour se trouve bien dans le répertoire actuel.
Une fois la rotation terminée, la commande rapporte la version actuelle de l'autorité de certification.
Mettre à jour le fichier kubeconfig une nouvelle fois
Une fois la deuxième moitié de la rotation terminée, mettez à nouveau le fichier kubeconfig à jour. L'ancien certificat CA est alors supprimé du fichier kubeconfig.
Si le cluster avancé est activé, la commande gkectl update credentials
certificate-authorities rotate est synchrone. La commande génère des messages d'état au poste de travail administrateur à mesure que la rotation de l'autorité de certification progresse.
Une fois la rotation de l'autorité de certification effectuée, la commande se ferme et un nouveau fichier kubeconfig est généré automatiquement. Le fichier kubeconfig que vous avez spécifié dans la commande est remplacé par un nouveau. Le résultat de la commande ressemble à ceci:
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.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/04 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/09/04 (UTC)."],[],[],null,["Google Distributed Cloud use certificates and private keys to authenticate\ncommunication between Kubernetes system components in an admin cluster. When you\ncreate an admin cluster, new certificate authority (CA) certificates are created,\nand these root certificates are used to issue additional leaf certificates for\nKubernetes system components.\n\nThis guide applies only to rotation of admin cluster CA certificates. For\nuser clusters, see\n[Rotating user cluster CA certificates](/kubernetes-engine/distributed-cloud/vmware/docs/how-to/ca-rotation).\n\nThere are three CA certificates used by the Kubernetes system in an admin\ncluster:\n\n- The etcd CA certificate secures communication from the Kubernetes API server\n to the etcd replicas and also communication between etcd replicas. This\n certificate is self-signed.\n\n- The cluster CA certificate secures communication between the Kubernetes API\n server and all internal Kubernetes API clients, for example, the kubelet, the\n controller manager, and the scheduler. This certificate is self-signed.\n\n- The front-proxy CA certificate secures communication with\n [aggregated APIs](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/).\n This certificate is self-signed.\n\nYou can use `gkectl` to trigger a certificate rotation. During a rotation,\n`gkectl` replaces the core system CA certificates for the\nadmin cluster with newly generated certificates. Then it distributes the new\nCA certificates, leaf certificates, and private keys to admin cluster system\ncomponents. The rotation happens incrementally, so that system components can\ncontinue to communicate during the rotation. Note, however, that workloads and\nnodes are restarted during the rotation.\n\nWithout rotation, CA certificates and control-plane certificates will expire\nfive years from the date the cluster was created. The control plane certificates\nare automatically rotated during a cluster upgrade, but the CAs are\nnot automatically rotated. This means a CA rotation must be performed at least\nonce every five years, in addition to regular version upgrades.\n| **Warning:** A CA certificate rotation revokes the old CA certificates at the end of the operation. This invalidates kubeconfig files that were based on an old certificate. Consequently, the credentials in the kubeconfig file stop working after a CA certificate rotation. This guide includes instructions on how to update your kubeconfig file. The same issue applies to authentication configuration files.\n\nLimitations\n\n- Note the following limitation with advanced clusters:\n\n - Version 1.31: CA rotation isn't supported on [advanced clusters](/kubernetes-engine/distributed-cloud/vmware/docs/how-to/admin-cluster-configuration-file-latest#enable-advanced-cluster-field).\n - Version 1.32 and higher: CA rotation is supported on advanced clusters but there are some minor differences noted where applicable in this document.\n- CA certificate rotation limited to the etcd, cluster, and front-proxy\n certificates mentioned previously.\n\n- CA certificate rotation is limited to certificates issued automatically by\n Google Distributed Cloud. It does not update certificates issued manually by an\n administrator, even if those certificates are signed by the system CAs.\n\n- CA certificate rotation restarts the Kubernetes API server, other\n control-plane processes, and each node in the admin cluster multiple times.\n Each stage of a rotation progresses similarly to a cluster upgrade. While the\n admin cluster and the user clusters managed by the admin cluster do remain\n operational during a certificate rotation, you should expect that workloads\n in the admin cluster will be restarted and rescheduled. You should also expect\n brief periods of downtime for the admin cluster control plane and user cluster\n control plane.\n\n- You must update the admin cluster kubeconfig file in the middle of a\n certificate rotation and again after the rotation completes. This is because\n the old cluster certificate is revoked, and the credentials in the kubeconfig\n file will no longer work.\n\n- Once initiated, a CA certificate rotation cannot be rolled back.\n\n- A CA certificate rotation might take considerable time to complete, depending\n on the size of the cluster.\n\n- The certificate rotation process can be resumed by re-running the same\n command if it is interrupted. However, you must ensure that there is only one\n rotation command running at a time.\n\nStart the rotation\n\nTo start the certificate rotation, run the following command:\n\n```\ngkectl update credentials certificate-authorities rotate \\\n --admin-cluster \\\n --config ADMIN_CLUSTER_CONFIG \\\n --kubeconfig ADMIN_CLUSTER_KUBECONFIG\n```\n\nReplace the following:\n\n- \u003cvar translate=\"no\"\u003eADMIN_CLUSTER_CONFIG\u003c/var\u003e: the path of the admin cluster configuration\n file\n\n- \u003cvar translate=\"no\"\u003eADMIN_CLUSTER_KUBECONFIG\u003c/var\u003e: the path of the admin cluster kubeconfig\n file\n\nThe behavior of the command differs depending on whether advanced cluster\nis enabled: \n\nNot enabled\n\nThe `gkectl update credentials certificate-authorities rotate` command starts\nand performs the first half of the rotation. The command then pauses to let\nyou run the next command to update the kubeconfig file.\n\nUpdate the kubeconfig file\n\nWhen the `gkectl update credentials certificate-authorities rotate` command\npauses, update the kubeconfig file for the admin cluster. This places a new\nclient certificate and a new CA certificate in the kubeconfig file. The old\nclient certificate is removed from the kubeconfig file, and the old CA\ncertificate remains in the kubeconfig file.\n\n```\ngkectl update credentials certificate-authorities update-kubeconfig \\\n --admin-cluster \\\n --config ADMIN_CLUSTER_CONFIG \\\n --kubeconfig ADMIN_CLUSTER_KUBECONFIG\n```\n\nContinue the rotation\n\nRun the following command to perform the second half of the procedure. The\ncommand doesn't proceed until `gkectl` verifies that the updated kubeconfig\nfile is in the current directory.\n\n```\ngkectl update credentials certificate-authorities rotate \\\n --admin-cluster \\\n --complete \\\n --config ADMIN_CLUSTER_CONFIG \\\n --kubeconfig ADMIN_CLUSTER_KUBECONFIG\n```\n\nWhen the rotation is complete, it reports the current CA version.\n\nUpdate the kubeconfig file again\n\nAfter the second half of the rotation completes, update the kubeconfig file\nagain. This removes the old CA certificate from the kubeconfig file.\n\n```\ngkectl update credentials certificate-authorities update-kubeconfig \\\n --admin-cluster \\\n --config ADMIN_CLUSTER_CONFIG \\\n --kubeconfig ADMIN_CLUSTER_KUBECONFIG\n```\n\nEnabled\n\nIf advanced cluster is enabled, the `gkectl update credentials\ncertificate-authorities rotate` command is synchronous. The command outputs\nstatus messages to the admin workstation as the CA rotation progresses.\n\nAfter the CA is rotated successfully, the command exits and a new kubeconfig\nfile is automatically generated. The kubeconfig file that you specified in the\ncommand is replaced with a new one. The command output is similar to the\nfollowing:\n\n```\nBeginning CA rotation with generated CA\n...\nSuccessfully rotated CA for admin cluster. The kubeconfig file\n\"/home/ubuntu/kubeconfig\" has been updated.\nDone rotating certificate-authorities\n```\n\nDistribute the new kubeconfig file\n\nDistribute the new admin cluster kubeconfig file to all cluster users."]]
