In diesem Dokument wird beschrieben, wie Google Kubernetes Engine (GKE) Ihre Komponenten der Cluster-Steuerungsebene 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 getroffen werden, um Risiken effektiv zu bewerten und die Sicherheit Ihrer GKE-Bereitstellungen zu gewährleisten.
GKE enthält integrierte Sicherheitsfunktionen wie ein sicherheitsgehärtetes Betriebssystem, eine robuste Architektur und Isolation, sicheren Zugriff auf die Steuerungsebene, Sicherheit für die etcd- oder Spanner-basierte Clusterstatusdatenbank, Zertifizierungsstelle und Clustervertrauen sowie Sicherheitslücken- und Patchverwaltung.
Im Rahmen des Modells der gemeinsamen 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.s3ns-system.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 Cloud de Confiance by S3NSwerden 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 Datenbank für den Clusterstatus 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, um miteinander zu kommunizieren. Der Traffic auf Port 2380 zwischen etcd-Datenbankinstanzen auf mehreren VMs der Steuerungsebene (z. B. in regionalen Clustern) wird durch gegenseitiges TLS verschlüsselt. Bei gegenseitigem TLS muss jeder Server seine Identität gegenüber dem anderen 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 hat eine eigene Root-Zertifizierungsstelle. Ein interner Google-Dienst verwaltet Stammschlüssel für diese Zertifizierungsstelle. Die Stammzertifikate für diese Zertifizierungsstelle werden in den 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 auch 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 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 zur Verfügung stehen. Sie können die Logeinträge im Log-Explorer in derCloud de Confiance 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 mit entsprechenden VSAs verwenden, und die Bootintegrität jeder VM der Steuerungsebene prüfen.
Informationen zum Ausführen der VM-Integritätsprüfung finden Sie unter Integrität von GKE-Steuerungsebenen-VMs prüfen.
Konfigurationsmöglichkeiten
Die GKE verwaltet den Großteil der Steuerungsebene für Sie. Sie können jedoch 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 verwendet 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.
Rotation von Anmeldedaten: Rotieren Sie die Cluster-Zertifizierungsstelle (CA) und die TLS-Zertifikate regelmäßig, indem Sie eine Rotation von Anmeldedaten durchführen. GKE rotiert während dieses Vorgangs auch die IP-Adresse Ihres Kubernetes API-Servers. 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, die Ihnen mehr Transparenz und Kontrolle über bestimmte Aspekte der Steuerungsebene bieten, 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.