In diesem Dokument wird erläutert, was die Kubernetes- und Google Kubernetes Engine-Benchmarks (GKE) von CIS sind, wie Sie Ihre Compliance mit den Benchmarks prüfen und was von GKE konfiguriert wird, wenn Sie eine Empfehlung nicht direkt prüfen oder implementieren können.
CIS-Benchmarks verwenden
Das Center for Internet Security (CIS) veröffentlicht Benchmarks für Best-Practice-Sicherheitsempfehlungen. Die CIS-Kubernetes-Benchmark besteht aus einer Reihe von Empfehlungen für die Konfiguration von Kubernetes, um ein hohes Sicherheitsniveau zu gewährleisten. Die Benchmark ist an einen bestimmten Kubernetes-Release gebunden. Die CIS-Kubernetes-Benchmark wurde für die Open-Source-Kubernetes-Distribution geschrieben und soll möglichst universell auf alle Distributionen anwendbar sein.
Bei einem verwalteten Service wie GKE sind Sie nicht für alle Elemente in der Benchmark verantwortlich. Außerdem gibt es Empfehlungen, die Sie nicht selbst direkt prüfen oder korrigieren können. Wenn Sie Arbeitslasten in GKE ausführen, sollten Sie daher die CIS-GKE-Benchmark verwenden. Diese ist eine untergeordnete Benchmark der CIS-Kubernetes-Benchmark, die speziell für die GKE-Distribution gilt. Sie basiert auf der vorhandenen CIS-Benchmark, allerdings wurden Elemente entfernt, die nicht vom Nutzer konfiguriert oder verwaltet werden können. Außerdem wurden zusätzliche Google Cloud-spezifische Kontrollen hinzugefügt.
Mehrere Sätze von Benchmarks
Mit GKE können Sie CIS-Benchmarks für GKE, Kubernetes, Docker, Container-Optimized OS und Linux verwenden. Aktuelle Benchmarks für diese Produkte können Sie auf der CIS-Benchmark-Website herunterladen.
Die Standard-Containerlaufzeit containerd hat keine CIS-Benchmark.
Die mit GKE verwendeten Windows Server-Knoten werden nicht anhand einer geeigneten CIS-Benchmark bewertet, da Windows Server-CIS-Benchmarks keine Kubernetes-Nutzung zulassen und die CIS-Benchmarks von Kubernetes derzeit keine Windows-Knoten unterstützen.
Einige Tools versuchen, Kubernetes-Knoten anhand von mehreren CIS-Benchmarks (z. B. Linux, Docker und Kubernetes) zu analysieren und die Ergebnisse zu kombinieren. Dies führt häufig zu verwirrenden und potenziell widersprüchlichen Ratschlägen, da diese Benchmarks nicht für die Kombination und Anwendung in einer Kubernetes-Umgebung entwickelt wurden.
Modell der geteilten Verantwortung
In GKE verwaltet Google unter dem Modell der geteilten Verantwortung die folgenden Kubernetes-Komponenten:
- Die Steuerungsebene, einschließlich ihrer VMs, des API-Servers, weiterer Komponenten auf den VMs usw.
- Die Kubernetes-Distribution
- Das Betriebssystem der Knoten
Konfigurationen in Zusammenhang mit diesen Elementen können Sie in GKE im Allgemeinen nicht prüfen oder ändern.
Sie sind aber weiterhin für das Upgrade der Knoten, die Ihre Arbeitslasten ausführen, sowie für die Arbeitslasten selbst verantwortlich. Sie können Empfehlungen für diese Komponenten generell prüfen und korrigieren.
Prüf- und Korrekturmöglichkeit
Die CIS-GKE-Benchmark basiert auf der vorhandenen CIS-Kubernetes-Benchmark, allerdings wurden Elemente entfernt, die nicht vom Nutzer konfiguriert oder verwaltet werden können. Außerdem wurden zusätzliche Google Cloud-spezifische Kontrollen hinzugefügt.
Die CIS-GKE-Benchmark umfasst folgende Abschnitte:
- Komponenten der Steuerungsebene, etcd und Konfiguration der Steuerungsebene (Abschnitte 1, 2 und 3) stammen aus der CIS-Kubernetes-Benchmark. Diese können generell nicht in GKE geprüft oder korrigiert werden.
- Worker-Knoten (Abschnitt 4) stammt aus der CIS-Kubernetes-Benchmark. Einige dieser Elemente können in GKE geprüft oder korrigiert werden, die Anleitungen variieren jedoch unter Umständen.
- Richtlinien (Abschnitt 5) stammt ebenfalls aus der CIS-Kubernetes-Benchmark. Diese lassen sich generell direkt auf GKE anwenden, ohne Änderungen an den Anleitungen.
- Verwaltete Services (Abschnitt 6) in der CIS-GKE-Benchmark ist komplett neuer Inhalt speziell für GKE. Dieser Abschnitt enthält alle Empfehlungen, die speziell für Google Cloud-Kontrollen gelten. Diese können in GKE geprüft und korrigiert werden.
Informationen zu den Elementen, die in GKE nicht geprüft oder korrigiert werden können, finden Sie im Abschnitt zu den Standardwerten. Dort wird erläutert, wie ein in GKE erstellter Standardcluster im Vergleich zur CIS-Kubernetes-Benchmark abschneidet.
Versionen
Beachten Sie, dass die Versionsnummern für verschiedene Benchmarks möglicherweise nicht identisch sind.
Dieses Dokument bezieht sich auf folgende Versionen:
| Kubernetes-Version | Version der CIS-Kubernetes-Benchmark | Version der CIS-GKE-Benchmark |
|---|---|---|
| 1.15 | 1.5.0 | 1.0.0 |
CIS-Kubernetes-Benchmark
Auf die Benchmark zugreifen
Die CIS-Kubernetes-Benchmark steht auf der CIS-Website zur Verfügung.
Empfehlungsstufen
In der CIS-Kubernetes-Benchmark:
| Level | Beschreibung |
|---|---|
| Stufe 1 | Die Empfehlungen sollen: |
| Stufe 2 | Erweitert das Profil von Stufe 1. Die Empfehlungen weisen eine oder mehrere der folgenden Eigenschaften auf: |
Empfehlungsbewertung
In der CIS-Kubernetes-Benchmark:
| Bewertungen | Beschreibung |
|---|---|
| Bewertet | Die Nichteinhaltung dieser Empfehlungen verringert den endgültigen Benchmarkwert. |
| Nicht bewertet | Die Nichteinhaltung dieser Empfehlungen verringert den endgültigen Benchmarkwert nicht. |
Evaluierung in GKE
Wir verwenden die folgenden Werte, um den Status von Kubernetes-Empfehlungen in GKE anzugeben:
| Status | Beschreibung |
|---|---|
| Bestanden | Entspricht einer Benchmarkempfehlung. |
| Nicht bestanden | Entspricht nicht einer Benchmarkempfehlung. |
| Gleichwertige Kontrolle | Entspricht nicht genau den Bedingungen in der Benchmarkempfehlung. GKE bietet jedoch andere Mechanismen, um gleichwertige Sicherheitskontrollen bereitzustellen. |
| Umgebungsabhängig | GKE konfiguriert keine Elemente im Zusammenhang mit dieser Empfehlung. Die Konfiguration des Nutzers bestimmt, ob die Umgebung einer Benchmarkempfehlung entspricht. |
Status in GKE
Wenn Sie einen neuen GKE-Cluster mit der hier angegebenen Version erstellen, schneidet er im Vergleich zur CIS-Kubernetes-Benchmark wie unten beschrieben ab.
Status des GKE-Standardclusters:
| Nr. | Empfehlung | Bewertet/Nicht bewertet | Stufe | Standardstatus |
|---|---|---|---|---|
| 1 | Komponenten der Steuerungsebene | |||
| 1.1 | Konfigurationsdateien des Knotens der Steuerungsebene | |||
| 1.1.1 | Die Berechtigungen für die Pod-Spezifikationsdatei des API-Servers sollten auf 644 festgelegt oder restriktiver sein |
Bewertet | S1 | Bestanden |
| 1.1.2 | Die Eigentümerschaft der Pod-Spezifikationsdatei des API-Servers sollte auf root:root festgelegt sein |
Bewertet | S1 | Bestanden |
| 1.1.3 | Die Berechtigungen für die Pod-Spezifikationsdatei des Controller-Managers sollten auf 644 festgelegt oder restriktiver sein |
Bewertet | S1 | Bestanden |
| 1.1.4 | Die Eigentümerschaft der Pod-Spezifikationsdatei des Controller-Managers sollte auf root:root festgelegt sein |
Bewertet | S1 | Bestanden |
| 1.1.5 | Die Berechtigungen für die Pod-Spezifikationsdatei des Planers sollten auf 644 festgelegt oder restriktiver sein |
Bewertet | S1 | Bestanden |
| 1.1.6 | Die Eigentümerschaft der Pod-Spezifikationsdatei des Planers sollte auf root:root festgelegt sein |
Bewertet | S1 | Bestanden |
| 1.1.7 | Die Berechtigungen für die Pod-Spezifikationsdatei von etcd sollten auf 644 festgelegt oder restriktiver sein |
Bewertet | S1 | Bestanden |
| 1.1.8 | Die Eigentümerschaft der Pod-Spezifikationsdatei von etcd sollte auf root:root festgelegt sein |
Bewertet | S1 | Bestanden |
| 1.1.9 | Die Berechtigungen für die Container Network Interface-Datei sollten auf 644 festgelegt oder restriktiver sein |
Nicht bewertet | S1 | Bestanden |
| 1.1.10 | Die Eigentümerschaft der Container Network Interface-Datei sollte auf root:root festgelegt sein |
Nicht bewertet | S1 | Bestanden |
| 1.1.11 | Die Berechtigungen für das etcd-Datenverzeichnis sollten auf 700 festgelegt oder restriktiver sein |
Bewertet | S1 | Bestanden |
| 1.1.12 | Die Eigentümerschaft des etcd-Datenverzeichnisses sollte auf etcd:etcd festgelegt sein |
Bewertet | S1 | Bestanden |
| 1.1.13 | Die Berechtigungen für die Datei "admin.conf" sollten auf 644 festgelegt oder restriktiver sein |
Bewertet | S1 | Bestanden |
| 1.1.14 | Die Eigentümerschaft der Datei "admin.conf" sollte auf root:root festgelegt sein |
Bewertet | S1 | Bestanden |
| 1.1.15 | Die Berechtigungen für die Datei "scheduler.conf" sollten auf 644 festgelegt oder restriktiver sein |
Bewertet | S1 | Bestanden |
| 1.1.16 | Die Eigentümerschaft der Datei "scheduler.conf" sollte auf root:root festgelegt sein |
Bewertet | S1 | Bestanden |
| 1.1.17 | Die Berechtigungen für die Datei "controller-manager.conf" sollten auf 644 festgelegt oder restriktiver sein |
Bewertet | S1 | Bestanden |
| 1.1.18 | Die Eigentümerschaft der Datei "controller-manager.conf" sollte auf root:root festgelegt sein |
Bewertet | S1 | Bestanden |
| 1.1.19 | Die Eigentümerschaft des Kubernetes-PKI-Verzeichnisses und der Kubernetes-PKI-Datei sollte auf root:root festgelegt sein |
Bewertet | S1 | Bestanden |
| 1.1.20 | Die Berechtigungen für die Kubernetes-PKI-Zertifikatsdatei sollten auf 644 festgelegt oder restriktiver sein |
Bewertet | S1 | Bestanden |
| 1.1.21 | Die Berechtigungen für die Kubernetes-PKI-Schlüsseldatei sollten auf 600 festgelegt sein |
Bewertet | S1 | Bestanden |
| 1.2 | API-Server | |||
| 1.2.1 | Das Argument "--anonymous-auth" sollte auf "false" festgelegt sein | Nicht bewertet | S1 | Nicht bestanden |
| 1.2.2 | Das Argument "--base-auth-file" sollte nicht festgelegt sein | Bewertet | S1 | Bestanden |
| 1.2.3 | Der Parameter "--token-auth-file" sollte nicht festgelegt sein | Bewertet | S1 | Nicht bestanden |
| 1.2.4 | Das Argument "--kubelet-https" sollte auf "true" festgelegt sein | Bewertet | S1 | Bestanden |
| 1.2.5 | Die Argumente "--kubelet-client-certificate" und "--kubelet-client-key" sollten entsprechend festgelegt sein | Bewertet | S1 | Bestanden |
| 1.2.6 | Das Argument "--kubelet-certificate-authority" sollte entsprechend festgelegt sein | Bewertet | S1 | Bestanden |
| 1.2.7 | Das Argument "--authorization-mode" sollte nicht auf "AlwaysAllow" festgelegt sein | Bewertet | S1 | Bestanden |
| 1.2.8 | Der Wert "Node" sollte im Argument "--authorization-mode" enthalten sein | Bewertet | S1 | Bestanden |
| 1.2.9 | Der Wert "RBAC" sollte im Argument "--authorization-mode" enthalten sein | Bewertet | S1 | Bestanden |
| 1.2.10 | Das Zugangskontroll-Plug-in "EventRateLimit" sollte festgelegt sein | Nicht bewertet | S1 | Nicht bestanden |
| 1.2.11 | Das Zugangskontroll-Plug-in "AlwaysAdmit" sollte nicht festgelegt sein | Bewertet | S1 | Bestanden |
| 1.2.12 | Das Zugangskontroll-Plug-in "AlwaysPullImages" sollte festgelegt sein | Nicht bewertet | S1 | Nicht bestanden |
| 1.2.13 | Das Zugangskontroll-Plug-in "SecurityContextDeny" sollte festgelegt sein, wenn "PodSecurityPolicy" nicht verwendet wird | Nicht bewertet | S1 | Nicht bestanden |
| 1.2.14 | Das Zugangskontroll-Plug-in "ServiceAccount" sollte festgelegt sein | Bewertet | S1 | Bestanden |
| 1.2.15 | Das Zugangskontroll-Plug-in "NamespaceLifecycle" sollte festgelegt sein | Bewertet | S1 | Bestanden |
| 1.2.16 | Das Zugangskontroll-Plug-in "PodSecurityPolicy" sollte festgelegt sein | Bewertet | S1 | Nicht bestanden |
| 1.2.17 | Das Zugangskontroll-Plug-in "NodeRestriction" sollte festgelegt sein | Bewertet | S1 | Bestanden |
| 1.2.18 | Das Argument "--insecure-bind-address" sollte nicht festgelegt sein | Bewertet | S1 | Bestanden |
| 1.2.19 | Das Argument "--insecure-port" sollte auf 0 festgelegt sein | Bewertet | S1 | Bestanden |
| 1.2.20 | Das Argument "--secure-port" sollte nicht auf 0 festgelegt sein | Bewertet | S1 | Bestanden |
| 1.2.21 | Das Argument "--profiling" sollte auf "false" festgelegt sein | Bewertet | S1 | Nicht bestanden |
| 1.2.22 | Das Argument "--audit-log-path" sollte festgelegt sein | Bewertet | S1 | Gleichwertige Kontrolle |
| 1.2.23 | Das Argument "--audit-log-maxage" sollte auf 30 oder einen angemessenen Wert festgelegt sein | Bewertet | S1 | Gleichwertige Kontrolle |
| 1.2.24 | Das Argument "--audit-log-maxbackup" sollte auf 10 oder einen angemessenen Wert festgelegt sein | Bewertet | S1 | Gleichwertige Kontrolle |
| 1.2.25 | Das Argument "--audit-log-maxsize" sollte auf 100 oder einen angemessenen Wert festgelegt sein | Bewertet | S1 | Gleichwertige Kontrolle |
| 1.2.26 | Das Argument "--request-timeout" sollte auf einen angemessenen Wert festgelegt sein | Bewertet | S1 | Bestanden |
| 1.2.27 | Das Argument "--service-account-lookup" sollte auf "true" festgelegt sein | Bewertet | S1 | Bestanden |
| 1.2.28 | Das Argument "--service-account-key-file" sollte entsprechend festgelegt sein | Bewertet | S1 | Bestanden |
| 1.2.29 | Die Argumente "--etcd-certfile" und "--etcd-keyfile" sollten entsprechend festgelegt sein | Bewertet | S1 | Nicht bestanden |
| 1.2.30 | Die Argumente "--tls-cert-file" und "--tls-private-key-file" sollten entsprechend festgelegt sein | Bewertet | S1 | Bestanden |
| 1.2.31 | Das Argument "--client-ca-file" sollte entsprechend festgelegt sein | Bewertet | S1 | Bestanden |
| 1.2.32 | Das Argument "--etcd-cafile" sollte entsprechend festgelegt sein | Bewertet | S1 | Nicht bestanden |
| 1.2.33 | Das Argument "--encryption-provider-config" sollte entsprechend festgelegt sein | Bewertet | S1 | Bestanden |
| 1.2.34 | Verschlüsselungsanbieter sollten entsprechend konfiguriert sein | Bewertet | S1 | Nicht bestanden |
| 1.2.35 | Der API-Server sollte nur starke kryptografische Chiffren verwenden | Nicht bewertet | S1 | Bestanden |
| 1.3 | Controller-Manager | |||
| 1.3.1 | Das Argument "--terminated-pod-gc-threshold" sollte auf einen angemessenen Wert festgelegt sein | Bewertet | S1 | Bestanden |
| 1.3.2 | Das Argument "--profiling" sollte auf "false" festgelegt sein | Bewertet | S1 | Nicht bestanden |
| 1.3.3 | Das Argument "--use-service-account-credentials" sollte auf "true" festgelegt sein | Bewertet | S1 | Nicht bestanden |
| 1.3.4 | Das Argument "--service-account-private-key-file" sollte entsprechend festgelegt sein | Bewertet | S1 | Bestanden |
| 1.3.5 | Das Argument "--root-ca-file" sollte entsprechend festgelegt sein | Bewertet | S1 | Bestanden |
| 1.3.6 | Das Argument "RotateKubeletServerCertificate" sollte auf "true" festgelegt sein | Bewertet | S2 | Gleichwertige Kontrolle |
| 1.3.7 | Das Argument "--bind-address" sollte auf 127.0.0.1 festgelegt sein | Bewertet | S1 | Bestanden |
| 1.4 | Planer | |||
| 1.4.1 | Das Argument "--profiling" sollte auf "false" festgelegt sein | Bewertet | S1 | Nicht bestanden |
| 1.4.2 | Das Argument "--bind-address" sollte auf 127.0.0.1 festgelegt sein | Bewertet | S1 | Bestanden |
| 2 | etcd | |||
| 2.1 | Die Argumente "--cert-file" und "--key-file" sollten entsprechend festgelegt sein | Bewertet | S1 | Nicht bestanden |
| 2.2 | Das Argument "--client-cert-auth" sollte auf "true" festgelegt sein | Bewertet | S1 | Nicht bestanden |
| 2.3 | Das Argument "--auto-tls" sollte nicht auf "true" festgelegt sein | Bewertet | S1 | Bestanden |
| 2.4 | Die Argumente "--peer-cert-file" und "--peer-key-file" sollten entsprechend festgelegt sein | Bewertet | S1 | Gleichwertige Kontrolle |
| 2.5 | Das Argument "--peer-client-cert-auth" sollte auf "true" festgelegt sein | Bewertet | S1 | Gleichwertige Kontrolle |
| 2.6 | Das Argument "--peer-auto-tls" sollte nicht auf "true" festgelegt sein | Bewertet | S1 | Gleichwertige Kontrolle |
| 2.7 | Für etcd sollte eine eindeutige Zertifizierungsstelle verwendet werden | Nicht bewertet | S2 | Bestanden |
| 3 | Konfiguration der Steuerungsebene | |||
| 3.1 | Authentifizierung und Autorisierung | |||
| 3.1.1 | Die Clientzertifikatsauthentifizierung sollte nicht für Nutzer verwendet werden | Nicht bewertet | S2 | Bestanden |
| 3.2 | Logging | |||
| 3.2.1 | Eine Audit-Mindestrichtlinie sollte erstellt werden | Bewertet | S1 | Bestanden |
| 3.2.2 | Die Audit-Richtlinie sollte wichtige Sicherheitsaspekte abdecken | Nicht bewertet | S2 | Bestanden |
| 4 | Worker-Knoten | |||
| 4.1 | Konfigurationsdateien der Worker-Knoten | |||
| 4.1.1 | Die Berechtigungen für die kubelet-Servicedatei sollten auf 644 festgelegt oder restriktiver sein |
Bewertet | S1 | Bestanden |
| 4.1.2 | Die Eigentümerschaft der kubelet-Servicedatei sollte auf root:root festgelegt sein |
Bewertet | S1 | Bestanden |
| 4.1.3 | Die Berechtigungen für die Proxy-kubeconfig-Datei sollten auf 644 festgelegt oder restriktiver sein |
Bewertet | S1 | Bestanden |
| 4.1.4 | Die Eigentümerschaft der Proxy-kubeconfig-Datei sollte auf root:root festgelegt sein |
Bewertet | S1 | Bestanden |
| 4.1.5 | Die Berechtigungen für die Datei "kubelet.conf" sollten auf 644 festgelegt oder restriktiver sein |
Bewertet | S1 | Bestanden |
| 4.1.6 | Die Eigentümerschaft der Datei "kubelet.conf" sollte auf root:root festgelegt sein |
Bewertet | S1 | Bestanden |
| 4.1.7 | Die Berechtigungen für die Zertifizierungsstellendatei sollten auf 644 festgelegt oder restriktiver sein |
Bewertet | S1 | Bestanden |
| 4.1.8 | Die Eigentümerschaft der Client-Zertifizierungsstellendatei sollte auf root:root festgelegt sein |
Bewertet | S1 | Bestanden |
| 4.1.9 | Die Berechtigungen für die kubelet-Konfigurationsdatei sollten auf 644 festgelegt oder restriktiver sein |
Bewertet | S1 | Bestanden |
| 4.1.10 | Die Eigentümerschaft der kubelet-Konfigurationsdatei sollte auf root:root festgelegt sein |
Bewertet | S1 | Bestanden |
| 4.2 | Kubelet | |||
| 4.2.1 | Das Argument "--anonymous-auth" sollte auf "false" festgelegt sein | Bewertet | S1 | Bestanden |
| 4.2.2 | Das Argument "--authorization-mode" sollte nicht auf "AlwaysAllow" festgelegt sein | Bewertet | S1 | Bestanden |
| 4.2.3 | Das Argument "--client-ca-file" sollte entsprechend festgelegt sein | Bewertet | S1 | Bestanden |
| 4.2.4 | Das Argument "--read-only-port" sollte auf 0 festgelegt sein | Bewertet | S1 | Nicht bestanden |
| 4.2.5 | Das Argument "--streaming-connection-idle-timeout" sollte nicht auf 0 festgelegt sein | Bewertet | S1 | Bestanden |
| 4.2.6 | Das Argument "--protect-kernel-defaults" sollte auf "true" festgelegt sein | Bewertet | S1 | Nicht bestanden |
| 4.2.7 | Das Argument "--make-iptables-util-chains" sollte auf "true" festgelegt sein | Bewertet | S1 | Bestanden |
| 4.2.8 | Das Argument "--hostname-override" sollte nicht festgelegt sein | Nicht bewertet | S1 | Bestanden |
| 4.2.9 | Das Argument "--event-qps" sollte auf 0 oder eine Stufe festgelegt sein, die eine geeignete Ereigniserfassung gewährleistet | Nicht bewertet | S2 | Nicht bestanden |
| 4.2.10 | Die Argumente "--tls-cert-file" und "--tls-private-key-file" sollten entsprechend festgelegt sein | Bewertet | S1 | Gleichwertige Kontrolle |
| 4.2.11 | Das Argument "--rotate-certificates" sollte nicht auf "false" festgelegt sein | Bewertet | S1 | Gleichwertige Kontrolle |
| 4.2.12 | Das Argument "RotateKubeletServerCertificate" sollte auf "true" festgelegt sein | Bewertet | S1 | Gleichwertige Kontrolle |
| 4.2.13 | Das Kubelet sollte nur starke kryptografische Chiffren verwenden | Nicht bewertet | S1 | Nicht bestanden |
| 5 | Richtlinien | |||
| 5.1 | RBAC- und Servicekonten | |||
| 5.1.1 | Die Rolle "cluster-admin" sollte nur dort verwendet werden, wo es erforderlich ist | Nicht bewertet | S1 | Umgebungsabhängig |
| 5.1.2 | Zugriff auf Secrets minimieren | Nicht bewertet | S1 | Umgebungsabhängig |
| 5.1.3 | Verwendung von Platzhaltern in "Roles" und "ClusterRoles" minimieren | Nicht bewertet | S1 | Umgebungsabhängig |
| 5.1.4 | Zugriff zum Erstellen von Pods minimieren | Nicht bewertet | S1 | Umgebungsabhängig |
| 5.1.5 | Standardservicekonten sollten nicht aktiv verwendet werden | Bewertet | S1 | Umgebungsabhängig |
| 5.1.6 | Tokens für Servicekonten sollten nur dort bereitgestellt werden, wo es erforderlich ist | Nicht bewertet | S1 | Umgebungsabhängig |
| 5.2 | Pod-Sicherheitsrichtlinien | |||
| 5.2.1 | Zugang von privilegierten Containern minimieren | Nicht bewertet | S1 | Umgebungsabhängig |
| 5.2.2 | Zugang von Containern minimieren, die den Hostprozess-ID-Namespace freigeben möchten | Bewertet | S1 | Umgebungsabhängig |
| 5.2.3 | Zugang von Containern minimieren, die den Host-IPC-Namespace freigeben möchten | Bewertet | S1 | Umgebungsabhängig |
| 5.2.4 | Zugang von Containern minimieren, die den Hostnetzwerk-Namespace freigeben möchten | Bewertet | S1 | Umgebungsabhängig |
| 5.2.5 | Zugang von Containern mit "allowPrivilegeEscalation" minimieren | Bewertet | S1 | Umgebungsabhängig |
| 5.2.6 | Zugang von Root-Containern minimieren | Nicht bewertet | S2 | Umgebungsabhängig |
| 5.2.7 | Zugang von Containern mit der NET_RAW-Funktion minimieren | Nicht bewertet | S1 | Umgebungsabhängig |
| 5.2.8 | Zugang von Containern mit hinzugefügten Funktionen minimieren | Nicht bewertet | S1 | Umgebungsabhängig |
| 5.2.9 | Zugang von Containern mit zugewiesenen Funktionen minimieren | Nicht bewertet | S2 | Umgebungsabhängig |
| 5.3 | Netzwerkrichtlinien und CNI | |||
| 5.3.1 | Das verwendete CNI sollte Netzwerkrichtlinien unterstützen | Nicht bewertet | S1 | Bestanden |
| 5.3.2 | Für alle Namespaces sollten Netzwerkrichtlinien definiert sein | Bewertet | S2 | Umgebungsabhängig |
| 5.4 | Verwaltung von Secrets | |||
| 5.4.1 | Secrets in Form von Dateien und nicht in Form von Umgebungsvariablen verwenden | Nicht bewertet | S1 | Umgebungsabhängig |
| 5.4.2 | Externen Speicher für Secrets verwenden | Nicht bewertet | S2 | Umgebungsabhängig |
| 5.5 | Erweiterbare Zugangskontrolle | |||
| 5.5.1 | Image-Herkunft mit dem Zugangs-Controller "ImagePolicyWebhook" konfigurieren | Nicht bewertet | S2 | Umgebungsabhängig |
| 5.6 | Allgemeine Richtlinien | |||
| 5.6.1 | Administrative Grenzen zwischen Ressourcen mithilfe von Namespaces erstellen | Nicht bewertet | S1 | Umgebungsabhängig |
| 5.6.2 | Das seccomp-Profil sollte in Ihren Pod-Definitionen auf "docker/default" festgelegt sein | Nicht bewertet | S2 | Umgebungsabhängig |
| 5.6.3 | Sicherheitskontext auf Ihre Pods und Container anwenden | Nicht bewertet | S2 | Umgebungsabhängig |
| 5.6.4 | Der Standard-Namespace sollte nicht verwendet werden | Bewertet | S2 | Umgebungsabhängig |
Standardwerte in GKE
Im Folgenden sind die in GKE für einen neuen GKE-Cluster verwendeten Standardwerte, die einer Empfehlung aus der CIS-Kubernetes-Benchmark nicht entsprechen, zusammen mit einer Erläuterung aufgeführt. Einige dieser Empfehlungen können mithilfe der in der CIS-GKE-Benchmark beschriebenen Verfahren korrigiert werden. Elemente, die automatisch geprüft werden können, werden in der CIS-GKE-Benchmark als "Bewertet" gekennzeichnet.
Standardwerte für Empfehlungen, die in einem GKE-Standardcluster die Prüfung nicht bestehen oder umgebungsabhängig sind:
| # | Empfehlung | Bewertet/Nicht bewertet in der CIS-Kubernetes-Benchmark |
Stufe | Standardstatus | Standardwert | Begründung | Bewertet/Nicht bewertet in der CIS-GKE-Benchmark |
|---|---|---|---|---|---|---|---|
| 1 | Komponenten der Steuerungsebene | ||||||
| 1.2 | API-Server | ||||||
| 1.2.1 | Das Argument "--anonymous-auth" sollte auf "false" festgelegt sein | Nicht bewertet | S1 | Nicht bestanden | true |
Einige GKE-Monitoring-Komponenten verwenden die anonyme Authentifizierung, um Messwerte abzurufen. Obwohl GKE die anonyme Authentifizierung für das kubelet zulässt, entspricht das Sicherheitsrisiko dem schreibgeschützten Port, da GKE die zusätzlichen Debugging-Handler deaktiviert. | Nicht bewertet |
| 1.2.3 | Der Parameter "--token-auth-file" sollte nicht festgelegt sein | Bewertet | S1 | Nicht bestanden | Festgelegt | Das Bootstrapping einiger Komponenten der Steuerungsebene erfolgt mit statischen Tokens, die dann zur Authentifizierung beim API-Server verwendet werden. | Nicht bewertet |
| 1.2.10 | Das Zugangskontroll-Plug-in "EventRateLimit" sollte festgelegt sein | Nicht bewertet | S1 | Nicht bestanden | Nicht festgelegt | GKE unterstützt den Zugangs-Controller "EventRateLimit" nicht, da dies ein Kubernetes-Alphafeature ist. | Nicht bewertet |
| 1.2.12 | Das Zugangskontroll-Plug-in "AlwaysPullImages" sollte festgelegt sein | Nicht bewertet | S1 | Nicht bestanden | Nicht festgelegt | Der AlwaysPullImages-Admission-Controller bietet einen gewissen Schutz für private Registry-Images in nicht kooperativen, mehrinstanzenfähigen Clustern, allerdings mit dem Kompromiss, dass Container Registries beim Erstellen neuer Pods für den gesamten Cluster einen Single Point Of Failure darstellen. GKE aktiviert den AlwaysPullImages-Admission-Controller nicht, sodass es im Ermessen der Clusteradministratoren liegt, diesen Kompromiss einzugehen und die Zugangsrichtlinie zu implementieren. | Nicht bewertet |
| 1.2.13 | Das Zugangskontroll-Plug-in "SecurityContextDeny" sollte festgelegt sein, wenn "PodSecurityPolicy" nicht verwendet wird | Nicht bewertet | S1 | Nicht bestanden | Nicht festgelegt | GKE aktiviert den Zugangs-Controller "SecurityContext" nicht standardmäßig. Die Verwendung einer Pod-Sicherheitsrichtlinie bietet mehr Kontrolle und ist vorzuziehen. | Nicht bewertet |
| 1.2.16 | Das Zugangskontroll-Plug-in "PodSecurityPolicy" sollte festgelegt sein | Bewertet | S1 | Nicht bestanden | Nicht festgelegt | GKE aktiviert den Zugangs-Controller "PodSecurityPolicy" nicht standardmäßig, da hierfür eine Richtlinie festgelegt werden muss. GKE-Kunden können "PodSecurityPolicy" aktivieren. | Nicht bewertet, siehe auch 6.10.3 |
| 1.2.21 | Das Argument "--profiling" sollte auf "false" festgelegt sein | Bewertet | S1 | Nicht bestanden | Nicht festgelegt | GKE verwendet Profiling für das Debugging. | Nicht bewertet |
| 1.2.22 | Das Argument "--audit-log-path" sollte festgelegt sein | Bewertet | S1 | Gleichwertige Kontrolle | Nicht definiert | GKE erfasst Audit-Logs, verwendet diese Flags jedoch nicht für Audits. Weitere Informationen finden Sie unter GKE-Audit-Richtlinie. | Nicht bewertet |
| 1.2.23 | Das Argument "--audit-log-maxage" sollte auf 30 oder einen angemessenen Wert festgelegt sein | Bewertet | S1 | Gleichwertige Kontrolle | Nicht definiert | GKE erfasst Audit-Logs, verwendet diese Flags jedoch nicht für Audits. Weitere Informationen finden Sie unter GKE-Audit-Richtlinie. | Nicht bewertet |
| 1.2.24 | Das Argument "--audit-log-maxbackup" sollte auf 10 oder einen angemessenen Wert festgelegt sein | Bewertet | S1 | Gleichwertige Kontrolle | Nicht definiert | GKE erfasst Audit-Logs, verwendet diese Flags jedoch nicht für Audits. Weitere Informationen finden Sie unter GKE-Audit-Richtlinie. | Nicht bewertet |
| 1.2.25 | Das Argument "--audit-log-maxsize" sollte auf 100 oder einen angemessenen Wert festgelegt sein | Bewertet | S1 | Gleichwertige Kontrolle | Nicht definiert | GKE erfasst Audit-Logs, verwendet diese Flags jedoch nicht für Audits. Weitere Informationen finden Sie unter GKE-Audit-Richtlinie. | Nicht bewertet |
| 1.2.29 | Die Argumente "--etcd-certfile" und "--etcd-keyfile" sollten entsprechend festgelegt sein | Bewertet | S1 | Nicht bestanden | Nicht definiert | GKE verwendet mTLS derzeit nicht, um Verbindungen zwischen dem API-Server und etcd zu schützen. "localhost" wird von etcd beobachtet. Weitere Informationen finden Sie unter Cluster Trust. | Nicht bewertet |
| 1.2.32 | Das Argument "--etcd-cafile" sollte entsprechend festgelegt sein | Bewertet | S1 | Nicht bestanden | Nicht definiert | GKE verwendet mTLS derzeit nicht, um Verbindungen zwischen dem API-Server und etcd zu schützen. "localhost" wird von etcd beobachtet. Weitere Informationen finden Sie unter Cluster Trust. | Nicht bewertet |
| 1.2.34 | Verschlüsselungsanbieter sollten entsprechend konfiguriert sein | Bewertet | S1 | Nicht bestanden | identity |
GKE verschlüsselt inaktive Kundeninhalte standardmäßig. Wenn Sie Secrets weiter verschlüsseln möchten, verwenden Sie die Verschlüsselung von Secrets auf Anwendungsebene. | Nicht bewertet, siehe auch 6.3.1 |
| 1.3 | Controller-Manager | ||||||
| 1.3.2 | Das Argument "--profiling" sollte auf "false" festgelegt sein | Bewertet | S1 | Nicht bestanden | true |
GKE verwendet Profiling für das Debugging. | Nicht bewertet |
| 1.3.6 | Das Argument "RotateKubeletServerCertificate" sollte auf "true" festgelegt sein | Bewertet | S2 | Gleichwertige Kontrolle | false |
GKE rotiert kubelet-Zertifikate, verwendet dieses Flag jedoch nicht. | Nicht bewertet |
| 1.4 | Planer | ||||||
| 1.4.1 | Das Argument "--profiling" sollte auf "false" festgelegt sein | Bewertet | S1 | Nicht bestanden | true |
GKE verwendet Profiling für das Debugging. | Nicht bewertet |
| 2 | etcd | ||||||
| 2.1 | Die Argumente "--cert-file" und "--key-file" sollten entsprechend festgelegt sein | Bewertet | S1 | Nicht bestanden | Nicht definiert | GKE verwendet mTLS derzeit nicht, um Verbindungen zwischen dem API-Server und etcd zu schützen. "localhost" wird von etcd beobachtet. Weitere Informationen finden Sie unter Cluster Trust. | Nicht bewertet |
| 2.2 | Das Argument "--client-cert-auth" sollte auf "true" festgelegt sein | Bewertet | S1 | Nicht bestanden | Nicht definiert | GKE verwendet mTLS derzeit nicht, um Verbindungen zwischen dem API-Server und etcd zu schützen. "localhost" wird von etcd beobachtet. Weitere Informationen finden Sie unter Cluster Trust. | Nicht bewertet |
| 2.4 | Die Argumente "--peer-cert-file" und "--peer-key-file" sollten entsprechend festgelegt sein | Bewertet | S1 | Gleichwertige Kontrolle | Nicht definiert | GKE verwendet mTLS für Peer-Traffic zwischen Instanzen von etcd. Diese Flags werden für regionale Cluster, jedoch nicht für zonale Cluster verwendet, da es in einem zonalen Cluster nur eine Instanz von etcd gibt. Weitere Informationen finden Sie unter Cluster Trust. | Nicht bewertet |
| 2.5 | Das Argument "--peer-client-cert-auth" sollte auf "true" festgelegt sein | Bewertet | S1 | Gleichwertige Kontrolle | Nicht definiert | GKE verwendet mTLS für Peer-Traffic zwischen Instanzen von etcd. Diese Flags werden für regionale Cluster, jedoch nicht für zonale Cluster verwendet, da es in einem zonalen Cluster nur eine Instanz von etcd gibt. Weitere Informationen finden Sie unter Cluster Trust. | Nicht bewertet |
| 2.6 | Das Argument "--peer-auto-tls" sollte nicht auf "true" festgelegt sein | Bewertet | S1 | Gleichwertige Kontrolle | Nicht definiert | GKE verwendet mTLS für Peer-Traffic zwischen Instanzen von etcd. Diese Flags werden für regionale Cluster, jedoch nicht für zonale Cluster verwendet, da es in einem zonalen Cluster nur eine Instanz von etcd gibt. Weitere Informationen finden Sie unter Cluster Trust. | Nicht bewertet |
| 4 | Worker-Knoten | ||||||
| 4.2 | Kubelet | ||||||
| 4.2.4 | Das Argument "--read-only-port" sollte auf 0 festgelegt sein | Bewertet | S1 | Nicht bestanden | 10255 |
Einige GKE-Monitoring-Komponenten verwenden den schreibgeschützten kubelet-Port, um Messwerte abzurufen. | Bewertet |
| 4.2.6 | Das Argument "--protect-kernel-defaults" sollte auf "true" festgelegt sein | Bewertet | S1 | Nicht bestanden | false |
GKE schützt die Kernel-Standardeinstellungen von Kubernetes nicht, da diese für Kundenarbeitslasten möglicherweise geändert werden sollen. | Bewertet |
| 4.2.9 | Das Argument "--event-qps" sollte auf 0 oder eine Stufe festgelegt sein, die eine geeignete Ereigniserfassung gewährleistet | Nicht bewertet | S2 | Nicht bestanden | 5 |
Ereignisse sind Kubernetes-Objekte, die in etcd gespeichert sind. Damit eine Überlastung von etcd vermieden wird, werden sie nur eine Stunde lang aufbewahrt. Sie sind daher kein geeigneter Mechanismus für Sicherheits-Audits. Das Zulassen von unbegrenzten Ereignissen, wie in dieser Kontrolle vorgeschlagen, setzt den Cluster einem unnötigen DoS-Risiko aus und widerspricht der Empfehlung zur Verwendung von Zugangs-EventRateLimits. Sicherheitsrelevante Ereignisse, die dauerhaft gespeichert werden müssen, sollten an Logs gesendet werden. | Bewertet |
| 4.2.10 | Die Argumente "--tls-cert-file" und "--tls-private-key-file" sollten entsprechend festgelegt sein | Bewertet | S1 | Gleichwertige Kontrolle | Nicht festgelegt | GKE verwendet mTLS für den Traffic vom kubelet zum API-Server. Für den Traffic vom API-Server zum kubelet verwendet GKE TLS. Der Traffic wird für GKE-Cluster ab Version 1.12 authentifiziert. GKE verwendet diese Flags nicht. Dies wird stattdessen in der kubelet-Konfigurationsdatei angegeben. Weitere Informationen finden Sie unter Cluster Trust. | Bewertet |
| 4.2.11 | Das Argument "--rotate-certificates" sollte nicht auf "false" festgelegt sein | Bewertet | S1 | Gleichwertige Kontrolle | Nicht definiert | GKE rotiert Serverzertifikate für GKE-Cluster ab Version 1.12. Diese Flags werden in GKE nicht verwendet, sondern in der kubelet-Konfigurationsdatei angegeben. GKE rotiert Clientzertifikate nur, wenn Shielded GKE-Knoten aktiviert sind. In diesem Fall verwendet GKE diese Flags nicht, sondern führt einen separaten Prozess für die Zertifikatsrotation aus. Weitere Informationen finden Sie unter Cluster Trust. | Bewertet |
| 4.2.12 | Das Argument "RotateKubeletServerCertificate" sollte auf "true" festgelegt sein | Bewertet | S1 | Gleichwertige Kontrolle | Nicht definiert | GKE rotiert Serverzertifikate für GKE-Cluster ab Version 1.12. Diese Flags werden in GKE nicht verwendet, sondern in der kubelet-Konfigurationsdatei angegeben. Weitere Informationen finden Sie unter Cluster Trust. | Bewertet |
| 4.2.13 | Das Kubelet sollte nur starke kryptografische Chiffren verwenden. | Nicht bewertet | Nicht bestanden | Nicht festgelegt | GKE verwendet den standardmäßigen Golang-Chiffresatz, der von den Golang-Kryptografieexperten als sicher eingestuft wird. Außerdem ist er der Standard für Kubernetes. | Nicht bewertet | |
| 5 | Richtlinien | ||||||
| 5.1 | RBAC- und Servicekonten | ||||||
| 5.1.1 | Die Rolle "cluster-admin" sollte nur dort verwendet werden, wo es erforderlich ist | Nicht bewertet | S1 | Umgebungsabhängig | – | Nicht bewertet | |
| 5.1.2 | Zugriff auf Secrets minimieren | Nicht bewertet | S1 | Umgebungsabhängig | – | Nicht bewertet | |
| 5.1.3 | Verwendung von Platzhaltern in "Roles" und "ClusterRoles" minimieren | Nicht bewertet | S1 | Umgebungsabhängig | – | Nicht bewertet | |
| 5.1.4 | Zugriff zum Erstellen von Pods minimieren | Nicht bewertet | S1 | Umgebungsabhängig | – | Nicht bewertet | |
| 5.1.5 | Standardservicekonten sollten nicht aktiv verwendet werden | Bewertet | S1 | Umgebungsabhängig | – | Bewertet | |
| 5.1.6 | Tokens für Servicekonten sollten nur dort bereitgestellt werden, wo es erforderlich ist | Nicht bewertet | S1 | Umgebungsabhängig | – | Nicht bewertet | |
| 5.2 | Pod-Sicherheitsrichtlinien | ||||||
| 5.2.1 | Zugang von privilegierten Containern minimieren | Nicht bewertet | S1 | Umgebungsabhängig | – | Standardmäßig ist keine Pod-Sicherheitsrichtlinie festgelegt. | Bewertet |
| 5.2.2 | Zugang von Containern minimieren, die den Hostprozess-ID-Namespace freigeben möchten | Bewertet | S1 | Umgebungsabhängig | – | Standardmäßig ist keine Pod-Sicherheitsrichtlinie festgelegt. | Bewertet |
| 5.2.3 | Zugang von Containern minimieren, die den Host-IPC-Namespace freigeben möchten | Bewertet | S1 | Umgebungsabhängig | – | Standardmäßig ist keine Pod-Sicherheitsrichtlinie festgelegt. | Bewertet |
| 5.2.4 | Zugang von Containern minimieren, die den Hostnetzwerk-Namespace freigeben möchten | Bewertet | S1 | Umgebungsabhängig | – | Standardmäßig ist keine Pod-Sicherheitsrichtlinie festgelegt. | Bewertet |
| 5.2.5 | Zugang von Containern mit "allowPrivilegeEscalation" minimieren | Bewertet | S1 | Umgebungsabhängig | – | Standardmäßig ist keine Pod-Sicherheitsrichtlinie festgelegt. | Bewertet |
| 5.2.6 | Zugang von Root-Containern minimieren | Nicht bewertet | S2 | Umgebungsabhängig | – | Standardmäßig ist keine Pod-Sicherheitsrichtlinie festgelegt. | Bewertet |
| 5.2.7 | Zugang von Containern mit der NET_RAW-Funktion minimieren | Nicht bewertet | S1 | Umgebungsabhängig | – | Standardmäßig ist keine Pod-Sicherheitsrichtlinie festgelegt. | Bewertet |
| 5.2.8 | Zugang von Containern mit hinzugefügten Funktionen minimieren | Nicht bewertet | S1 | Umgebungsabhängig | – | Standardmäßig ist keine Pod-Sicherheitsrichtlinie festgelegt. | Bewertet |
| 5.2.9 | Zugang von Containern mit zugewiesenen Funktionen minimieren | Nicht bewertet | S2 | Umgebungsabhängig | – | Standardmäßig ist keine Pod-Sicherheitsrichtlinie festgelegt. | Bewertet |
| 5.3 | Netzwerkrichtlinien und CNI | ||||||
| 5.3.2 | Für alle Namespaces sollten Netzwerkrichtlinien definiert sein | Bewertet | S2 | Umgebungsabhängig | – | Bewertet | |
| 5.4 | Verwaltung von Secrets | ||||||
| 5.4.1 | Secrets in Form von Dateien und nicht in Form von Umgebungsvariablen verwenden | Nicht bewertet | S1 | Umgebungsabhängig | – | Nicht bewertet | |
| 5.4.2 | Externen Speicher für Secrets verwenden | Nicht bewertet | S2 | Umgebungsabhängig | – | Nicht bewertet | |
| 5.5 | Erweiterbare Zugangskontrolle | ||||||
| 5.5.1 | Image-Herkunft mit dem Zugangs-Controller "ImagePolicyWebhook" konfigurieren | Nicht bewertet | S2 | Umgebungsabhängig | Nicht aktiviert | GKE aktiviert den Zugangs-Controller "ImagePolicyWebhook" nicht standardmäßig. Die Verwendung der Binärautorisierung für die Image-Herkunft ist nicht standardmäßig festgelegt, da hierfür eine Richtlinie eingerichtet werden muss. | Nicht bewertet, siehe auch 6.10.5 |
| 5.6 | Allgemeine Richtlinien | ||||||
| 5.6.1 | Administrative Grenzen zwischen Ressourcen mithilfe von Namespaces erstellen | Nicht bewertet | S1 | Umgebungsabhängig | – | Nicht bewertet | |
| 5.6.2 | Das seccomp-Profil sollte in Ihren Pod-Definitionen auf "docker/default" festgelegt sein | Nicht bewertet | S2 | Umgebungsabhängig | – | Standardmäßig ist kein seccomp-Profil festgelegt. | Nicht bewertet |
| 5.6.3 | Sicherheitskontext auf Ihre Pods und Container anwenden | Nicht bewertet | S2 | Umgebungsabhängig | – | Standardmäßig ist kein Sicherheitskontext festgelegt. | Nicht bewertet |
| 5.6.4 | Der Standard-Namespace sollte nicht verwendet werden | Bewertet | S2 | Umgebungsabhängig | – | Bewertet |
CIS-GKE-Benchmark
Auf die Benchmark zugreifen
Die CIS-GKE-Benchmark steht auf der CIS-Website zur Verfügung:
- Rufen Sie die vollständige Liste der CIS-Benchmarks auf.
- Klicken Sie unter der Überschrift "Kubernetes" auf Expand to see related content.
- Die CIS-GKE-Benchmark wird in der Liste der Downloads aufgeführt.
Empfehlungsstufen
In der CIS-GKE-Benchmark:
| Stufe | Beschreibung |
|---|---|
| Stufe 1 | Empfehlungen sollen allgemein anwendbar sein. Diese Empfehlungen sollten auf fast alle Umgebungen angewendet werden. |
| Stufe 2 | Empfehlungen führen zu einer stringenteren Sicherheitsumgebung, sind jedoch nicht unbedingt auf alle Fälle anwendbar. Sie können sich auf die Leistung auswirken oder möglicherweise nicht zusammen mit anderen Empfehlungen angewendet werden. Diese Empfehlungen sollten vor der Anwendung für Ihre Umgebung evaluiert werden. In einigen Fällen, z. B. bei Arbeitslasten für mehrere Mandanten, sind diese Empfehlungen möglicherweise relevanter. |
Empfehlungsbewertung
In der CIS-GKE-Benchmark:
| Bewertungen | Beschreibung |
|---|---|
| Bewertet |
Empfehlungen können mit einer automatisierten Methode einfach getestet werden und haben einen Wert, der definitiv evaluiert werden kann. Diese Empfehlungen beziehen sich nur auf allgemein verfügbare Produkte oder Features. |
| Nicht bewertet |
Empfehlungen lassen sich nicht einfach automatisch bewerten oder müssen evaluiert werden, um die genaue Implementierung für Ihre Arbeitslast zu bestimmen. Diese Empfehlungen können sich auf Produkte oder Features in der Betaversion beziehen. Für Pod-Sicherheitsrichtlinie muss beispielsweise eine Richtlinie speziell für Ihre Arbeitslast verwendet werden. Außerdem ist dies ein Betafeature und damit nicht bewertet. |
Evaluierung in GKE
Da alle GKE-spezifischen Empfehlungen (Abschnitt 6) so konfigurierbar sind, dass sie die Prüfung in Ihrer Umgebung bestehen, verwenden wir die folgenden Werte zur Angabe der Standardwerte:
| Status | Beschreibung |
|---|---|
| Standard | Ein neuer Cluster entspricht standardmäßig einer Benchmark-Empfehlung. |
| Keine Standardeinstellung | Ein neuer Cluster entspricht nicht standardmäßig einer Benchmark-Empfehlung. |
| Umgebungsabhängig | GKE konfiguriert keine Elemente im Zusammenhang mit dieser Empfehlung. Die Konfiguration des Nutzers bestimmt, ob die Umgebung einer Benchmarkempfehlung entspricht. |
Standardwerte in GKE
Wenn Sie einen neuen GKE-Cluster mit der hier angegebenen Version erstellen, schneidet er im Vergleich zur CIS-Kubernetes-Benchmark wie unten beschrieben ab.
Status des GKE-Standardclusters:
| Nr. | Empfehlung | Bewertet/Nicht bewertet | Stufe | Standardstatus |
|---|---|---|---|---|
| 6 | Verwaltete Services | |||
| 6.1 | Image-Registry und Image-Scans | |||
| 6.1.1 | Images sollten mithilfe von GCR Container Analysis oder einem Drittanbieter auf Sicherheitslücken gescannt werden | Bewertet | S1 | Keine Standardeinstellung |
| 6.1.2 | Nutzerzugriff auf GCR minimieren | Bewertet | S1 | Umgebungsabhängig |
| 6.1.3 | Clusterzugriff für GCR auf Lesezugriff minimieren | Bewertet | S1 | Keine Standardeinstellung |
| 6.1.4 | Container-Registries auf genehmigte Registries minimieren | Nicht bewertet | S2 | Keine Standardeinstellung |
| 6.2 | Identitäts- und Zugriffsverwaltung | |||
| 6.2.1 | GKE-Cluster nicht mit dem Compute Engine-Standardservicekonto ausführen | Bewertet | S2 | Keine Standardeinstellung |
| 6.2.2 | Dedizierte Google Cloud-Dienstkonten und Workload Identity verwenden | Nicht bewertet | S1 | Keine Standardeinstellung |
| 6.3 | Cloud Key Management Service (Cloud KMS) | |||
| 6.3.1 | Kubernetes-Secrets mit Schlüsseln verschlüsseln, die in Cloud KMS verwaltet werden | Bewertet | S1 | Keine Standardeinstellung |
| 6.4 | Knotenmetadaten | |||
| 6.4.1 | Legacy-Instanzmetadaten-APIs sollten in Compute Engine deaktiviert sein | Bewertet | S1 | Standardeinstellung |
| 6.4.2 | Der GKE-Metadatenserver sollte aktiviert sein | Nicht bewertet | S2 | Keine Standardeinstellung |
| 6.5 | Knotenkonfiguration und -pflege | |||
| 6.5.1 | Container-Optimized OS (COS) sollte für GKE-Knoten-Images verwendet werden | Bewertet | S2 | Standardeinstellung |
| 6.5.2 | Automatische Knotenreparaturen sollten für GKE-Knoten aktiviert sein | Bewertet | S1 | Standardeinstellung |
| 6.5.3 | Automatische Knotenupgrades sollten für GKE-Knoten aktiviert sein | Bewertet | S1 | Standardeinstellung |
| 6.5.4 | GKE-Versionsverwaltung mithilfe von Release-Versionen automatisieren | Nicht bewertet | S1 | Keine Standardeinstellung |
| 6.5.5 | Shielded GKE-Knoten sollten aktiviert sein | Nicht bewertet | S1 | Keine Standardeinstellung |
| 6.5.6 | Integritäts-Monitoring für Shielded GKE-Knoten sollte aktiviert sein | Nicht bewertet | S1 | Keine Standardeinstellung |
| 6.5.7 | Secure Boot sollte für Shielded GKE-Knoten aktiviert sein | Nicht bewertet | S2 | Keine Standardeinstellung |
| 6.6 | Clusternetzwerk | |||
| 6.6.1 | VPC-Flusslogs und knoteninterne Sichtbarkeit aktivieren | Nicht bewertet | S2 | Keine Standardeinstellung |
| 6.6.2 | VPC-native Cluster bevorzugen | Bewertet | S1 | Keine Standardeinstellung |
| 6.6.3 | Autorisierte Masternetzwerke sollten aktiviert sein | Bewertet | S1 | Keine Standardeinstellung |
| 6.6.4 | Cluster sollten mit aktiviertem privatem Endpunkt und deaktiviertem öffentlichem Zugriff erstellt werden | Bewertet | S2 | Keine Standardeinstellung |
| 6.6.5 | Cluster sollten mit privaten Knoten erstellt werden | Bewertet | S1 | Keine Standardeinstellung |
| 6.6.6 | Firewall für GKE-Worker-Knoten erstellen | Nicht bewertet | S1 | Keine Standardeinstellung |
| 6.6.7 | Netzwerkrichtlinie sollte aktiviert und entsprechend eingerichtet sein | Nicht bewertet | S1 | Keine Standardeinstellung |
| 6.6.8 | Von Google verwaltete SSL-Zertifikate verwenden | Nicht bewertet | S2 | Umgebungsabhängig |
| 6.7 | Logging | |||
| 6.7.1 | Stackdriver Kubernetes Logging und Monitoring sollten aktiviert sein | Bewertet | S1 | Standardeinstellung |
| 6.7.2 | Linux-auditd-Logging aktivieren | Nicht bewertet | S2 | Keine Standardeinstellung |
| 6.8 | Authentifizierung und Autorisierung | |||
| 6.8.1 | Die Basisauthentifizierung mit statischen Passwörtern sollte deaktiviert sein | Bewertet | S1 | Standardeinstellung |
| 6.8.2 | Die Authentifizierung mit Clientzertifikaten sollte deaktiviert sein | Bewertet | S1 | Standardeinstellung |
| 6.8.3 | Kubernetes RBAC-Nutzer mit Google Groups for RBAC verwalten | Nicht bewertet | S2 | Keine Standardeinstellung |
| 6.8.4 | Die Legacy-Autorisierung (ABAC) sollte deaktiviert sein | Bewertet | S1 | Standardeinstellung |
| 6.9 | Speicher | |||
| 6.9.1 | Vom Kunden verwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEK) für nichtflüchtige Speicher in GKE aktivieren | Nicht bewertet | S1 | Keine Standardeinstellung |
| 6.10 | Andere Clusterkonfigurationen | |||
| 6.10.1 | Die Kubernetes-Web-UI sollte deaktiviert sein | Bewertet | S1 | Standardeinstellung |
| 6.10.2 | Alphacluster sollten nicht für Produktionsarbeitslasten verwendet werden | Bewertet | S1 | Standardeinstellung |
| 6.10.3 | Die Pod-Sicherheitsrichtlinie sollte aktiviert und entsprechend eingerichtet sein | Nicht bewertet | S1 | Keine Standardeinstellung |
| 6.10.4 | GKE Sandbox zum Ausführen von nicht vertrauenswürdigen Arbeitslasten verwenden | Nicht bewertet | S2 | Keine Standardeinstellung |
| 6.10.5 | Binärautorisierung aktivieren und Richtlinie entsprechend konfigurieren | Nicht bewertet | S2 | Keine Standardeinstellung |
| 6.10.6 | Cloud Security Command Center (Cloud SCC) aktivieren | Nicht bewertet | S1 | Keine Standardeinstellung |
Benchmarks prüfen
Spezifische Anleitungen für die Prüfung der einzelnen Empfehlungen sind im Rahmen der entsprechenden CIS-Benchmark verfügbar. Vielleicht möchten Sie aber verschiedene Prüfungen automatisieren, um die Verifizierung dieser Kontrollen in Ihrer Umgebung zu vereinfachen. Die unten aufgeführten Tools können Ihnen dabei helfen.
Es können damit allerdings keine Empfehlungen aus der Kubernetes-CIS-Benchmark geprüft werden, die sich in GKE nicht prüfen lassen. Informationen zu Komponenten, die nicht direkt geprüft werden können, finden Sie unter Standardwerte. Dort erfahren Sie, welche Elemente in Ihrer Umgebung bereits von GKE konfiguriert wurden.
Automatisierte Prüfung der CIS-Kubernetes-Benchmark
Sie können das Open-Source-Tool kube-bench verwenden, um Ihre Clusterkonfiguration anhand der CIS-Kubernetes-Benchmark zu testen. kube-bench master-Tests können nicht für Ihre GKE-Arbeitslasten ausgeführt werden, da Sie keinen direkten Zugriff auf den Knoten der Steuerungsebene haben. Sie können nur kube-bench node-Tests ausführen.
Sie müssen unbedingt die richtige Version angeben, zum Beispiel:
kube-bench node --benchmark cis-1.5
Automatisierte Prüfung der CIS-GKE-Benchmark
Security Health Analytics erkennt gängige Konfigurationsfehler in Ihrer Umgebung, beispielsweise offene Firewalls oder öffentliche Buckets. Dies schließt GKE-Sicherheitsempfehlungen ein. Wenn Sie Security Health Analytics aktivieren, werden Sie im Cloud Security Command Center über fehlerhafte Clusterkonfigurationen informiert.
Security Health Analytics liefert für viele der in Stufe 1 bewerteten Empfehlungen entsprechende Ergebnisse.
| # | Empfehlung | Bewertet/Nicht bewertet | Stufe | Ergebnis(se) von Security Health Analytics |
|---|---|---|---|---|
| 6.1 | Image-Registry und Image-Scans | |||
| 6.1.1 | Images sollten mithilfe von GCR Container Analysis oder einem Drittanbieter auf Sicherheitslücken gescannt werden | Bewertet | S1 | – |
| 6.1.2 | Nutzerzugriff auf GCR minimieren | Bewertet | S1 | – |
| 6.1.3 | Clusterzugriff für GCR auf Lesezugriff minimieren | Bewertet | S1 | – |
| 6.1.4 | Container-Registries auf genehmigte Registries minimieren | Nicht bewertet | S2 | – |
| 6.2 | Identitäts- und Zugriffsverwaltung | |||
| 6.2.1 | GKE-Cluster nicht mit dem Compute Engine-Standardservicekonto ausführen | Bewertet | S2 | OVER_PRIVILEGED_ACCOUNT und OVER_PRIVILEGED_SCOPES |
| 6.2.2 | Dedizierte Google Cloud-Dienstkonten und Workload Identity verwenden | Nicht bewertet | S1 | WORKLOAD_IDENTITY_DISABLED |
| 6.3 | Cloud Key Management Service (Cloud KMS) | |||
| 6.3.1 | Kubernetes-Secrets mit Schlüsseln verschlüsseln, die in Cloud KMS verwaltet werden | Bewertet | S1 | – |
| 6.4 | Knotenmetadaten | |||
| 6.4.1 | Legacy-Instanzmetadaten-APIs sollten in Compute Engine deaktiviert sein | Bewertet | S1 | LEGACY_METADATA_ENABLED |
| 6.4.2 | Der GKE-Metadatenserver sollte aktiviert sein | Nicht bewertet | S2 | – |
| 6.5 | Knotenkonfiguration und -pflege | |||
| 6.5.1 | Container-Optimized OS (COS) sollte für GKE-Knoten-Images verwendet werden | Bewertet | S2 | COS_NOT_USED |
| 6.5.2 | Automatische Knotenreparaturen sollten für GKE-Knoten aktiviert sein | Bewertet | S1 | AUTO_REPAIR_DISABLED |
| 6.5.3 | Automatische Knotenupgrades sollten für GKE-Knoten aktiviert sein | Bewertet | S1 | AUTO_UPGRADE_DISABLED |
| 6.5.4 | GKE-Versionsverwaltung mithilfe von Release-Versionen automatisieren | Nicht bewertet | S1 | – |
| 6.5.5 | Shielded GKE-Knoten sollten aktiviert sein | Nicht bewertet | S1 | – |
| 6.5.6 | Integritäts-Monitoring für Shielded GKE-Knoten sollte aktiviert sein | Nicht bewertet | S1 | – |
| 6.5.7 | Secure Boot sollte für Shielded GKE-Knoten aktiviert sein | Nicht bewertet | S2 | – |
| 6.6 | Clusternetzwerk | |||
| 6.6.1 | VPC-Flusslogs und knoteninterne Sichtbarkeit aktivieren | Nicht bewertet | S2 | FLOW_LOGS_DISABLED |
| 6.6.2 | VPC-native Cluster bevorzugen | Bewertet | S1 | IP_ALIAS_DISABLED |
| 6.6.3 | Autorisierte Masternetzwerke sollten aktiviert sein | Bewertet | S1 | MASTER_AUTHORIZED_NETWORKS_DISABLED |
| 6.6.4 | Cluster sollten mit aktiviertem privatem Endpunkt und deaktiviertem öffentlichem Zugriff erstellt werden | Bewertet | S2 | – |
| 6.6.5 | Cluster sollten mit privaten Knoten erstellt werden | Bewertet | S1 | PRIVATE_CLUSTER_DISABLED |
| 6.6.6 | Firewall für GKE-Worker-Knoten erstellen | Nicht bewertet | S1 | – |
| 6.6.7 | Netzwerkrichtlinie sollte aktiviert und entsprechend eingerichtet sein | Nicht bewertet | S1 | NETWORK_POLICY_DISABLED |
| 6.6.8 | Von Google verwaltete SSL-Zertifikate verwenden | Nicht bewertet | S2 | – |
| 6.7 | Logging | |||
| 6.7.1 | Stackdriver Kubernetes Logging und Monitoring sollten aktiviert sein | Bewertet | S1 | CLUSTER_LOGGING_DISABLED und CLUSTER_MONITORING_DISABLED |
| 6.7.2 | Linux-auditd-Logging aktivieren | Nicht bewertet | S2 | – |
| 6.8 | Authentifizierung und Autorisierung | |||
| 6.8.1 | Die Basisauthentifizierung mit statischen Passwörtern sollte deaktiviert sein | Bewertet | S1 | – |
| 6.8.2 | Die Authentifizierung mit Clientzertifikaten sollte deaktiviert sein | Bewertet | S1 | – |
| 6.8.3 | Kubernetes RBAC-Nutzer mit Google Groups for RBAC verwalten | Nicht bewertet | S2 | – |
| 6.8.4 | Die Legacy-Autorisierung (ABAC) sollte deaktiviert sein | Bewertet | S1 | LEGACY_AUTHORIZATION_ENABLED |
| 6.9 | Speicher | |||
| 6.9.1 | Vom Kunden verwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEK) für nichtflüchtige Speicher in GKE aktivieren | Nicht bewertet | S1 | – |
| 6.10 | Andere Clusterkonfigurationen | |||
| 6.10.1 | Die Kubernetes-Web-UI sollte deaktiviert sein | Bewertet | S1 | WEB_UI_ENABLED |
| 6.10.2 | Alphacluster sollten nicht für Produktionsarbeitslasten verwendet werden | Bewertet | S1 | – |
| 6.10.3 | Die Pod-Sicherheitsrichtlinie sollte aktiviert und entsprechend eingerichtet sein | Nicht bewertet | S1 | POD_SECURITY_POLICY_DISABLED |
| 6.10.4 | GKE Sandbox zum Ausführen von nicht vertrauenswürdigen Arbeitslasten verwenden | Nicht bewertet | S2 | – |
| 6.10.5 | Binärautorisierung aktivieren und Richtlinie entsprechend konfigurieren | Nicht bewertet | S2 | – |
| 6.10.6 | Cloud Security Command Center (Cloud SCC) aktivieren | Nicht bewertet | S1 | – |
Nächste Schritte
- Übersicht zur GKE-Sicherheit lesen
- Best Practices für die Sicherheit im Leitfaden zum Härten von GKE beachten
- Mehr über das Modell der geteilten Verantwortung in GKE erfahren