In diesem Dokument wird beschrieben, wie Google Kubernetes Engine (GKE) Ihre Komponenten der Clustersteuerungsebene schützt. In diesem Dokument wird davon ausgegangen, dass Sie mit Folgendem vertraut sind:
Dieses Dokument richtet sich an Sicherheitsexperten, die wissen möchten, wie Google GKE-Steuerungsebenenkomponenten verwaltet und welche Sicherheitsmaßnahmen vorhanden sind, um Risiken effektiv zu bewerten und die Sicherheit Ihrer GKE-Bereitstellungen zu gewährleisten.
GKE umfasst integrierte Sicherheitsfunktionen wie ein gehärtetes Betriebssystem, eine robuste Architektur und Isolation, sicheren Zugriff auf die Steuerungsebene, Sicherheit für die etcd- oder Spanner-basierte Datenbank für den Clusterstatus, Zertifizierungsstelle und Clustervertrauenswürdigkeit sowie Verwaltung von Sicherheitslücken und Patches.
Im Rahmen des Modells der geteilten Verantwortung verwaltet Google die Komponenten der GKE-Steuerungsebene für Sie. Die Steuerungsebene umfasst den Kubernetes API-Server, den Kubernetes API-Objektspeicher und andere Controller. Google ist für die Sicherung der Steuerungsebene verantwortlich. Möglicherweise können Sie jedoch bestimmte Optionen gemäß Ihren Anforderungen konfigurieren. Sie sind für die Sicherung Ihrer Knoten, Container und Pods verantwortlich.
Gehärtetes Betriebssystem
Komponenten der GKE-Steuerungsebene werden unter Container-Optimized OS ausgeführt, einem von Google entwickelten sicherheitsoptimierten Betriebssystem. Eine ausführliche Beschreibung der integrierten Sicherheitsfunktionen von Container-Optimized OS finden Sie im Überblick über die Sicherheit.
Architektur und Isolation
Die Komponenten der Steuerungsebene in einem GKE-Cluster werden als Eigentum von Google in einem von Google verwalteten Projekt auf Compute Engine-Instanzen ausgeführt. Die Komponenten werden auf jeder Instanz jeweils nur für einen Cluster ausgeführt.
Weitere Informationen zur Authentifizierung von Clusterkomponenten finden Sie unter Cluster Trust.
Zugriff der Steuerungsebene auf Ihr Projekt
GKE verwendet einen Dienst-Agent mit dem Namen des Kubernetes Engine-Dienst-Agents, um Clusterressourcen wie Knoten, Laufwerke und Load-Balancer in Ihrem Namen einzusetzen. Dem Dienstkonto wird automatisch die Rolle des Kubernetes Engine-Dienst-Agents (roles/container.serviceAgent) für Ihr Projekt zugewiesen.
Der Kubernetes Engine-Dienst-Agent hat die folgende E-Mail-Adresse:
service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com
In dieser E-Mail-Adresse ist PROJECT_NUMBER Ihre Projektnummer.
Administratorzugriff auf den Cluster
SSH-Sitzungen der Site Reliability Engineers (SREs) von Google werden per Audit-Log über die Infrastruktur für interne Überprüfungen von Google aufgezeichnet, die für Forensik und Sicherheitsmaßnahmen verfügbar ist. Weitere Informationen finden Sie unter Administratorzugriff im Whitepaper zur Sicherheit bei Google.
Sicherheit der Datenbank für den Clusterstatus
In Google Cloudwerden Kundeninhalte standardmäßig auf Dateisystemebene verschlüsselt. Diese Verschlüsselung umfasst die Infrastruktur, auf der die etcd- oder Spanner-basierte Datenbank gehostet wird, in der der Status von Kubernetes API-Objekten in Ihrem Cluster gespeichert wird. Weitere Informationen zur Clusterstatusdatenbank finden Sie unter GKE-Clusterarchitektur.
In der Clusterstatusdatenbank wird die Konfiguration jedes Kubernetes-API-Objekts in Ihrem Cluster als Schlüssel/Wert-Paare gespeichert. GKE verwendet bestimmte TCP-Ports auf VMs der Steuerungsebene für die folgenden Arten der Kommunikation mit der Clusterstatusdatenbank:
etcd API-Clients: GKE stellt die etcd API auf jeder VM der Steuerungsebene bereit. etcd API-Clients in der Steuerungsebene, z. B. der Kubernetes API-Server, verwenden einen der folgenden Ports:
- Port 2379: Dieser Port wird verwendet, wenn GKE den Clusterstatus in etcd-Datenbankinstanzen speichert, die auf jeder VM der Steuerungsebene ausgeführt werden.
- Port 3379: Dieser Port wird verwendet, wenn GKE den Clusterstatus in einer Spanner-Datenbank speichert, die von der Steuerungsebene getrennt ist.
Der Port, den etcd API-Clients verwenden, ist an die lokale Loopback-Netzwerkschnittstelle gebunden und nur über die VM der Steuerungsebene zugänglich, auf der der Kubernetes API-Server ausgeführt wird.
etcd-Datenbankinstanzen: Wenn auf den VMs der Steuerungsebene etcd-Datenbankinstanzen ausgeführt werden, verwenden die etcd-API-Server auf jeder VM Port 2380 für die Kommunikation miteinander. Traffic auf Port 2380 zwischen etcd-Datenbankinstanzen auf mehreren VMs der Steuerungsebene (z. B. in regionalen Clustern) wird durch gegenseitige TLS-Authentifizierung verschlüsselt. Bei der gegenseitigen TLS-Authentifizierung muss jeder Server gegenüber anderen Servern seine Identität nachweisen.
Port 2380 wird in Clustern, in denen der Clusterstatus in einer Spanner-Datenbank gespeichert wird, nicht verwendet, da die Datenbank nicht auf den VMs der Steuerungsebene ausgeführt wird.
Zertifizierungsstelle und Vertrauenswürdigkeit in Clustern
Jeder Cluster verfügt über eine eigene Stammzertifizierungsstelle. Ein interner Google-Dienst verwaltet Stammschlüssel für diese Zertifizierungsstelle. Stammschlüssel für diese Zertifizierungsstelle werden an die Metadaten der VMs verteilt, auf denen der Kubernetes API-Server ausgeführt wird. Die Kommunikation zwischen Knoten und dem Kubernetes API-Server wird durch TLS geschützt. Jeder Cluster hat außerdem eine eigene Zertifizierungsstelle für die etcd-API und, falls im Cluster etcd-Datenbankinstanzen ausgeführt werden, für den Traffic zwischen etcd-Instanzen. Weitere Informationen finden Sie unter Cluster Trust.
Sicherheitslücken und Patchverwaltung
GKE erfüllt die Google-Standards für das Testen, Qualifizieren und schrittweise Implementieren von Änderungen an der Steuerungsebene. Dadurch wird das Risiko minimiert, dass eine Komponente der Steuerungsebene ausfällt. GKE richtet sich nach einem Service Level Agreement, in dem viele Aspekte der Verfügbarkeit definiert werden.
Komponenten der GKE-Steuerungsebene werden von einem Team aus Site Reliability Engineers von Google verwaltet und regelmäßig mit den neuesten Sicherheitspatches aktualisiert. Dazu gehören Patches für das Hostbetriebssystem, Kubernetes-Komponenten und Container, die auf den VMs der Steuerungsebene ausgeführt werden.
Neue Fehlerkorrekturen auf Kernel-, Betriebssystem- und Kubernetes-Ebene werden in GKE umgehend auf VMs der Steuerungsebene angewendet. Wenn Korrekturen für bekannte Sicherheitslücken enthalten sind, stehen in den GKE-Sicherheitsbulletins zusätzliche Informationen zur Verfügung. GKE prüft alle Kubernetes-Systeme und GKE-spezifischen Container mithilfe der Artefaktanalyse auf Schwachstellen und sorgt dafür, dass alle Container regelmäßig gepatcht werden. Das kommt der gesamten Kubernetes-Umgebung zugute.
Google-Entwickler sind an der Suche, Behebung und Veröffentlichung von Kubernetes-Sicherheitsproblemen beteiligt. Außerdem bezahlt Google externe Sicherheitsexperten im Rahmen des Google Vulnerability Reward Program (Prämienprogramm für die Meldung von Sicherheitslücken), um nach Sicherheitslücken zu suchen. In einigen Fällen, wie der dnsmasq-Sicherheitslücke im Oktober 2017, konnten alle ausgeführten Cluster durch GKE gepatcht werden, bevor die Sicherheitslücke öffentlich bekannt wurde.
Was Sie einsehen und überwachen können
Die in den vorherigen Abschnitten beschriebenen Sicherheitsfunktionen werden von Google verwaltet. In diesem Abschnitt und im Abschnitt Konfigurationsmöglichkeiten werden Sicherheitsfunktionen beschrieben, die Sie beobachten und konfigurieren können.
- Audit-Logs: Audit-Logging ist standardmäßig aktiviert. Es bietet eine detaillierte Aufzeichnung der Aufrufe des Kubernetes API-Servers, die in Google Cloud Observability verfügbar ist. Sie können die Logeinträge im Log-Explorer in derGoogle Cloud Console ansehen. Außerdem können Sie diese Logs mit BigQuery aufrufen und analysieren.
Integrität von VM-Images der Steuerungsebene: GKE fügt Cloud Logging detaillierte Logs für die Erstellung von Knoten-VMs und Boot-Ereignisse hinzu. Außerdem veröffentlichen wir SLSA-VSAs auf GitHub, die den Maschinen-Images für die Steuerungsebene und die Worker-Knoten entsprechen. Sie können prüfen, ob Ihre VMs Betriebssystem-Images verwenden, die entsprechende VSAs haben, und die Integrität beim Booten jeder Steuerungsebene-VM prüfen.
Informationen zum Prüfen der VM-Integrität finden Sie unter Integrität von GKE-Steuerungsebenen-VMs prüfen.
Konfigurationsmöglichkeiten
GKE verwaltet zwar den Großteil der Steuerungsebene für Sie, aber Sie können Folgendes steuern:
Zugriff auf die Steuerungsebene: Die Steuerungsebene hat zwei Arten von Endpunkten für den Clusterzugriff:
- DNS-basierter Endpunkt
- IP-basierte Endpunkte
Standardmäßig nutzt der Kubernetes API-Server eine externe IP-Adresse. Sie können den Kubernetes API-Server schützen, indem Sie einen DNS-basierten Endpunkt für den Zugriff auf die Steuerungsebene aktivieren. Mit VPC Service Controls können Sie steuern, wer auf den DNS-Endpunkt zugreifen kann. Damit können Sie einen Sicherheitsparameter für alle Google-APIs in Ihrem Projekt definieren. Wenn Sie IP-basierte Endpunkte für den Zugriff auf die Steuerungsebene verwenden, empfehlen wir, autorisierte Netzwerke zu verwenden und den Zugriff auf den externen Endpunkt der Steuerungsebene zu deaktivieren. Weitere Informationen zur Netzwerkisolation finden Sie unter Netzwerkisolation anpassen.
Authentifizierung: Für die Clusterauthentifizierung in GKE können Sie IAM als Identitätsanbieter verwenden. Zur Verbesserung der Authentifizierungssicherheit sind die Basisauthentifizierung und die Ausgabe von Clientzertifikaten standardmäßig deaktiviert.
Anmeldedatenrotation: Rotieren Sie die Cluster-Zertifizierungsstelle (CA) und die TLS-Zertifikate regelmäßig, indem Sie eine Anmeldedatenrotation durchführen. Außerdem wird in GKE während dieses Vorgangs eine Rotation der IP-Adresse des Kubernetes API-Servers durchgeführt. Weitere Informationen finden Sie unter Rotation von Anmeldedaten.
Wenn Ihre Organisation strenge Compliance- oder Richtlinienanforderungen in Bezug auf die Steuerungsebene hat, bietet die GKE Control Plane Authority eine Reihe von Funktionen, mit denen Sie mehr Einblick und Kontrolle über bestimmte Aspekte der Steuerungsebene erhalten, darunter:
- Sie können Ihre eigenen Zertifizierungsstellen und Schlüssel für die Identitätsausstellung mit Cloud KMS und CA Service ausführen.
- Verschlüsseln Sie etcd- und Bootlaufwerke der Steuerungsebene mit Ihren eigenen Schlüsseln in Cloud KMS.
Weitere Informationen dazu, warum Sie diese Funktionen verwenden sollten, und zu allen verfügbaren Funktionen finden Sie unter GKE Control Plane Authority.