Anthos-Cluster auf VMware (GKE On-Prem) verwenden Zertifikate und private Schlüssel, um Verbindungen zwischen Systemkomponenten in Nutzerclustern zu authentifizieren und zu verschlüsseln. Der Administratorcluster erstellt für jeden Nutzercluster einen neuen Satz von Zertifizierungsstellen (Certificate Authorities, CAs) und verwendet diese, um zusätzliche untergeordnete Zertifikate für Systemkomponenten auszustellen. Der Administratorcluster verwaltet die Verteilung der Schlüsselpaare für öffentliche CA-Zertifikate und für das untergeordnete Zertifikat an Systemkomponenten, um eine sichere Kommunikation für sie zu gewährleisten.
Mit dem CA-Rotations-Feature für Nutzercluster können Sie die Rotation der Kernsystemzertifikate in einem Nutzercluster auslösen. Bei einer Rotation ersetzt der Administratorcluster die Kernsystem-CAs für den Nutzercluster durch neu generierte CAs und verteilt die Schlüsselpaare für die neuen öffentlichen CA-Zertifikate und für das untergeordnete Zertifikat an Systemkomponenten des Nutzerclusters. Die Rotation erfolgt schrittweise, damit Systemkomponenten während der Rotation weiterhin kommunizieren können. Beachten Sie aber, dass Arbeitslasten und Knoten während der Rotation neu gestartet werden.
Für jeden Nutzercluster werden vom Administratorcluster drei System-CAs verwaltet:
- Die etcd-CA schützt die Kommunikation vom API-Server zu den etcd-Replikaten sowie den Traffic zwischen etcd-Replikaten. Diese Zertifizierungsstelle (CA) ist selbstsigniert.
- Die Clusterzertifizierungsstelle sichert die Kommunikation zwischen dem API-Server und allen internen Kubernetes API-Clients (Kubelets, Controller, Planer). Diese Zertifizierungsstelle (CA) ist selbstsigniert.
- Die Front-Proxy-CA schützt die Kommunikation mit aggregierten APIs. Diese Zertifizierungsstelle (CA) ist selbstsigniert.
Sie können zusätzlich mit einer Organisations-CA das Zertifikat zu signieren, das mit der Option authentication.sni konfiguriert wurde.
Diese CA und das SNI-Zertifikat werden zur Bereitstellung der Kubernetes API für Clients außerhalb des Clusters genutzt. Sie verwalten diese CA und generieren das SNI-Zertifikat manuell. Weder diese CA noch das SNI-Zertifikat sind vom CA-Rotations-Feature für Nutzercluster betroffen.
Beschränkungen
- Das CA-Rotations-Feature für Nutzercluster wird in Clustern von Anthos-Cluster auf VMware ab Version 1.8 unterstützt.
- Das CA-Rotations-Feature für Nutzercluster ist speziell auf die in der Übersicht genannten etcd-, Cluster- und Front-Proxy-CAs beschränkt. Die Organisations-CA wird damit nicht rotiert. Das CA-Rotations-Feature für Nutzercluster ist darüber hinaus auf Zertifikate beschränkt, die von Anthos-Cluster auf VMware automatisch ausgestellt wurden. Zertifikate, die von einem Administrator manuell ausgestellt wurden, werden nicht aktualisiert, auch wenn sie von den System-CAs signiert sind.
- Für eine CA-Rotation müssen der API-Server, andere Prozesse der Steuerungsebene und alle Knoten im Cluster mehrmals neu gestartet werden. Jede Phase der CA-Rotation verläuft ähnlich wie ein Clusterupgrade. Während der Nutzercluster während einer CA-Rotation weiter funktionsfähig ist, sollten Sie davon ausgehen, dass Arbeitslasten neu gestartet und neu geplant werden. Außerdem müssen Sie mit kurzen Ausfallzeiten für die Steuerungsebene rechnen, wenn Sie keine Hochverfügbarkeit konfiguriert haben.
- kubeconfig-Dateien für Nutzercluster und Konfigurationsdateien für die Authentifizierung zum Herstellen einer Verbindung zu Nutzerclustern müssen manuell aktualisiert und nach einer CA-Rotation neu verteilt werden. Dies liegt daran, dass die CA-Rotation notwendigerweise die alte CA widerruft, sodass die entsprechenden Anmeldedaten nicht mehr authentifiziert werden.
- Nach dem Start kann eine CA-Rotation nicht angehalten und auch kein Rollback ausgeführt werden.
- Eine CA-Rotation kann je nach Größe des Nutzerclusters sehr viel Zeit in Anspruch nehmen.
CA-Rotation ausführen
Mit den im Folgenden aufgeführten gkectl-Befehlen können Sie eine CA-Rotation starten und den aktuellen Status der Rotation aufrufen.
CA-Zertifikate rotieren
Um eine CA-Rotation auszulösen, führen Sie den folgenden Befehl aus:
gkectl update credentials certificate-authorities rotate \ --config USER_CONFIG_FILE \ --kubeconfig ADMIN_KUBECONFIG_FILE
Wobei:
- USER_CONFIG_FILE ist der Pfad zur Konfigurationsdatei des Nutzerclusters, für den CAs rotiert werden sollen.
- ADMIN_KUBECONFIG_FILE ist der Pfad zu der kubeconfig-Datei, mit der eine Verbindung zu dem Administratorcluster hergestellt werden soll, der den Nutzercluster verwaltet.
Wenn die CA-Rotation erfolgreich gestartet wurde, wird eine Meldung wie die folgende angezeigt:
successfully started the CA rotation with CAVersion 2, use gkectl update credentials certificate-authorities status command to view the current state of CA rotation
Wenn bereits eine CA-Rotation ausgeführt wird, erhalten Sie eine Fehlermeldung ähnlich der folgenden:
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
Status der CA-Rotation aufrufen
Um den Status einer CA-Rotation aufzurufen, führen Sie den unten aufgeführten Befehl aus. Mit diesem Befehl werden folgende Informationen ausgegeben: die CAVersion, eine Ganzzahl, die das System automatisch erhöht, um die vor und nach einer CA-Rotation verwendeten CAs zu unterscheiden, der Status (True oder False), der angibt, ob die CA-Rotation abgeschlossen ist, sowie eine Nachricht, die beschreibt, welche CAVersion derzeit von jeder Komponente des Systems verwendet wird.
gkectl update credentials certificate-authorities status \ --config USER_CONFIG_FILE \ --kubeconfig ADMIN_KUBECONFIG_FILE
Wenn die CA-Rotation bereits abgeschlossen ist, wird eine Meldung wie die folgende angezeigt:
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.
Wenn die CA-Rotation noch ausgeführt wird, wird eine Meldung wie die folgende angezeigt:
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.
Anmeldedaten des Nutzerclusters aktualisieren
Nach Abschluss der CA-Rotation muss eine neue kubeconfig-Datei des Nutzerclusters aus dem Administratorcluster heruntergeladen werden. Diese ersetzt die alte kubeconfig-Datei, die zuvor für das Herstellen einer Verbindung mit Nutzerclustern verwendet wurde. Dies ist erforderlich, da die CA-Rotation die alte CA widerruft, auf der die alte kubeconfig-Datei basiert. Führen Sie nach Abschluss der CA-Rotation den folgenden Befehl aus, um die neue kubeconfig-Datei herunterzuladen:
kubectl --kubeconfig ADMIN_KUBECONFIG_FILE get secret admin \
-n USER_CLUSTER_NAME -o jsonpath='{.data.admin\.conf}' \
| base64 --decode > USER_CLUSTER_NAME-kubeconfig
Wenn weitere kubeconfig-Dateien manuell an andere Nutzer des Clusters ausgegeben wurden, müssen auch diese aktualisiert werden.
Konfigurationsdateien für die Authentifizierung aktualisieren
Nach Abschluss der CA-Rotation müssen die Konfigurationsdateien für die Authentifizierung aktualisiert und neu verteilt werden. Folgen Sie den verlinkten Anleitungen, um diese Dateien nach der CA-Rotation zu aktualisieren und neu zu verteilen:
Rotation der Zertifikate der Steuerungsebene
Ohne Rotation laufen sowohl die Zertifizierungsstelle der Nutzercluster als auch die Zertifikate der Steuerungsebene in fünf Jahren ab dem Datum ab, an dem der Cluster erstellt wurde. Die Zertifikate der Nutzercluster werden innerhalb von zehn Stunden nach jedem Upgrade des Nutzerclusters automatisch rotiert. Die Zertifizierungsstellen werden jedoch nicht automatisch rotiert. Das bedeutet, dass zusätzlich zu den regulären Versionsupgrades mindestens alle fünf Jahre eine Rotation der Zertifizierungsstelle durchgeführt werden muss.
Damit ein Nutzercluster verfügbar bleibt, werden Zertifikate der Steuerungsebene innerhalb von zehn Stunden nach einem Nutzercluster-Upgrade rotiert. In diesem Fall wird eine Nachricht im Rotationsstatus der Zertifizierungsstelle des Nutzerclusters angezeigt.
So sehen Sie sich die letzte Version an, auf die ein Nutzercluster aktualisiert wurde, als Zertifikate der Steuerungsebene rotiert wurden:
gkectl update credentials certificate-authorities status \ --config USER_CONFIG_FILE \ --kubeconfig ADMIN_KUBECONFIG_FILE
Wenn ein Nutzercluster kürzlich auf Version 1.10 oder höher aktualisiert wurde, wird innerhalb von zehn Stunden eine Meldung am Ende von message angezeigt. Beispiel:
Last Leaf Certificates Rotation Version: 1.10.0-gke.0.
Fehlerbehebung bei CA-Rotationen
Der Befehl gkectl diagnose unterstützt die Prüfung des erwarteten Status einer abgeschlossenen CA-Rotation für einen Nutzercluster. Eine Anleitung zum Ausführen der gkectl-Diagnose für einen Nutzercluster finden Sie unter Clusterprobleme diagnostizieren.
Wenn bei der CA-Rotation Probleme auftreten, wenden Sie sich an den Google-Support und geben Sie dabei die Ausgabe von gkectl diagnose an.