Zertifizierungsstellen für Nutzercluster rotieren

Sie können die Kernsystem-Zertifizierungsstellen (CAs) in einem Google Distributed Cloud-Nutzercluster rotieren, um sie vor Ablauf zu erneuern. Während einer Rotation ersetzt der Administratorcluster die Zertifizierungsstellen des Nutzerclusters durch neu generierte Zertifizierungsstellen und verteilt dann die Zertifikate und Schlüsselpaare, die die neuen Zertifizierungsstellen ausstellen, an Systemkomponenten. Die Rotation erfolgt schrittweise, damit Systemkomponenten weiterhin kommunizieren können. Arbeitslasten und Knoten werden jedoch neu gestartet. Informationen zum Rotieren von Zertifizierungsstellen in einem Administratorcluster finden Sie unter CA-Zertifikate von Administratorclustern rotieren.

Nutzercluster-Zertifizierungsstellen

Der Administratorcluster verwaltet drei selbstsignierte System-CAs für jeden Nutzercluster. Jede Zertifizierungsstelle stellt Zertifikate, sogenannte untergeordnete Zertifikate, für einzelne Systemkomponenten aus, die diese zur Authentifizierung und Verschlüsselung ihrer Verbindungen verwenden:

  • Die etcd-Zertifizierungsstelle sorgt für die Sicherheit der Kommunikation vom API-Server zu den etcd-Replikaten sowie des Traffics zwischen etcd-Replikaten.
  • Die Clusterzertifizierungsstelle sichert die Kommunikation zwischen dem API-Server und allen internen Kubernetes API-Clients (Kubelets, Controller, Planer).
  • Die Front-Proxy-CA schützt die Kommunikation mit aggregierten APIs.

Sie können auch eine Organisationszertifizierungsstelle verwenden, um das mit der Option authentication.sni konfigurierte Zertifikat zu signieren, das die Kubernetes API für Clients außerhalb des Clusters bereitstellt. Sie verwalten diese Zertifizierungsstelle und generieren das SNI-Zertifikat manuell. Die CA-Rotation für Nutzercluster hat keine Auswirkungen auf die Organisations-CA oder das SNI-Zertifikat.

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 in erweiterten Clustern unterstützt. Es gibt jedoch einige geringfügige Unterschiede, die in diesem Dokument gegebenenfalls erwähnt werden.

  • Die Rotation von CA-Zertifikaten ist auf die zuvor genannten etcd-, Cluster- und Front-Proxy-Zertifizierungsstellen 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.

  • 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. Sie sollten auch kurze Ausfallzeiten der Steuerungsebene erwarten, wenn Ihr Nutzercluster keine hochverfügbare Steuerungsebene hat.

  • Sie müssen die kubeconfig-Datei des Nutzerclusters und die Konfigurationsdateien für die Authentifizierung nach einer CA-Rotation aktualisieren. Das liegt daran, dass das alte Clusterzertifikat widerrufen wird und die Anmeldedaten in der kubeconfig-Datei nicht mehr funktionieren.

  • Nachdem eine CA-Rotation gestartet wurde, kann sie nicht mehr pausiert oder rückgängig gemacht werden.

  • Eine CA-Rotation kann je nach Größe des Nutzerclusters sehr viel Zeit in Anspruch nehmen.

Zertifizierungsstelle-Rotation durchführen

  1. Starten Sie die Rotation:

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

    Ersetzen Sie dabei Folgendes:

    • USER_CLUSTER_CONFIG: der Pfad der Nutzercluster-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

Wenn der erweiterte Cluster nicht auf dem Cluster aktiviert ist, ist der Befehl asynchron und startet die CA-Rotation und wird dann beendet. Sie müssen die Ausgabe des Befehls nicht während der gesamten CA-Rotation im Auge behalten. Stattdessen können Sie den Fortschritt regelmäßig mit dem Befehl gkectl update credentials certificate-authorities status prüfen.

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, wird eine Fehlermeldung ähnlich der folgenden 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

So rufen Sie den Status der Rotation auf:

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

Der vorherige Befehl gibt die CAVersion zurück. Dies ist eine Ganzzahl, die vom System automatisch erhöht wird, um die vor und nach einer Rotation verwendeten Zertifizierungsstellen zu unterscheiden. Der Befehl meldet auch einen Status (True oder False), der angibt, ob die CA-Rotation abgeschlossen ist, und eine Nachricht, die beschreibt, welche CAVersion derzeit von jeder Komponente des Systems verwendet wird.

Wenn die CA-Rotation 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 CA-Rotation noch läuft, 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

Bei Clustern, für die das erweiterte Cluster nicht aktiviert ist, müssen Sie eine neue kubeconfig-Datei für den Nutzercluster vom Administratorcluster abrufen. Dies ist erforderlich, da die CA-Rotation die alte CA widerruft, auf der die alte kubeconfig-Datei basiert.

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

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 Befehlsausgabe enthält den Namen der neuen kubeconfig-Datei und sieht in etwa so aus:

Beginning CA rotation with generated CA
...
Successfully rotated CA for user cluster "USER_CLUSTER_NAME". The
kubeconfig file "/home/ubuntu"/USER_CLUSTER_NAME-kubeconfig" has
been updated.

Die neue kubeconfig-Datei befindet sich im selben Verzeichnis wie die kubeconfig-Datei des Administratorclusters, die Sie im Befehl angegeben haben. Der Name der neuen kubeconfig-Datei lautet USER_CLUSTER_NAME-kubeconfig.

Neue kubeconfig-Datei verteilen

Verteilen Sie die neue kubeconfig-Datei an alle, die eine kubeconfig-Datei verwenden, um mit dem Cluster zu interagieren.

Konfigurationsdateien für die Authentifizierung aktualisieren

Nach Abschluss der CA-Rotation müssen die Konfigurationsdateien für die Authentifizierung aktualisiert und neu verteilt werden. Weitere Informationen finden Sie unter Nutzeridentität verwalten.

Rotation der Zertifikate der Steuerungsebene

Ohne Rotation laufen sowohl die Zertifizierungsstellen des Nutzerclusters als auch die Zertifikate der Steuerungsebene zehn Jahre nach dem Erstellungsdatum des Clusters ab. Bei Versionen vor 1.36.100 laufen diese Zertifikate nach fünf Jahren ab. 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 zehn Jahre (fünf Jahre für Versionen vor 1.36.100) 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_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 der CA-Rotation Probleme auftreten, wenden Sie sich an den Google-Support und geben Sie dabei die Ausgabe von gkectl diagnose an.