In diesem Dokument wird beschrieben, wie Google Kubernetes Engine (GKE) Ihre Komponenten der Clustersteuerungsebene schützt.
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 etcd-Speicher 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.
etcd-Sicherheit
In der Google Cloud werden Kundeninhalte standardmäßig auf Dateisystemebene verschlüsselt. Das gilt auch für Laufwerke, auf denen der etcd-Speicher für GKE-Cluster gehostet wird. Weitere Informationen finden Sie unter Verschlüsselung inaktiver Daten.
etcd überwacht zwei TCP-Ports. Port 2379 wird für etcd-Clients wie den Kubernetes API-Server verwendet. Port 2379 ist an die lokale Loopback-Netzwerkschnittstelle gebunden und deshalb nur über die VM zugänglich, auf der der Kubernetes API-Server ausgeführt wird. Port 2380 wird für die Server-zu-Server-Kommunikation verwendet. Traffic auf Port 2380 wird durch gegenseitige TLS-Authentifizierung verschlüsselt. Das heißt, dass jeder Server gegenüber anderen Servern seine Identität nachweisen muss. Die Kommunikation zwischen etcd-Servern zur Einrichtung eines Quorums in einem regionalen Cluster wird ebenfalls durch gegenseitige TLS-Authentifizierung verschlüsselt.
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. Jeder Cluster hat außerdem eine eigene Stammzertifizierungsstelle für etcd. Stammschlüssel für die etcd-Zertifizierungsstelle werden an die Metadaten der VMs verteilt, auf der der Kubernetes API-Server ausgeführt wird. Die Kommunikation zwischen Knoten und dem Kubernetes API-Server wird durch TLS geschützt. Weitere Informationen finden Sie unter Vertrauenswürdigkeit in Cluster.
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 diesem Thema beschriebenen Sicherheitsfunktionen werden von Google verwaltet. In diesem und im folgenden Abschnitt werden Sicherheitsfunktionen beschrieben, die Sie beobachten und konfigurieren können.
Audit-Logging ist standardmäßig für Cluster aktiviert, die ab GKE-Version 1.8.3 erstellt wurden. 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 der Google Cloud Console ansehen. Außerdem können Sie diese Logs mit BigQuery aufrufen und analysieren.
Konfigurationsmöglichkeiten
Standardmäßig nutzt der Kubernetes API-Server eine öffentliche IP-Adresse. Zum Schutz des Kubernetes API-Servers können Sie autorisierte Netzwerke und private Cluster verwenden. Dadurch können Sie dem Kubernetes API-Server eine private IP-Adresse zuweisen und den Zugriff auf die öffentliche IP-Adresse deaktivieren.
Für die Clusterauthentifizierung in GKE können Sie Cloud IAM als Identitätsanbieter verwenden. Zur Verbesserung der Authentifizierungssicherheit sind die Basisauthentifizierung und die Ausgabe von Clientzertifikaten für Cluster, die mit GKE ab Version 1.12 erstellt wurden, standardmäßig deaktiviert.
Sie können die Sicherheit der Steuerungsebene dadurch verbessern, dass Sie eine regelmäßige Rotation von Anmeldedaten durchführen. In diesem Fall werden die TLS-Zertifikate und die Cluster-Zertifizierungsstelle automatisch rotiert. Außerdem wird in GKE eine Rotation der IP-Adresse des Kubernetes API-Servers durchgeführt. Weitere Informationen finden Sie unter Rollenbasierte Zugriffssteuerung und Rotation von Anmeldedaten.