Cluster Trust

In diesem Dokument geht es um das Vertrauensmodell in GKE-Clustern (Google Kubernetes Engine), einschließlich der Kommunikation innerhalb von Clustern und der Authentifizierung von Anfragen für Komponenten wie Steuerungsebenen. Für dieses Dokument wird vorausgesetzt, dass Sie mit den folgenden Themen vertraut sind:

Dieses Dokument richtet sich an Sicherheitsexperten, die das Cluster-Vertrauensmodell von GKE verstehen möchten. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

Kommunikation innerhalb eines Clusters

GKE wendet verschiedene Sicherheitsmechanismen auf den Traffic zwischen Clusterkomponenten an:

  • Traffic zwischen der Steuerungsebene und den Knoten: Die Steuerungsebene kommuniziert mit einem Knoten zum Verwalten von Containern. Wenn die Steuerungsebene eine Anfrage (z. B. kubectl logs) an Knoten sendet, wird die Anfrage über einen Konnectivity-Proxy-Tunnel gesendet. Von der Steuerungsebene gesendete Anfragen werden authentifiziert und durch TLS geschützt. Wenn ein Knoten eine Anfrage an die Steuerungsebene sendet, z. B. von kubelet an den API-Server, wird diese Anfrage mithilfe von gegenseitigem TLS (Mutual TLS, mTLS) authentifiziert und verschlüsselt.

    Alle neu erstellten und aktualisierten Cluster verwenden TLS 1.3 für die Kommunikation von Steuerungsebene zu Knoten. TLS 1.2 ist die unterstützte Mindestversion für die Kommunikation von Steuerungsebene zu Knoten.

  • Traffic zwischen Knoten: Knoten sind Compute Engine-VMs. Verbindungen zwischen Knoten im Google Cloud Produktionsnetzwerk werden authentifiziert und verschlüsselt. Weitere Informationen finden Sie im Abschnitt VM-zu-VM des Whitepapers zur Verschlüsselung bei der Übertragung in Google Cloud.

  • Traffic zwischen Pods: Wenn ein Pod eine Anfrage an einen anderen Pod sendet, wird dieser Traffic nicht standardmäßig authentifiziert. GKE verschlüsselt Traffic zwischen Pods auf verschiedenen Knoten auf der Netzwerkschicht. Traffic zwischen Pods auf demselben Knoten wird nicht standardmäßig verschlüsselt. Weitere Informationen zur Verschlüsselung auf Netzwerkebene finden Sie unter Google Cloud Virtuelle Netzwerkverschlüsselung und authentifizierung.

    Sie können den Pod-zu-Pod-Traffic mit einer NetworkPolicy einschränken, und Sie können den gesamten Pod-zu-Pod-Traffic, einschließlich Traffic auf demselben Knoten, mit einem Service Mesh wie Cloud Service Mesh verschlüsseln oder eine andere Methode der Verschlüsselung auf Anwendungsebene verwenden.

  • Traffic zwischen Komponenten der Steuerungsebene: Der Traffic zwischen verschiedenen Komponenten, die auf der Steuerungsebene ausgeführt werden, wird mit TLS authentifiziert und verschlüsselt. Der Traffic verlässt niemals ein Google-eigenes Netzwerk, das durch Firewalls geschützt ist.

Root of trust

GKE hat die folgende Konfiguration:

  • Die Root-Zertifizierungsstelle des Clusters wird verwendet, um die Clientzertifikate des API-Servers und der kubelets zu prüfen. Das bedeutet, Steuerungsebenen und Knoten haben dieselbe Root of Trust. Jedes kubelet innerhalb des Cluster Knotenpools kann mit der certificates.k8s.io API ein Zertifikat von dieser Zertifizierungsstelle anfordern. Dazu wird eine Zertifikatsignierungsanfrage gesendet. Die Root-Zertifizierungsstelle hat eine begrenzte Lebensdauer, wie im Abschnitt Lebensdauer der Stammzertifizierungsstelle des Clusters beschrieben.
  • In Clustern, in denen etcd-Datenbankinstanzen auf den VMs der Steuerungsebene ausgeführt werden, wird eine separate etcd-Peer-Zertifizierungsstelle pro Cluster verwendet, um Vertrauen zwischen etcd-Instanzen herzustellen.
  • In allen GKE-Clustern wird eine separate etcd-API-Zertifizierungsstelle verwendet, um Vertrauen zwischen dem Kubernetes API-Server und der etcd API herzustellen.

API-Server und kubelets

Der API-Server und die kubelets verwenden die Stammzertifizierungsstelle des Clusters für die Vertrauenswürdigkeit. In GKE wird das API-Zertifikat der Steuerungsebene von der Stammzertifizierungsstelle des Clusters signiert. Jeder Cluster führt seine eigene Zertifizierungsstelle aus. Wenn also die Zertifizierungsstelle eines Clusters kompromittiert wird, ist keine andere Cluster-Zertifizierungsstelle betroffen.

Ein interner Dienst verwaltet Stammschlüssel für diese Zertifizierungsstelle, die nicht exportierbar sind. Dieser Dienst akzeptiert Anfragen zur Signierung von Zertifikaten, einschließlich der Anfragen von kubelets in jedem GKE-Cluster. Selbst wenn der API-Server in einem Cluster kompromittiert wäre, ist die Zertifizierungsstelle nicht kompromittiert, sodass keine anderen Cluster betroffen wären.

