Clusterzugangsdaten rotieren

Erfahren Sie, wie Sie die Zugangsdaten von Clustern rotieren, die Sie mit der Kubernetes Engine (OKE) erstellt haben.

Um eine sichere TLS-Kommunikation (früher SSL) zu, von und innerhalb von Clustern zu ermöglichen, verwendet Kubernetes PKI-(Public Key Infrastructure-)Zertifikate zur Authentifizierung. Weitere Informationen zu PKI-Zertifikaten und Kubernetes-Clustern finden Sie unter PKI-Zertifikate und -Anforderungen in der Kubernetes-Dokumentation.

Die Cluster, die Sie mit der Kubernetes-Engine erstellen, verfügen über PKI-Root-CAs (Certificate Authorities) und Private Keys für das Cluster, die etcd-Komponente und die Front-Proxy-Komponente. Mit diesen Root-CAs werden die im Cluster verwendeten Zertifikate und Private Keys signiert. Die Root-CAs, signierten Zertifikate und privaten Schlüssel, die im Cluster verwendet werden, werden zusammen als Clusterzugangsdaten bezeichnet.

In Clustern, die Sie mit der Kubernetes-Engine erstellen, laufen die Root-CAs nach fünf Jahren ab. Um ein Cluster weiterhin zu verwenden, müssen Sie die Clusterzugangsdaten vor dem Ende des Zeitraums von fünf Jahren ändern (oder rotieren). Darüber hinaus verfügen Ihre Unternehmen möglicherweise über Sicherheitsrichtlinien und -richtlinien, bei denen Sie Clusterzugangsdaten häufiger rotieren müssen (in einigen Fällen viel häufiger). Meldungen, die Sie über den bevorstehenden Ablauf von Clusterzugangsdaten informieren, werden in der Konsole angezeigt. Sie können auch die Konsole, die CLI und die API verwenden, um zu ermitteln, wann Clusterzugangsdaten ablaufen sollen.

Wenn Sie Clusterzugangsdaten rotieren, müssen Sie Kubernetes-API-Clients aktualisieren, die die vorherigen Zugangsdaten verwendet haben, um mit der Kubernetes-API zu kommunizieren. Solche Kubernetes-API-Clients umfassen kubeconfig-Dateien und Pods, die direkt mit der Kubernetes-API kommunizieren.

Das Rotieren von Clusterzugangsdaten erfolgt in drei Schritten:

• Schritt 1, Phase "Zugangsdatenrotation starten": Während der Phase "Zugangsdatenrotation starten" werden neue Root-CAs, Private Keys und Zertifikate erstellt. Sie können die Phase "Zugangsdatenrotation starten" jederzeit initiieren. Sie müssen jedoch die Zugangsdatenrotation starten, bevor die Zugangsdaten ablaufen. Wenn Sie die Zugangsdatenrotation starten, bevor die Zugangsdaten ablaufen, wird auch eine Serviceunterbrechung vermieden.

  Wenn Sie die Phase "Zugangsdatenrotation starten" initiieren, geben Sie explizit die Länge eines "Verzögerungszeitraums" an, bevor die Phase "Zugangsdatenrotation abschließen" automatisch initiiert wird. Mit dem Verzögerungszeitraum können Sie Kubernetes-API-Clients aktualisieren (Schritt 2). Während des Verzögerungszeitraums bieten sowohl die Legacy-Zugangsdaten als auch die neuen Zugangsdaten eine sichere Kommunikation mit, aus und innerhalb des Clusters. Die angegebene Verzögerungsperiode darf nicht weniger als 1 Tag und nicht mehr als 90 Tage betragen. Sie können die Phase "Zugangsdatenrotation abschließen" manuell vor dem Ende des Verzögerungszeitraums initiieren, sofern die neuen Zugangsdaten mindestens 24 Stunden alt sind und Sie Schritt 2 erfolgreich abgeschlossen haben.

  Starten Sie Schritt 2 erst, wenn die neuen Root-CAs, Private Keys und Zertifikate erstellt wurden.

  Hinweis
  
  Wenn Sie die CLI oder API zum Starten der Rotationsphase "Zugangsdaten starten" verwenden, geben Sie die Länge des Verzögerungszeitraums im ISO 8601-Dauerformat an. Beispiel:

  • Verwenden Sie P5D, um fünf Tage anzugeben
  • Verwenden Sie P5DT5H, um fünf Tage und fünf Stunden anzugeben
  • Verwenden Sie P5DT5H5M, um fünf Tage, fünf Stunden und fünf Minuten anzugeben

  Weitere Informationen zum ISO 8601-Dauerformat finden Sie online.

