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. In diesem Dokument wird davon ausgegangen, dass Sie mit Folgendem vertraut sind:

Dieses Dokument richtet sich an Sicherheitsexperten, die das GKE-Cluster-Vertrauensmodell 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. Anfragen, die von der Steuerungsebene gesendet werden, 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 (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 Produktionsnetzwerk von Google Cloud 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 Netzwerkschicht 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: Traffic zwischen verschiedenen Komponenten, die auf der Steuerungsebene ausgeführt werden, wird mit TLS authentifiziert und verschlüsselt. Der Traffic verlässt nie ein von Google verwaltetes 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, dass Steuerungsebenen und Knoten dieselbe Root of Trust haben. Jedes kubelet innerhalb des Clusterknotenpools kann mit der API certificates.k8s.io 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, die etcd-Datenbankinstanzen auf den VMs der Steuerungsebene ausführen, wird eine separate etcd-Peer-Zertifizierungsstelle pro Cluster verwendet, um eine Vertrauensstellung zwischen etcd-Instanzen herzustellen.
  • In allen GKE-Clustern wird eine separate etcd-API-Zertifizierungsstelle verwendet, um eine Vertrauensstellung 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 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 des 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.

Clusterstatus-Speicher

GKE-Cluster speichern den Status von Kubernetes API-Objekten als Schlüssel/Wert-Paare in einer Datenbank. Der Kubernetes API-Server in Ihrer Steuerungsebene interagiert mit dieser Datenbank über die etcd API. GKE verwendet eine der folgenden Technologien, um die Clusterstatusdatenbank 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 in der Steuerungsebene bereit. Zum Verschlüsseln des Traffics, der die Clusterstatusdatenbank betrifft, verwendet GKE eine oder beide der folgenden clusterbezogenen Zertifizierungsstellen:

  • etcd API CA: Wird zum Signieren von Zertifikaten für Traffic zu und von etcd API-Endpunkten verwendet. In jedem GKE-Cluster wird eine etcd API-Zertifizierungsstelle ausgeführt.
  • etcd-Peer-Zertifizierungsstelle: Wird zum Signieren von Zertifikaten für Traffic zwischen etcd-Datenbankinstanzen auf der Steuerungsebene verwendet. Eine etcd-Peer-Zertifizierungsstelle wird in jedem Cluster ausgeführt, der etcd-Datenbanken verwendet. Cluster, die Spanner-Datenbanken verwenden, nutzen nicht die etcd-Peer-Zertifizierungsstelle.

Root-Schlü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 zwischen Clustern geteilt.

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 fünf 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 während 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