Auf dieser Seite wird der Ansatz beschrieben, mit dem die Google Kubernetes Engine (GKE) die Einhaltung der CIS-Benchmarks (Center for Internet Security) für Kubernetes und GKE verbessert. Diese Seite enthält die folgenden Informationen:
GKE-Knoten und ‑Arbeitslasten gemäß CIS-GKE-Benchmark (Google Kubernetes Engine) konfigurieren
CIS-Benchmarks
CIS veröffentlicht die folgenden Benchmarks mit Richtlinien für die sichere Konfiguration von Kubernetes:
CIS-Kubernetes-Benchmark: Gilt für das Open-Source-Kubernetes-Projekt.
Bietet eine Anleitung für eine Vielzahl von selbst verwalteten und gehosteten Kubernetes-Implementierungen.
CIS-GKE-Benchmark: Enthält Richtlinien für die sichere Konfiguration von Komponenten, die Sie in GKE-Clustern steuern können. Enthält Empfehlungen, die speziell für GKE in Google Cloud gelten.
Wir empfehlen, die CIS-GKE-Benchmark zu priorisieren, da sie speziell für GKE in Google Cloud entwickelt wurde. Die CIS-Kubernetes-Benchmark enthält viele Empfehlungen für Steuerelemente, die Sie in GKE nicht aufrufen oder ändern können. Unser Ansatz für die Clustersicherheit umfasst Maßnahmen, die über den Umfang der Open-Source-Kubernetes-Benchmark hinausgehen und zu Konflikten mit diesen Empfehlungen führen können.
Weitere Benchmarks für GKE
Zusätzlich zu der CIS-GKE-Benchmark und der CIS-Kubernetes-Benchmark gelten die folgenden Benchmarks für die in GKE verfügbaren Betriebssysteme. Auch wenn in einer bestimmten Betriebssystem-Benchmark die Kubernetes-Nutzung nicht explizit erwähnt wird, sollten Sie sich dennoch auf diese Benchmark beziehen, um zusätzliche Sicherheitsrichtlinien zu erhalten.
Die Steuerungsebene, einschließlich ihrer VMs, API-Server und Komponenten wie etcd, kube-controller-manager und kube-scheduler.
Das Betriebssystem des Knotens
Diese Komponenten befinden sich in einem GKE-Projekt. Sie können sie daher nicht ändern oder anhand der entsprechenden CIS-Benchmark-Steuerelemente bewerten. Sie können jedoch alle CIS-Benchmark-Steuerelemente prüfen und beheben, die für Ihre Worker-Knoten und Arbeitslasten gelten. Gemäß dem GKE-Modell der geteilten Verantwortung liegen diese Komponenten in Ihrer Verantwortung.
Unser Ansatz zur Sicherung von GKE für die CIS-Benchmark
GKE ist eine verwaltete Implementierung von Open-Source-Kubernetes. Wir verwalten die Steuerungsebene vollständig und sind für die Sicherheit der Konfiguration der Steuerungsebenenkomponenten verantwortlich. In der folgenden Tabelle werden einige unserer Entscheidungen beschrieben, die sich auf die Bewertung der CIS-Benchmarks auswirken können:
GKE-Sicherheitsansatz
Authentifizierung
Einige GKE-Monitoring-Komponenten verwenden die anonyme Authentifizierung, um Messwerte abzurufen. GKE erlaubt die anonyme Authentifizierung für das Kubelet. Dieses Risiko entspricht jedoch dem schreibgeschützten Port, da wir zusätzliche Debugging-Handler deaktivieren.
Das Bootstrapping einiger Komponenten der Steuerungsebene erfolgt mit statischen Tokens, die dann zur Authentifizierung beim API-Server verwendet werden. Diese Tokens werden bei jedem Start oder Neustart einer VM generiert.
Zugangs-Controller
In GKE werden die folgenden Zugangs-Controller deaktiviert:
EventRateLimit: Dies ist eine Alphafunktion in Kubernetes.
AlwaysPullImages: Dieser Controller bietet einen gewissen Schutz für private Registry-Images in nicht operativen Clustern mit mehreren Instanzen. Dafür müssen Image-Registries als Single Point of Failure zur Erstellung neuer Pods im Cluster dienen.
SecurityContextDeny: Der PodSecurity-Admission-Controller ist vorzuziehen und in allen GKE-Versionen verfügbar.
Wenn Sie GKE Enterprise verwenden, können Sie die Durchsetzung der Pod-Sicherheitsstandards auch mit Policy Controller aktivieren.
ImagePolicyWebhook: In GKE ist ImagePolicyWebhook standardmäßig deaktiviert, da es eigene Mechanismen für die Imageverwaltung und ‑sicherheit hat. So kann GKE die Umgebung strenger steuern und dafür sorgen, dass die Sicherheitspraktiken einheitlich angewendet werden.
Sie können jedoch die Binärautorisierung oder Policy Controller für die Richtlinienverwaltung verwenden.
Audit-Logging
GKE erfasst Audit-Logs gemäß der GKE-Audit-Richtlinie.
Daher müssen wir keine Flags für das Audit-Logging des Kubernetes API-Servers festlegen.
GKE verwendet mTLS für Traffic zwischen etcd-Instanzen, zwischen dem API-Server und etcd sowie zwischen der Steuerungsebene und den Knoten. Weitere Informationen finden Sie unter Cluster Trust.
Kubelet
In GKE ist der nicht authentifizierte schreibgeschützte Port für Kubelet aktiviert.
Im GKE Standard-Modus können Ihre Arbeitslasten bei Bedarf die Kernel-Standardeinstellungen ändern.
In GKE wird die Anzahl der Kubernetes-Ereignisse im Kubelet begrenzt, um das Risiko von Denial-of-Service-Angriffen zu verringern.
GKE verwendet mTLS, um den Traffic zwischen dem Kubelet und dem API-Server zu sichern.
GKE rotiert standardmäßig Serverzertifikate. Clientzertifikate werden rotiert, wenn „Shielded GKE-Knoten“ aktiviert ist.
Sie können die Bewertung Ihrer Cluster anhand der Benchmarks mit einer der folgenden Methoden automatisieren:
CIS-GKE-Benchmark:
Alle GKE-Versionen:
Führen Sie kube-bench aus, um Worker-Knoten anhand der Benchmark zu bewerten. Weitere Informationen finden Sie im GitHub-Repository von kube-bench.
Verwenden Sie ein Drittanbietertool wie Twistlock Defender, um Knoten anhand der Benchmark zu bewerten.
GKE Enterprise Edition: Mit dem Compliance-Dashboard können Sie alle Ihre Cluster auf Einhaltung der CIS-GKE-Benchmark prüfen. Weitere Informationen finden Sie unter GKE-Compliance-Dashboard.
CIS-Kubernetes-Benchmark: Führen Sie kube-bench aus, um Worker-Knoten anhand der Benchmark zu bewerten. Sie können die verwaltete Steuerungsebene nicht anhand dieser Empfehlungen in der Benchmark bewerten.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2024-12-19 (UTC)."],[],[],null,["# CIS Benchmarks\n\n[Autopilot](/kubernetes-engine/docs/concepts/autopilot-overview) [Standard](/kubernetes-engine/docs/concepts/choose-cluster-mode)\n\n*** ** * ** ***\n\nThis page describes the approach that Google Kubernetes Engine (GKE) takes to\nimprove compliance with the Center for Internet Security (CIS) benchmarks for\nKubernetes and for GKE. This page includes the following\ninformation:\n\n- How we configure the managed GKE control plane to conform to the CIS Kubernetes Benchmark\n- How you can configure your GKE nodes and workloads to conform to the CIS Google Kubernetes Engine (GKE) Benchmark\n\nAbout the CIS Benchmarks\n------------------------\n\nCIS releases the following benchmarks that contain secure configuration\nguidelines for Kubernetes:\n\n- **CIS Kubernetes Benchmark**: Applies to the open source Kubernetes project. Intended to provide guidance for a variety of self-managed and hosted Kubernetes implementations.\n- **CIS GKE Benchmark**: Establishes guidelines for the secure configuration of components you can control in GKE clusters. Includes recommendations that are specific to GKE on Google Cloud.\n\nWe recommend that you **prioritize the CIS GKE Benchmark**, because it is\nspecific to GKE on Google Cloud. The CIS Kubernetes\nBenchmark contains many recommendations for controls that you can't view or\nmodify in GKE. Our approach to cluster security includes\nmitigations that go beyond the scope of the open source Kubernetes benchmark and\nmight result in conflicts with those recommendations.\n\n### Other benchmarks that apply to GKE\n\nIn addition to the CIS GKE Benchmark and the CIS Kubernetes Benchmark, the following benchmarks apply to the operating systems that are available in GKE. Even if a specific OS benchmark doesn't explicitly address Kubernetes usage, you should still reference that benchmark for additional security guidance.\n\n- [**Container-Optimized OS Benchmark**](https://www.cisecurity.org/benchmark/google_cloud_computing_platform): the default operating system that's installed on all GKE Linux nodes\n- [**Ubuntu Linux Benchmark**](https://www.cisecurity.org/benchmark/ubuntu_linux): available for GKE Standard\n- [**Windows Server Benchmark**](https://www.cisecurity.org/benchmark/microsoft_windows_server): available for GKE Standard\n\nThe default container runtime, containerd, doesn't have a benchmark.\n\n### Shared responsibility model\n\nBased on the\n[GKE shared responsibility model](/kubernetes-engine/docs/concepts/shared-responsibility),\nwe manage the following components for you:\n\n- The control plane, including the control plane VMs, API server, and components like the cluster state database (etcd or Spanner-based), kube-controller-manager, and kube-scheduler.\n- The node operating system.\n\nThese components exist in a project that GKE owns, so you can't\nmodify or evaluate any of these components against corresponding CIS Benchmark\ncontrols. You can, however, evaluate and remediate any CIS Benchmark controls\nthat apply to your worker nodes and your workloads. Based on the\nGKE shared responsibility model, these components are your\nresponsibility.\n\nOur approach to securing GKE for the CIS Benchmark\n--------------------------------------------------\n\nGKE is a managed implementation of open source Kubernetes. We\nfully manage the control plane and are responsible for securing the\nconfiguration of control plane components. The following table describes some of\nour decisions that might affect scoring of the CIS benchmarks:\n\nEvaluate GKE against the CIS Benchmarks\n---------------------------------------\n\n| **Note:** This section mentions third-party applications like `kube-bench`. The versions of the CIS Benchmarks that these applications evaluate might not be the latest available versions. Ensure that you check which version your chosen application uses for evaluations.\n\nYou can automate evaluation of your clusters against the Benchmarks by using one\nof the following methods:\n\n- CIS GKE Benchmark:\n - Run `kube-bench` to evaluate worker nodes against the Benchmark. For details, see the [kube-bench GitHub repository](https://github.com/aquasecurity/kube-bench).\n - Use a third-party tool like Twistlock Defender to evaluate nodes against the Benchmark.\n- CIS Kubernetes Benchmark: Run `kube-bench` to evaluate worker nodes against the Benchmark. You can't evaluate the managed control plane against those recommendations in the Benchmark.\n\nWhat's next\n-----------\n\n- Read the [GKE security overview](/kubernetes-engine/docs/concepts/security-overview).\n- Follow security best practices in the [GKE hardening guide](/kubernetes-engine/docs/how-to/hardening-your-cluster).\n- Learn about monitoring your clusters for security issues with [GKE security posture](/kubernetes-engine/docs/concepts/about-security-posture-dashboard).\n- Learn how to evaluate your clusters for compliance issues in the [GKE compliance dashboard](/kubernetes-engine/fleet-management/docs/about-compliance-dashboard) for GKE Enterprise."]]
