Zertifizierungsstellen rotieren

Google Distributed Cloud verwendet Zertifikate und private Schlüssel zur Authentifizierung und Verschlüsselung von Verbindungen zwischen Systemkomponenten in Clustern. Die Cluster-Zertifizierungsstelle (CA) verwaltet diese Zertifikate und Schlüssel. Wenn Sie den Befehl bmctl update credentials certificate-authorities rotate ausführen, führt Google Distributed Cloud die folgenden Aktionen aus:

• Der Befehl erstellt und lädt neue Clusterzertifizierungsstellen (Certificate Authorities, CA), die etcd-CA und die Front-Proxy-CA in den Nutzercluster-Namespace im Administratorcluster hoch.

• Die Administratorcluster-Controller ersetzen die Zertifizierungsstellen des Nutzerclusters durch die neu generierten Zertifizierungsstellen.

• Die Administratorcluster-Controller verteilen die neuen öffentlichen CA-Zertifikate und Schlüsselpaare für das untergeordnete Zertifikat an die Systemkomponenten des Nutzerclusters.

• Der Befehl aktualisiert auch das Secret stackdriver-prometheus-etcd-scrape, das von Google Distributed Cloud während der Clustererstellung erstellt wurde. Prometheus benötigt dieses Secret, um etcd-Messwerte zu erfassen.

Für eine sichere Clusterkommunikation sollten Sie die Zertifizierungsstelle Ihres Nutzerclusters regelmäßig und bei einem möglichen Sicherheitsverstoß rotieren.

Wichtig: Wenn Ihre Clusterzertifikate abgelaufen sind, müssen Sie sie manuell verlängern, damit der Cluster wieder funktioniert. Weitere Informationen und Anleitungen finden Sie unter Abgelaufene Clusterzertifikate manuell erneuern.

Hinweise

Planen Sie vor dem Rotieren der Cluster-Zertifizierungsstelle entsprechend der folgenden Bedingungen und Auswirkungen:

• Achten Sie darauf, dass die Administrator- und Nutzercluster mindestens Version 1.9.0 haben, bevor Sie die CA-Rotation starten.

• Die Rotation von Cluster-CAs ist inkrementell, sodass Systemkomponenten während der Rotation kommunizieren können.

• 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.

• Wenn Ihr Nutzercluster keine hochverfügbare Steuerungsebene hat, müssen Sie während der CA-Rotation mit kurzen Ausfallzeiten der Steuerungsebene rechnen.

• Clusterverwaltungsoperationen sind während der CA-Rotation nicht zulässig.

• Die Dauer der CA-Rotation hängt von der Größe des Clusters ab. Beispielsweise kann die Rotation von Cluster-CAs für einen Nutzercluster mit einer einzigen Steuerungsebene und 50 Worker-Knoten fast zwei Stunden dauern.

Beschränkungen

Für die Funktion der CA-Rotation gelten die folgenden Einschränkungen:

• Bei der CA-Rotation werden Zertifikate, die von einem Administrator manuell ausgestellt wurden, nicht aktualisiert, auch wenn die Cluster-CA die Zertifikate signiert. Aktualisieren und verteilen Sie alle manuell ausgestellten Zertifikate nach Abschluss der Rotation der Cluster-CA

• Nach dem Start kann die CA-Rotation nicht mehr angehalten und es kann kein Rollback durchgeführt werden.

Cluster-CA-Rotation starten

TLS-Zertifikate haben standardmäßig eine Gültigkeitsdauer von einem Jahr, während das clientconfig-operator-Zertifikat eine Gültigkeitsdauer von 10 Jahren hat (bei Versionen vor 1.36.100 läuft das clientconfig-operator-Zertifikat nach fünf Jahren ab). Diese Zertifikate werden in Google Distributed Cloud verlängert, wenn Sie Zertifizierungsstellen rotieren. Google Distributed Cloud verlängert auch TLS-Zertifikate mit einer Gültigkeitsdauer von einem Jahr bei Cluster-Upgrades. Bei Versionen vor 1.36.100 empfehlen wir, Ihre Cluster regelmäßig zu aktualisieren, damit sie sicher und unterstützt bleiben und TLS-Zertifikate nicht ablaufen. Außerdem sollten Sie mindestens alle fünf Jahre eine CA-Rotation durchführen.

Verwenden Sie den folgenden Befehl, um den CA-Rotationsprozess zu starten:

bmctl update credentials certificate-authorities rotate --cluster CLUSTER_NAME \
    --kubeconfig KUBECONFIG

Dabei gilt:

• CLUSTER_NAME: der Name des Clusters, für den Sie CAs rotieren möchten.
• KUBECONFIG: der Pfad zur kubeconfig-Datei des Administratorclusters. Bei selbstverwalteten Clustern ist diese Datei die kubeconfig-Datei des Clusters.

Der Befehl bmctl wird beendet, nachdem die CA erfolgreich rotiert und eine neue kubeconfig-Datei generiert wurde. Der Standardpfad für die kubeconfig-Datei ist bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-kubeconfig.

Fehler bei einer Cluster-CA-Rotation beheben

Der Befehl bmctl update credentials zeigt den Fortschritt der CA-Rotation des Clusters an. Die zugehörige Datei update-credentials.log wird im folgenden Verzeichnis mit Zeitstempel gespeichert:

bmctl-workspace/CLUSTER_NAME/log/update-credentials-TIMESTAMP