Cluster Trust

Auf dieser Seite wird das Vertrauen in Google Kubernetes Engine-Cluster beschrieben, einschließlich der Authentifizierung von Anfragen bei den Steuerungsebenen (Mastern) 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 an den Knoten sendet, beispielsweise "kubectl logs", wird diese Anfrage über einen SSH-Tunnel gesendet und außerdem mit TLS geschützt, wodurch Authentifizierung, Integrität und Verschlüsselung gegeben ist. Wenn ein Knoten eine Anfrage an die Steuerungsebene sendet, z. B. 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

Ein Knoten kann als Teil einer bestimmten Arbeitslast mit einem anderen Knoten kommunizieren. Wenn der Knoten eine Anfrage an einen anderen Knoten sendet, wird diese Anfrage authentifiziert und verschlüsselt, wenn diese Verbindung eine von Google kontrollierte physische Grenze überschreitet. Beachten Sie, dass keine Kubernetes-Komponenten Knoten-zu-Knoten-Kommunikation erfordern. Weitere Informationen finden Sie im Whitepaper Verschlüsselung bei der Übertragung in Google Cloud.

Pod-zu-Pod

Ein Pod kann als Teil einer bestimmten Arbeitslast mit einem anderen Pod kommunizieren. Wenn der Pod eine Anfrage an einen anderen Pod sendet, wird diese Anfrage weder authentifiziert noch verschlüsselt. Beachten Sie, dass keine Kubernetes-Komponenten eine Pod-zu-Pod-Kommunikation erfordern. Pod-zu-Pod-Traffic kann mit einer Netzwerkrichtlinie eingeschränkt und mit einem Dienstnetzwerk wie Istio oder der Implementierung von Verschlüsselung auf Anwendungsebene verschlüsselt werden.

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 findet vollständig über localhost statt und wird nicht authentifiziert oder verschlüsselt.

Root of trust

GKE ist wie folgt konfiguriert:

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

API-Server und kubelets

Der API-Server und kubelets verwenden die Stammzertifizierungsstelle des Clusters von Kubernetes 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 Google-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. Beachten Sie, dass dieses gemeinsame Secret für Pods erreichbar ist, sofern die Metadatenverbergung nicht aktiviert ist.

Der API-Server und die kubelet-Zertifikate sind fünf Jahre lang gültig, können jedoch durch die Rotation von Anmeldedaten manuell früher rotiert werden.

etcd

etcd stützt sich auf eine separate clusterspezifische Zertifizierungsstelle für die Vertrauenswürdigkeit in GKE.

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