Anthos-Cluster auf VMware ist jetzt Google Distributed Cloud (nur Software) für VMware. Weitere Informationen finden Sie in der Produktübersicht.

Diese Seite wurde von der Cloud Translation API übersetzt.

Zertifizierungsstellen für Nutzercluster rotieren

Google Distributed Cloud verwendet 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 (CAs) und verwendet CA-Zertifikate, um zusätzliche untergeordnete Zertifikate für Systemkomponenten auszustellen. Der Administratorcluster verwaltet die Verteilung der öffentlichen CA-Zertifikate und der untergeordneten Zertifikatschlüsselpaare an Systemkomponenten, um deren sichere Kommunikation einzurichten.

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 jedoch, 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 ist selbst signiert.

Es kann auch sein, dass Sie eine Organisationszertifizierungsstelle verwenden, um das mit der Option authentication.sni konfigurierte Zertifikat zu signieren. 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

Die CA-Zertifikatsrotation ist auf die zuvor genannten etcd-, Cluster- und Front-Proxy-CAs beschränkt.
Die CA-Zertifikatsrotation ist auf Zertifikate beschränkt, die automatisch von Google Distributed Cloud ausgestellt werden. Zertifikate, die manuell von einem Administrator ausgestellt wurden, werden nicht aktualisiert, auch wenn sie von den System-CAs signiert sind.
Bei einer Zertifizierungsstellenrotation werden der API-Server, andere Prozesse auf der Steuerungsebene und jeder Knoten im Cluster mehrmals neu gestartet. Jede Phase der CA-Rotation verläuft ähnlich wie ein Clusterupgrade. Während der Nutzercluster während einer Zertifizierungsstellenrotation betriebsbereit bleibt, können Sie davon ausgehen, dass Arbeitslasten neu gestartet und neu geplant werden. Außerdem sollten Sie mit kurzen Ausfallzeiten der Steuerungsebene rechnen, wenn Ihr Nutzercluster keine Steuerungsebene mit Hochverfügbarkeit hat.
Sie müssen nach einer Zertifizierungsstellenrotation die kubeconfig-Datei des Nutzerclusters und die Konfigurationsdateien für die Authentifizierung aktualisieren. Das liegt daran, dass das alte Clusterzertifikat widerrufen wurde und die Anmeldedaten in der kubeconfig-Datei nicht mehr funktionieren.
Nachdem eine CA-Rotation gestartet wurde, kann sie weder pausiert noch rückgängig gemacht werden.
Eine CA-Rotation kann je nach Größe des Nutzerclusters einige Zeit in Anspruch nehmen.

CA-Rotation durchführen

Starten Sie die Rotation:

gkectl update credentials certificate-authorities rotate \
    --config USER_CLUSTER_CONFIG \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Ersetzen Sie Folgendes:

USER_CLUSTER_CONFIGE: Pfad der Konfigurationsdatei des Nutzerclusters
ADMIN_CLUSTER_KUBECONFIG: der Pfad der kubeconfig-Datei des Administratorclusters

Wenn die CA-Rotation erfolgreich gestartet wird, wird eine Meldung wie diese 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 Zertifizierungsstellenrotation durchgeführt wird, wird eine Fehlermeldung wie diese angezeigt:

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

Sehen Sie sich den Status der Rotation an:
```
gkectl update credentials certificate-authorities status \
    --config USER_CLUSTER_CONFIG \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG
```
Der vorherige Befehl gibt den CAVersion aus. Dies ist eine Ganzzahl, die das System automatisch inkrementiert, um die vor und nach der Rotation verwendeten Zertifizierungsstellen zu unterscheiden. Der Befehl meldet auch einen Status (True oder False), der angibt, ob die CA-Rotation abgeschlossen ist, sowie eine Meldung, die beschreibt, welche CAVersion derzeit von den einzelnen Komponenten des Systems verwendet wird.

Wenn die Zertifizierungsstellenrotation bereits abgeschlossen ist, wird eine Meldung wie diese 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 Zertifizierungsstellenrotation noch läuft, wird eine Meldung wie diese 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 müssen Sie eine neue kubeconfig-Datei des Nutzerclusters aus dem Administratorcluster abrufen. Das liegt daran, dass durch die CA-Rotation die Zertifizierungsstelle widerrufen wird, auf der die alte kubeconfig-Datei basierte.

Rufen Sie eine neue kubeconfig-Datei ab:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secret admin \
    -n USER_CLUSTER_NAME -o jsonpath='{.data.admin\.conf}' \
    | base64 --decode > USER_CLUSTER_NAME-kubeconfig

Verteilen Sie die neue kubeconfig-Datei an alle, die eine kubectl-Datei für die Interaktion mit dem Cluster verwenden.

Konfigurationsdateien für die Authentifizierung aktualisieren

Nach Abschluss der Zertifizierungsstellenrotation 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 von Zertifikaten der Steuerungsebene

Ohne Rotation laufen sowohl die Nutzercluster-CAs als auch die Zertifikate der Steuerungsebene fünf Jahre nach dem Datum der Clustererstellung ab. Die Zertifikate des Nutzerclusters werden automatisch innerhalb von zehn Stunden nach jedem Nutzerclusterupgrade rotiert. Die Zertifizierungsstellen werden jedoch nicht automatisch rotiert. Dies bedeutet, dass zusätzlich zu den regulären Versionsupgrades mindestens alle fünf Jahre eine CA-Rotation durchgeführt werden muss.

Um zu verhindern, dass ein Nutzercluster nicht mehr verfügbar ist, werden Zertifikate der Steuerungsebene innerhalb von zehn Stunden nach einem Nutzerclusterupgrade rotiert. In diesem Fall wird im CA-Rotationsstatus des Nutzerclusters eine Meldung angezeigt.

So rufen Sie die letzte Version auf, auf die ein Nutzercluster aktualisiert wurde, als Zertifikate der Steuerungsebene rotiert wurden:

gkectl update credentials certificate-authorities status \
--config USER_CLUSTER_CONFIG \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG

Die Informationen werden innerhalb von zehn Stunden nach einem Upgrade am Ende des Felds message angezeigt. Beispiel:

Last Leaf Certificates Rotation Version: 1.16.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 von gkectl diagnose in einem Nutzercluster finden Sie unter Clusterprobleme diagnostizieren. Wenn bei einer CA-Rotation Probleme auftreten, wenden Sie sich an den Google-Support und stellen Sie die gkectl diagnose-Ausgabe bereit.