CIS-Benchmarks

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:

  • Verwaltete GKE-Steuerungsebene gemäß CIS-Kubernetes-Benchmark konfigurieren
  • 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 auf Google Cloudgelten.

Wir empfehlen, die CIS-GKE-Benchmark zu priorisieren, da sie speziell für GKE auf Google Cloudentwickelt 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 Standard-Containerlaufzeit containerd hat keine Benchmark.

Modell der geteilten Verantwortung

Gemäß dem GKE-Modell der geteilten Verantwortung verwalten wir die folgenden Komponenten für Sie:

  • Die Steuerungsebene, einschließlich ihrer VMs, API-Server und Komponenten wie die Clusterstatusdatenbank (etcd- oder Spanner-basiert), 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.
  • 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. Sie können 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.
Debugging GKE verwendet Profiling für das Debugging.
Verschlüsselung
etcd

In Open-Source-Kubernetes wird für die Clusterstatusdatenbank etcd verwendet. In GKE ist die Backend-Datenbank, in der der Clusterstatus gespeichert wird, eine der folgenden Technologien:

  • etcd: Im Cluster werden etcd-Instanzen auf der Steuerungsebene ausgeführt.
  • Spanner: GKE speichert den Clusterstatus in einer Spanner-basierten Datenbank, die von den VMs der Steuerungsebene getrennt ist.

Alle GKE-Cluster stellen die etcd-API auf VMs der Steuerungsebene bereit. Alle Clientinteraktionen mit der Kubernetes API sind dieselben wie in Open-Source-Kubernetes. Abhängig von der Datenbanktechnologie, die das Backend für die etcd-API in Ihrem Cluster ist, können Abweichungen bei der etcd-bezogenen Bewertung in der Open-Source-CIS-Kubernetes-Benchmark auftreten.
Kubelet
  • In GKE ist der nicht authentifizierte schreibgeschützte Port für Kubelet aktiviert. Sie können den Port deaktivieren, indem Sie --no-autoprovisioning-enable-insecure-kubelet-readonly-port festlegen. Der schreibgeschützte Port wird in einem zukünftigen Release standardmäßig deaktiviert, nachdem Sie etwas Zeit für die Migration hatten.
  • 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.
  • GKE verwendet den standardmäßigen Golang-Chiffresatz, der auch der Standard für Kubernetes ist.

GKE anhand der CIS-Benchmarks bewerten

Sie können die Bewertung Ihrer Cluster anhand der Benchmarks mit einer der folgenden Methoden automatisieren:

  • CIS-GKE-Benchmark:
    • 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.
  • 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.

Nächste Schritte