Sie können die Zertifikate der Zertifizierungsstelle (Certificate Authority, CA) in einem Google Distributed Cloud-Administratorcluster rotieren, um sie vor dem Ablauf zu verlängern. Diese CA-Zertifikate werden mit dem Administratorcluster erstellt und stellen die Zertifikate aus, die Kubernetes-Systemkomponenten zur Authentifizierung ihrer Kommunikation verwenden. Sie führen die Rotation mit gkectl aus und aktualisieren dann Ihre kubeconfig-Dateien, die durch die Rotation ungültig werden. Dieses Dokument gilt nur für Administratorcluster. Informationen zu Nutzerclustern finden Sie unter CA-Zertifikate von Nutzerclustern rotieren.
CA-Zertifikate von Administratorclustern
Im Kubernetes-System in einem Administratorcluster gibt es drei CA-Zertifikate:
Das etcd-CA-Zertifikat sichert die Kommunikation vom Kubernetes API-Server zu den etcd-Replikaten sowie die Kommunikation zwischen etcd-Replikaten. Dieses Zertifikat ist selbst signiert.
Das Cluster-CA-Zertifikat sichert die Kommunikation zwischen dem Kubernetes API-Server und allen internen Kubernetes API-Clients, z. B. dem Kubelet, dem Controller-Manager und dem Planer. Dieses Zertifikat ist selbst signiert.
Das Front-Proxy-CA-Zertifikat schützt die Kommunikation mit aggregierten APIs. Dieses Zertifikat ist selbst signiert.
Mit gkectl können Sie eine Zertifikatsrotation auslösen. Während einer Rotation ersetzt gkectl die Kernsystem-CA-Zertifikate für den Administratorcluster durch neu generierte Zertifikate. Anschließend werden die neuen CA-Zertifikate, untergeordneten Zertifikate und privaten Schlüssel auf die Systemkomponenten des Administratorclusters verteilt. Die Rotation erfolgt schrittweise, damit Systemkomponenten während der Rotation weiterhin kommunizieren können. Beachten Sie jedoch, dass Arbeitslasten und Knoten während der Rotation neu gestartet werden.
Ohne Rotation laufen CA-Zertifikate und Zertifikate der Steuerungsebene nach einer bestimmten Zeit ab dem Datum ab, an dem der Cluster erstellt wurde.
Die Ablaufdauer hängt vom Clustertyp und der Erstellungsversion ab:
- Erweiterte Cluster:
- Ablauf nach 10 Jahren
- Nicht erweiterte Cluster:
- Vor Version 1.5 erstellt: 10 Jahre Gültigkeit
- Erstellt zwischen den Versionen 1.5 und 1.16: 5 Jahre Gültigkeit
- Nach Version 1.16 erstellt: 30 Jahre Gültigkeit
Die Zertifikate der Steuerungsebene werden während eines Clusterupgrades automatisch rotiert. Die Zertifizierungsstellen werden jedoch nicht automatisch rotiert. Das bedeutet, dass zusätzlich zu den regulären Versionsupgrades vor dem Ablaufdatum der Zertifizierungsstelle eine Rotation der Zertifizierungsstelle durchgeführt werden muss.
Beschränkungen
Beachten Sie die folgende Einschränkung bei erweiterten Clustern:
- Version 1.31: Die CA-Rotation wird auf erweiterten Clustern nicht unterstützt.
- Version 1.32 und höher: Die CA-Rotation wird auf erweiterten Clustern unterstützt. Es gibt jedoch einige geringfügige Unterschiede, die in diesem Dokument gegebenenfalls aufgeführt sind.
Die Rotation von CA-Zertifikaten ist auf die zuvor genannten etcd-, Cluster- und Front-Proxy-Zertifikate beschränkt.
Die Rotation von CA-Zertifikaten ist auf Zertifikate beschränkt, die automatisch von Google Distributed Cloud ausgestellt werden. Zertifikate, die von einem Administrator manuell ausgestellt wurden, werden nicht aktualisiert, auch wenn sie von den System-CAs signiert sind.
Durch die Rotation des CA-Zertifikats werden der Kubernetes API-Server, andere Prozesse der Steuerungsebene und jeder Knoten im Administratorcluster mehrmals neu gestartet. Jede Phase der Rotation verläuft ähnlich wie ein Clusterupgrade. Auch wenn der Administratorcluster und die vom Administratorcluster verwalteten Nutzercluster während der Zertifikatsrotation funktionsfähig bleiben, sollten Sie davon ausgehen, dass die Arbeitslasten im Administratorcluster neu gestartet und neu geplant werden. Sie sollten auch kurze Ausfallzeiten für die Steuerungsebene des Administratorclusters und die Steuerungsebene der Nutzercluster erwarten.
Sie müssen die kubeconfig-Datei des Administratorclusters in der Mitte einer Zertifikatsrotation und noch einmal, nachdem die Rotation abgeschlossen ist, aktualisieren. Das liegt daran, dass das alte Clusterzertifikat widerrufen wird und die Anmeldedaten in der kubeconfig-Datei nicht mehr funktionieren.
Nach der Initiierung kann die Rotation eines CA-Zertifikats nicht mehr rückgängig gemacht werden.
Eine CA-Zertifikatsrotation kann je nach Größe des Clusters viel Zeit in Anspruch nehmen.
Wenn die Rotation des Zertifikats fortgesetzt werden soll, wenn sie unterbrochen wird, können Sie den gleichen Befehl noch einmal ausführen. Sie müssen jedoch darauf achten, dass jeweils nur ein Rotationsbefehl ausgeführt wird.
Rotation starten
Führen Sie den folgenden Befehl aus, um die Zertifikatsrotation zu starten:
gkectl update credentials certificate-authorities rotate \
--admin-cluster \
--config ADMIN_CLUSTER_CONFIG \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG
Ersetzen Sie Folgendes:
ADMIN_CLUSTER_CONFIG: der Pfad Ihrer Administratorcluster-Konfigurationsdatei.
ADMIN_CLUSTER_KUBECONFIG: der Pfad der kubeconfig-Datei des Administratorclusters
Das Verhalten des Befehls hängt davon ab, ob der erweiterte Cluster aktiviert ist:
Nicht aktiviert
Der Befehl gkectl update credentials certificate-authorities rotate startet und führt die erste Hälfte der Rotation aus. Der Befehl wird dann pausiert, damit Sie den nächsten Befehl zum Aktualisieren der kubeconfig-Datei ausführen können.
kubeconfig-Datei aktualisieren
Wenn der Befehl gkectl update credentials certificate-authorities rotate pausiert, aktualisieren Sie die kubeconfig-Datei für den Administratorcluster. Dadurch wird ein neues Clientzertifikat und ein neues CA-Zertifikat in der kubeconfig-Datei abgelegt. Das alte Clientzertifikat wird aus der kubeconfig-Datei entfernt und das alte CA-Zertifikat bleibt in der kubeconfig-Datei.
gkectl update credentials certificate-authorities update-kubeconfig \ --admin-cluster \ --config ADMIN_CLUSTER_CONFIG \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG
Rotation fortsetzen
Führen Sie den folgenden Befehl aus, um die zweite Hälfte des Verfahrens auszuführen. Der Befehl wird erst fortgesetzt, wenn gkectl kontrolliert hat, dass sich die aktualisierte kubeconfig-Datei im aktuellen Verzeichnis befindet.
gkectl update credentials certificate-authorities rotate \ --admin-cluster \ --complete \ --config ADMIN_CLUSTER_CONFIG \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG
Wenn die Rotation abgeschlossen ist, wird die aktuelle CA-Version gemeldet.
kubeconfig-Datei noch einmal aktualisieren
Aktualisieren Sie nach Abschluss der zweiten Hälfte der Rotation die kubeconfig-Datei noch einmal. Dadurch wird das alte CA-Zertifikat aus der kubeconfig-Datei entfernt.
gkectl update credentials certificate-authorities update-kubeconfig \ --admin-cluster \ --config ADMIN_CLUSTER_CONFIG \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG
Aktiviert
Wenn der erweiterte Cluster aktiviert ist, ist der Befehl gkectl update credentials
certificate-authorities rotate synchron. Der Befehl gibt Statusmeldungen an die Administrator-Workstation aus, während die CA-Rotation fortschreitet.
Nachdem die Zertifizierungsstelle erfolgreich rotiert wurde, wird der Befehl beendet und automatisch eine neue kubeconfig-Datei generiert. Die im Befehl angegebene kubeconfig-Datei wird durch eine neue ersetzt. Die Befehlsausgabe sieht etwa so aus:
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
Neue kubeconfig-Datei verteilen
Verteilen Sie die neue kubeconfig-Datei des Administratorclusters an alle Clusternutzer.