Jedem Knoten im Cluster wird bei der Erstellung ein gemeinsames Secret hinzugefügt, das zum Senden von Zertifikatsignieranfragen an die Stammzertifizierungsstelle des Clusters und zum Abrufen von kubelet-Clientzertifikaten verwendet werden kann. Diese Zertifikate werden dann von kubelet verwendet, um seine Anfragen an den API-Server zu authentifizieren. Dieses gemeinsame Secret ist für Pods auf dem Knoten erreichbar, es sei denn, Sie aktivieren Shielded GKE-Knoten oder die Workload Identity-Föderation für GKE.

Lebensdauer einer Stammzertifizierungsstelle des Clusters

Die Stammzertifizierungsstelle des Clusters hat eine begrenzte Lebensdauer, nach der alle von der abgelaufenen Zertifizierungsstelle signierten Zertifikate ungültig sind. Prüfen Sie das ungefähre Ablaufdatum der Zertifizierungsstelle Ihres Clusters. Folgen Sie dazu der Anleitung unter Gültigkeitsdauer von Anmeldedaten prüfen.

Sie sollten Ihre Anmeldedaten manuell rotieren, bevor Ihre vorhandene Stammzertifizierungsstelle abläuft. Wenn die Zertifizierungsstelle abläuft und Sie Ihre Anmeldedaten nicht rotieren, wechselt der Cluster möglicherweise in einen nicht wiederherstellbaren Zustand. GKE hat die folgenden Mechanismen, um nicht wiederherstellbare Cluster zu testen und zu verhindern:

  • Der Cluster wechselt sieben Tage vor Ablauf der Zertifizierungsstelle in den Status DEGRADED.

  • GKE versucht 30 Tage vor dem Ablauf der Zertifizierungsstelle eine automatische Rotation der Anmeldedaten. Diese automatische Rotation ignoriert Wartungsfenster und kann zu Störungen führen, da GKE Knoten neu erstellt, um neue Anmeldedaten zu verwenden. Externe Clients wie kubectl in lokalen Umgebungen funktionieren erst, wenn Sie sie für die Verwendung der neuen Anmeldedaten aktualisieren.

Informationen zum Ausführen einer Rotation finden Sie unter Clusteranmeldedaten rotieren.

Speicher für den Clusterstatus

In GKE-Clustern wird der Status von Kubernetes API-Objekten als Schlüssel-Wert-Paare in einer Datenbank gespeichert. Der Kubernetes API-Server auf der Steuerungsebene interagiert mit dieser Datenbank über die etcd API. GKE verwendet eine der folgenden Technologien, um die Datenbank für den Clusterstatus auszuführen:

  • etcd: Der Cluster verwendet etcd-Instanzen, die auf den VMs der Steuerungsebene ausgeführt werden.
  • Spanner: Der Cluster verwendet eine Spanner Datenbank, die außerhalb der VMs der Steuerungsebene ausgeführt wird.

Unabhängig von der Datenbanktechnologie, die ein Cluster verwendet, stellt jeder GKE-Cluster die etcd API auf der Steuerungsebene bereit. Um den Traffic zu verschlüsseln, der die Datenbank für den Clusterstatus umfasst, verwendet GKE eine oder beide der folgenden Zertifizierungsstellen pro Cluster:

  • etcd API-Zertifizierungsstelle: Wird verwendet, um Zertifikate für den Traffic zu und von etcd API Endpunkten zu signieren. In jedem GKE-Cluster wird eine etcd API-Zertifizierungsstelle ausgeführt.
  • etcd-Peer-Zertifizierungsstelle: Wird verwendet, um Zertifikate für den Traffic zwischen etcd Datenbankinstanzen auf der Steuerungsebene zu signieren. In jedem Cluster, der etcd-Datenbanken verwendet, wird eine etcd-Peer-Zertifizierungsstelle ausgeführt. Cluster, die Spanner-Datenbanken verwenden, verwenden die etcd-Peer-Zertifizierungsstelle nicht.

Stammschlüssel für die etcd API-Zertifizierungsstelle werden an die Metadaten jeder Compute Engine-Instanz verteilt, auf der die Steuerungsebene ausgeführt wird. Die etcd API-Zertifizierungsstelle wird nicht von mehreren Clustern gemeinsam verwendet.

Die Gültigkeit des etcd-CA-Zertifikats hängt vom Erstellungsdatum des Clusters ab:

  • Bei Clustern, die vor Oktober 2021 erstellt wurden, ist das Zertifikat 5 Jahre lang gültig.
  • Bei Clustern, die nach Oktober 2021 erstellt wurden, ist das Zertifikat 30 Jahre lang gültig. Unabhängig vom Erstellungsdatum des Clusters ist das neue etcd-CA-Zertifikat, das bei einer Zertifikatsrotation erstellt wird, 30 Jahre lang gültig. Das Zertifikat wird 6 Monate vor Ablauf automatisch rotiert.

Zertifikatsrotation

Führen Sie die Rotation von Anmeldedaten durch, um sämtliche API-Server- und kubelet-Zertifikate Ihres Clusters zu rotieren. Die Rotation der etcd-Zertifikate kann nicht manuell ausgelöst werden, da dies in GKE für Sie verwaltet wird.

Nächste Schritte