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 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 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 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.
Debugging GKE verwendet Profiling für das Debugging.
Verschlüsselung
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.
  • 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:

    • 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.

Nächste Schritte