• Schritt 2, Kubernetes-API-Clients aktualisieren: Wenn die neuen Root-CAs, Private Keys und Zertifikate erstellt wurden und innerhalb des angegebenen Verzögerungszeitraums (nicht weniger als 1 Tag und nicht mehr als 90 Tage):
  • Richten Sie neue kubeconfig-Dateien ein, um den Zugriff auf das Cluster mit den neuen Zugangsdaten und den Legacy-Zugangsdaten zu ermöglichen.
  • Erstellen Sie Worker-Knoten neu, die Pods hosten, die direkt mit dem Kubernetes-API-Server kommunizieren, oder starten Sie sie neu (oder um eine Unterbrechung der Worker-Knoten zu vermeiden, starten Sie die Pods einfach selbst neu). Wenn das Cluster virtuelle Knoten enthält, starten Sie alle Pods neu, die auf den virtuellen Knoten ausgeführt werden.

  Starten Sie Schritt 3 erst, wenn Sie neue kubeconfig-Dateien eingerichtet und Worker-Knoten neu erstellt oder neu gestartet haben (oder die Pods einfach neu gestartet haben).

• Schritt 3, Phase "Vollständige Zugangsdatenrotation starten": Wenn Sie Schritt 2 abgeschlossen haben und innerhalb des angegebenen Verzögerungszeitraums (nicht weniger als 1 Tag und nicht mehr als 90 Tage) die Phase "Vollständige Zugangsdatenrotation" manuell initiieren können. Während der Phase "Zugangsdatenrotation abschließen" werden die Legacy-Root-CAs, Private Keys und Zertifikate eingestellt und entfernt. Initiieren Sie die Phase "Fertigstellen der Zugangsdatenrotation" frühestens 24 Stunden, nachdem Sie die Phase "Zugangsdatenrotation starten" initiiert haben, und erst nach Abschluss von Schritt 2. Wenn die neuen Zugangsdaten mindestens 24 Stunden alt sind, können Sie die Phase "Credential Rotation abschließen" starten, sobald Sie bereit sind.

  Wenn Sie die Phase "Zugangsdatenrotation abschließen" während des angegebenen Verzögerungszeitraums (mindestens 1 Tag und höchstens 90 Tage) nicht manuell initiieren, wird die Phase "Zugangsdatenrotation abschließen" am Ende des Verzögerungszeitraums automatisch initiiert.

  Wenn die Phase "Vollständige Zugangsdatenrotation" abgeschlossen ist, wird empfohlen, jede kubeconfig-Datei, die in Schritt 2 erstellt wurde (die sowohl Legacy-Zugangsdaten als auch neue Zugangsdaten enthält), durch eine neue kubeconfig-Datei zu ersetzen, die nur die neuen Zugangsdaten enthält. Wenn das Cluster virtuelle Knoten enthält, wird auch empfohlen, alle Pods, die auf den virtuellen Knoten ausgeführt werden, neu zu starten.

Die Phase "Drehung der Zugangsdaten starten" und "Drehung der Zugangsdaten abschließen" werden als separate Arbeitsanforderungen gestartet. Um den Fortschritt der Phase "Drehung von Zugangsdaten starten" und "Drehung von Zugangsdaten abschließen" zu verfolgen, zeigen Sie den Status der entsprechenden Arbeitsanforderung an. Siehe Arbeitsanforderungen anzeigen.

Sie können Clusterzugangsdaten mit der Konsole, der CLI und der API rotieren.

Beachten Sie beim Rotieren der Clusterzugangsdaten Folgendes:

• Die Zugangsdatenrotation wird für Cluster unterstützt, auf denen Kubernetes-Version 1.20 oder höher ausgeführt wird.
• Durch einfaches Upgrade der Kubernetes-Version auf der Cluster Control Plane werden die Zugangsdaten nicht rotiert. Sie müssen alle Schritte im Prozess der Zugangsdatenrotation ausführen.
• Die Phase "Zugangsdatenrotation starten" und "Zugangsdatenrotation abschließen" können nur beginnen, wenn alle Worker-Knoten im Cluster (verwaltete Knoten, virtuelle Knoten, selbstverwaltete Knoten) den Status "READY" aufweisen. Wenn sich der Status eines oder mehrerer Worker-Knoten während der Zugangsdatenrotation in NOT READY ändert, werden die Zugangsdatenrotationsvorgänge bis zu 24 Stunden angehalten und warten, bis alle Knoten wieder den Status READY haben, bevor sie fortfahren. Wenn ein oder mehrere Worker-Knoten nach 24 Stunden noch den Status NOT READY aufweist, ist der Timeout für Zugangsdatenrotationsvorgänge überschritten.
• Wenn die Phase "Zugangsdatenrotation starten" oder die Phase "Zugangsdatenrotation abschließen" aus irgendeinem Grund nicht erfolgreich verläuft, funktionieren die Legacy-Zugangsdaten weiter und werden erst nach Ablauf deaktiviert.
• Wenn Sie die Phase "Zugangsdatenrotation abschließen" innerhalb des angegebenen Verzögerungszeitraums (mindestens 1 Tag und höchstens 90 Tage) nicht manuell initiieren, wird die Phase "Zugangsdatenrotation abschließen" automatisch initiiert. Wenn Sie Kubernetes-API-Clients vor Ablauf des Verzögerungszeitraums nicht aktualisiert haben, tritt eine Serviceunterbrechung im Cluster auf.