Cluster Trust

In diesem Dokument geht es um das Vertrauensmodell in Google Kubernetes Engine-Clustern (GKE), 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 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 mit TLS geschützt. Wenn ein Knoten eine Anfrage an die Steuerungsebene sendet, z. B. vom 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 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 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 durch Firewalls geschütztes Google-eigenes Netzwerk.

Root of trust

GKE hat die folgende Konfiguration:

  • Die Stammzertifizierungsstelle des Clusters wird verwendet, um die Clientzertifikate des API-Servers und der Kubelets zu validieren. Das bedeutet, Steuerungsebenen und Knoten haben dieselbe Root of Trust. 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, in denen etcd-Datenbankinstanzen auf den VMs der Steuerungsebene ausgeführt werden, wird eine separate etcd-Peer-CA pro Cluster verwendet, um das 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 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.

Speichern des Clusterstatus

In GKE-Clustern wird der Status von Kubernetes API-Objekten als Schlüssel/Wert-Paare in einer Datenbank gespeichert. 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 auf der Steuerungsebene bereit. Zum Verschlüsseln des Traffics, der die Clusterstatusdatenbank umfasst, verwendet GKE eine oder beide der folgenden clusterbezogenen CAs:

  • 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 den Traffic zwischen etcd-Datenbankinstanzen auf der Steuerungsebene verwendet. Eine etcd-Peer-Zertifizierungsstelle wird in jedem Cluster ausgeführt, in dem etcd-Datenbanken verwendet werden. Für Cluster, die Spanner-Datenbanken verwenden, wird die etcd-Peer-Zertifizierungsstelle nicht verwendet.

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 etcd-CA-Zertifikate sind fünf Jahre lang gültig. GKE rotiert diese Zertifikate automatisch, bevor sie ablaufen.

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