In diesem Dokument wird die CIS Kubernetes Benchmark vorgestellt. Außerdem erfahren Sie, wie Sie die Compliance mit der Benchmark prüfen und was Google Distributed Cloud (GDC) Air-Gapped konfiguriert, wenn Sie eine Empfehlung nicht selbst implementieren können.
CIS-Benchmarks
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.
Auf die Benchmark zugreifen
Die CIS-Kubernetes-Benchmark steht auf der CIS-Website zur Verfügung.
Empfehlungsstufen
In der folgenden Tabelle werden die Empfehlungsstufen in der CIS-Kubernetes-Benchmark beschrieben.
| Level | Beschreibung |
|---|---|
| Stufe 1 | Die Empfehlungen weisen eine oder mehrere der folgenden Eigenschaften auf: |
| Stufe 2 | Erweitert das Profil von Stufe 1. Die Empfehlungen weisen eine oder mehrere der folgenden Eigenschaften auf: |
Prüfungsstatus
Für jede Empfehlung wird ein Bewertungsstatus angegeben. Der Prüfungsstatus gibt an, ob die angegebene Empfehlung automatisiert werden kann oder ob manuelle Schritte erforderlich sind. Beide Status sind gleichermaßen wichtig und werden wie in den folgenden Tabellen angegeben bestimmt und unterstützt.
Versionen
Die Bewertung bezieht sich auf die folgenden Versionen:
| GDC on Bare Metal-Version | Kubernetes-Version | Version der CIS-Kubernetes-Benchmark |
|---|---|---|
| 1,30 | 1.30.9 | v0.10.4 |
Status des GDC-Kubernetes-Clusters ohne Internetverbindung
| # | Empfehlung | Level | Status |
|---|---|---|---|
| 1 | Sicherheitskonfiguration der Steuerungsebene | ||
| 1.1 | Konfigurationsdateien des Knotens der Steuerungsebene | ||
| 1.1.1 | Achten Sie darauf, dass die Berechtigungen für die Pod-Spezifikationsdatei des API-Servers auf 600 oder restriktiver festgelegt sind (automatisiert). |
S1 | Bestanden |
| 1.1.2 | Achten Sie darauf, dass die Eigentümerschaft für die Pod-Spezifikationsdatei des API-Servers auf root:root festgelegt ist (automatisiert). |
S1 | Bestanden |
| 1.1.3 | Achten Sie darauf, dass die Berechtigungen für die Pod-Spezifikationsdatei des Controller-Managers auf 600 oder restriktiver festgelegt sind (automatisiert). |
S1 | Bestanden |
| 1.1.4 | Achten Sie darauf, dass die Eigentümerschaft für die Pod-Spezifikationsdatei des Controller-Managers auf root:root festgelegt ist (automatisiert). |
S1 | Bestanden |
| 1.1.5 | Achten Sie darauf, dass die Berechtigungen für die Pod-Spezifikationsdatei des Planers auf 600 oder restriktiver festgelegt sind (automatisiert). |
S1 | Bestanden |
| 1.1.6 | Achten Sie darauf, dass die Eigentümerschaft für die Pod-Spezifikationsdatei des Planers auf root:root festgelegt ist (automatisiert). |
S1 | Bestanden |
| 1.1.7 | Achten Sie darauf, dass die Berechtigungen für die Pod-Spezifikationsdatei von etcd auf 600 oder restriktiver festgelegt sind (automatisiert). |
S1 | Bestanden |
| 1.1.8 | Achten Sie darauf, dass die Eigentümerschaft für die Pod-Spezifikationsdatei von etcd auf root:root festgelegt ist (automatisiert). |
S1 | Bestanden |
| 1.1.9 | Achten Sie darauf, dass die Berechtigungen für die Container Network Interface-Datei auf 600 oder restriktiver festgelegt sind (manuell). |
S1 | Warnen |
| 1.1.10 | Achten Sie darauf, dass Eigentümerschaft für die Container Network Interface-Datei auf root:root festgelegt ist (manuell). |
S1 | Warnen |
| 1.1.11 | Achten Sie darauf, dass die Berechtigungen für das etcd-Datenverzeichnis auf 700 oder restriktiver festgelegt sind (automatisiert). |
S1 | Bestanden |
| 1.1.12 | Achten Sie darauf, dass die Eigentümerschaft für das etcd-Datenverzeichnisses auf etcd:etcd festgelegt ist (automatisiert). |
S1 | Nicht bestanden |
| 1.1.13 | Achten Sie darauf, dass die Berechtigungen für die Standarddatei mit administrativen Anmeldedaten auf 600 festgelegt sind (automatisiert). |
S1 | Bestanden |
| 1.1.14 | Achten Sie darauf, dass die Eigentümerschaft für die Datei mit den Standardanmeldedaten für die Administration auf root:root festgelegt ist (automatisiert). |
S1 | Bestanden |
| 1.1.15 | Achten Sie darauf, dass die Berechtigungen für die Datei scheduler.conf auf 600 oder restriktiver festgelegt sind (automatisiert). |
S1 | Bestanden |
| 1.1.16 | Achten Sie darauf, dass die Eigentümerschaft für die Datei scheduler.conf auf root:root festgelegt ist (automatisiert). |
S1 | Nicht bestanden |
| 1.1.17 | Achten Sie darauf, dass die Berechtigungen für die Datei controller-manager.conf auf 600 oder restriktiver festgelegt sind (automatisiert). |
S1 | Bestanden |
| 1.1.18 | Achten Sie darauf, dass die Eigentümerschaft für die Datei controller-manager.conf auf root:root festgelegt ist (automatisiert). |
S1 | Nicht bestanden |
| 1.1.19 | Achten Sie darauf, dass die Eigentümerschaft für das Kubernetes PKI-Verzeichnis und die Datei auf root:root festgelegt sind (automatisiert). |
S1 | Nicht bestanden |
| 1.1.20 | Achten Sie darauf, dass die Berechtigungen für die Kubernetes-PKI-Zertifikatsdatei auf 600 oder restriktiver festgelegt sind (manuell). |
S1 | Warnen |
| 1.1.21 | Achten Sie darauf, dass die Berechtigungen für die Kubernetes-PKI-Schlüsseldatei auf 600 festgelegt sind (manuell). |
S1 | Warnen |
| 1.2 | API-Server | ||
| 1.2.1 | Das Argument --anonymous-auth muss auf false festgelegt ist (manuell). |
S1 | Warnen |
| 1.2.2 | Der Parameter --token-auth-file darf nicht festgelegt sein (automatisiert). |
S1 | Bestanden |
| 1.2.3 | Das Argument --DenyServiceExternalIPs muss festgelegt sein (manuell). |
S1 | Warnen |
| 1.2.4 | Die Argumente --kubelet-client-certificate und --kubelet-client-key müssen entsprechend festgelegt sein (automatisiert). |
S1 | Bestanden |
| 1.2.5 | Das Argument --kubelet-certificate-authority muss entsprechend festgelegt sein (automatisiert). |
S1 | Bestanden |
| 1.2.6 | Das Argument --authorization-mode darf nicht auf "AlwaysAllow" festgelegt sein (automatisiert). |
S1 | Bestanden |
| 1.2.7 | Das Argument --authorization-mode muss Node enthalten (automatisiert). |
S1 | Bestanden |
| 1.2.8 | Das Argument --authorization-mode muss RBAC enthalten (automatisiert). |
S1 | Bestanden |
| 1.2.9 | Das Zugangskontroll-Plug-in EventRateLimit muss festgelegt sein (manuell). |
S1 | Warnen |
| 1.2.10 | Das Zugangskontroll-Plug-in AlwaysAdmit darf nicht festgelegt sein (automatisiert). |
S1 | Bestanden |
| 1.2.11 | Das Zugangskontroll-Plug-in AlwaysPullImages muss festgelegt sein (manuell). |
S1 | Warnen |
| 1.2.12 | Das Zugangskontroll-Plug-in ServiceAccount muss festgelegt sein (automatisiert). |
S1 | Bestanden |
| 1.2.13 | Das Zugangskontroll-Plug-in NamespaceLifecycle muss festgelegt sein (automatisiert). |
S1 | Bestanden |
| 1.2.14 | Das Zugangskontroll-Plug-in NodeRestriction muss festgelegt sein (automatisiert). |
S1 | Bestanden |
| 1.2.15 | Das Argument --profiling muss auf false festgelegt sein (automatisiert). |
S1 | Bestanden |
| 1.2.16 | Das Argument --audit-log-path muss festgelegt sein (automatisiert). |
S1 | Bestanden |
| 1.2.17 | Achten Sie darauf, dass das Argument --audit-log-maxage auf 30 oder nach Bedarf festgelegt ist (automatisiert). |
S1 | Bestanden |
| 1.2.18 | Achten Sie darauf, dass das Argument --audit-log-maxbackup auf 10 oder nach Bedarf festgelegt ist (automatisiert). |
S1 | Bestanden |
| 1.2.19 | Achten Sie darauf, dass das Argument --audit-log-maxsize auf 100 oder nach Bedarf festgelegt ist (automatisiert). |
S1 | Bestanden |
| 1.2.20 | Das Argument --request-timeout muss entsprechend festgelegt sein (manuell). |
S1 | Warnen |
| 1.2.21 | Das Argument --service-account-lookup muss auf true festgelegt sein (automatisiert). |
S1 | Bestanden |
| 1.2.22 | Das Argument --service-account-key-file muss entsprechend festgelegt sein (automatisiert). |
S1 | Bestanden |
| 1.2.23 | Die Argumente --etcd-certfile und --etcd-keyfile müssen entsprechend festgelegt sein (automatisiert). |
S1 | Bestanden |
| 1.2.24 | Die Argumente --tls-cert-file und --tls-private-key-file müssen entsprechend festgelegt sein (automatisiert). |
S1 | Bestanden |
| 1.2.25 | Das Argument --client-ca-file muss entsprechend festgelegt sein (automatisiert). |
S1 | Bestanden |
| 1.2.26 | Das Argument --etcd-cafile muss entsprechend festgelegt sein (automatisiert). |
S1 | Bestanden |
| 1.2.27 | Das Argument --encryption-provider-config muss entsprechend festgelegt sein (manuell). |
S1 | Bestanden |
| 1.2.28 | Verschlüsselungsanbieter sollten entsprechend konfiguriert sein (manuell). | S1 | Bestanden |
| 1.2.29 | Der API-Server darf nur starke kryptografische Chiffren verwenden (manuell). | S1 | Bestanden |
| 1.3 | Controller-Manager | ||
| 1.3.1 | Das Argument --terminated-pod-gc-threshold muss entsprechend festgelegt sein (manuell). |
S1 | Bestanden |
| 1.3.2 | --profiling argument muss auf false festgelegt sein (automatisiert). |
S1 | Bestanden |
| 1.3.3 | Das Argument --use-service-account-credentials muss auf true festgelegt sein (automatisiert). |
S1 | Bestanden |
| 1.3.4 | Das Argument --service-account-private-key-file muss entsprechend festgelegt sein (automatisiert). |
S1 | Bestanden |
| 1.3.5 | Das Argument --root-ca-file muss entsprechend festgelegt sein (automatisiert). |
S1 | Bestanden |
| 1.3.6 | Das Argument RotateKubeletServerCertificate muss auf true festgelegt sein (automatisiert). |
S2 | Bestanden |
| 1.3.7 | Das Argument --bind-address muss auf 127.0.0.1 festgelegt sein (automatisiert). |
S1 | Nicht bestanden |
| 1.4 | Planer | ||
| 1.4.1 | Das Argument --profiling muss auf false festgelegt sein (automatisiert). |
S1 | Bestanden |
| 1.4.2 | Das Argument --bind-address muss auf 127.0.0.1 festgelegt sein (automatisiert). |
S1 | Nicht bestanden |
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. Das folgende Tool kann Ihnen dabei helfen.
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.
Sie müssen unbedingt die richtige Version angeben, zum Beispiel:
kube-bench --benchmark BENCHMARK_VERSION
Ersetzen Sie BENCHMARK_VERSION durch die Version der CIS-Kubernetes-Benchmark, die Sie zum Bewerten Ihres Clusters verwenden.
Wenn Sie bestimmte CIS-Benchmark-Abschnitte wie „master“, „node“ oder „etcd“ ausführen möchten, verwenden Sie den Befehl run --targets. Beispiel:
kube-bench run --targets master,node
Weitere Informationen finden Sie in der kube-bench-Dokumentation zum Ausführen von kube-bench und zu Befehlen und Flags.