Cluster Trust

Auf dieser Seite wird das Vertrauen in GKE-Cluster (Google Kubernetes Engine) beschrieben, einschließlich der Authentifizierung von Anfragen bei den Steuerungsebenen und Knoten.

Kommunikation innerhalb eines Clusters

In einem Cluster gibt es viele Verbindungen für die Kommunikation zwischen Kubernetes-Komponenten.

Steuerungsebene-zu-Knoten

Die Steuerungsebene kommuniziert mit einem Knoten zum Verwalten von Containern. Wenn die Steuerungsebene eine Anfrage wie kubectl logs an Knoten in öffentlichen Clustern sendet, wird die Anfrage über einen Konnectivity-Proxy-Tunnel gesendet. Anfragen an Knoten in privaten Clustern werden über VPC-Peering gesendet. Von der Steuerungsebene gesendete Anfragen sind mit TLS geschützt, sodass Authentifizierung, Integrität und Verschlüsselung gegeben sind. Wenn ein Knoten eine Anfrage an die Steuerungsebene sendet, z. B. von kubelet an den API-Server, wird diese Anfrage mithilfe von gegenseitigem TLS 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.

Knoten-zu-Knoten

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

Pod-zu-Pod

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 Virtuelle Netzwerkverschlüsselung und -authentifizierung in Google Cloud

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.

etcd-zu-etcd

Eine Instanz von etcd kann mit einer anderen Instanz von etcd kommunizieren, um den Status aktuell zu halten. Wenn eine Instanz von etcd eine Anfrage an eine andere Instanz sendet, wird diese Anfrage mithilfe von gegenseitigem TLS authentifiziert und verschlüsselt. Der Traffic verlässt niemals ein durch Firewalls geschütztes GKE-eigenes Netzwerk.

Steuerungsebene-zu-etcd

Diese Kommunikation wird mit gegenseitigem TLS verschlüsselt.

Root of trust

GKE hat die folgende Konfiguration:

  • Die Stammzertifizierungsstelle 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 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.
  • Es wird eine separate etcd-Zertifizierungsstelle pro Cluster zur Validierung der Zertifikate von etcd verwendet.

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.

etcd

In GKE nutzt etcd für die Vertrauensstellung eine separate clusterspezifische etcd-Zertifizierungsstelle.

Stammschlüssel für die etcd-Zertifizierungsstelle werden an die Metadaten jeder VM verteilt, auf der die Steuerungsebene ausgeführt wird. Jeder Code, der auf VMs auf Steuerungsebene oder mit Zugriff auf Compute-Metadaten für diese VMs ausgeführt wird, kann als diese Zertifizierungsstelle Zertifikate signieren. Selbst wenn etcd in einem Cluster kompromittiert wurde, wird die Zertifizierungsstelle nicht zwischen Clustern geteilt, sodass keine weiteren Cluster betroffen wären.

Die etcd-Zertifikate sind fünf Jahre lang gültig.

Zertifikate rotieren

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.

Weitere Informationen