Dieses Dokument stellt die CIS Kubernetes Benchmark vor, erklärt, wie Sie die Compliance mit der Benchmark überprüfen können, und erläutert, wie Anthos-Cluster auf VMware (GKE On-Prem) konfiguriert werden, wenn Sie eine Empfehlung nicht selbst umsetzen 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.
Versionen
Die Versionsnummern für verschiedene Benchmarks sind möglicherweise nicht identisch. Dieses Dokument bezieht sich auf folgende Versionen:
| Anthos-Version | Kubernetes-Version | Version der CIS-Kubernetes-Benchmark |
|---|---|---|
| 1.15.0 | 1.27.1 | 1,6 |
CIS-Kubernetes-Benchmark verwenden
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 | Empfehlungen: |
| Stufe 2 | Das Profil der Stufe 1 wird erweitert. Empfehlungen weisen mindestens eine 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 der folgenden Tabelle angegeben bestimmt und unterstützt.
| Bewertungen | Beschreibung |
|---|---|
| Automatisiert | Empfehlungen, für die die Prüfung einer technischen Kontrolle vollständig automatisiert werden kann und im Status „Bestanden” oder „Nicht bestanden” validiert wird Empfehlungen enthalten die erforderlichen Informationen zur Implementierung der Automatisierung. |
| Manuell | Empfehlungen, für die die Prüfung einer technischen Kontrolle nicht vollständig automatisiert werden kann, sind vollständig oder teilweise manuell überprüft, um zu prüfen, ob der konfigurierte Status wie erwartet konfiguriert ist. Der erwartete Zustand kann je nach Umgebung variieren. |
Bewertung zu Anthos-Cluster auf VMware
Mit den folgenden Werten legen wir den Status von Kubernetes-Empfehlungen in Anthos-Cluster auf VMware fest:
| Status | Beschreibung |
|---|---|
| Bestanden | Entspricht einer Benchmarkempfehlung. |
| Nicht bestanden | Entspricht nicht einer Benchmarkempfehlung. |
| Gleichwertige Kontrolle | Entspricht nicht genau den Bedingungen, die in der Benchmark-Empfehlung enthalten sind. Es gibt jedoch andere Mechanismen in Anthos-Cluster auf VMware, um entsprechende Sicherheitskontrollen zu ermöglichen. |
| Umgebungsabhängig | Anthos-Cluster auf VMware konfiguriert keine Elemente für diese Empfehlung. Die Konfiguration des Nutzers bestimmt, ob die Umgebung einer Benchmarkempfehlung entspricht. |
Anthos-Cluster auf VMware-Architektur
Anthos-Cluster auf VMware verwendet einen Administratorcluster, um einen oder mehrere Nutzercluster zu verwalten, die tatsächliche Kubernetes-Arbeitslasten ausführen. Weitere Informationen zu dieser Architektur finden Sie in der Übersicht zu Anthos-Cluster auf VMware. Die Konfiguration von Administrator- und Nutzerclustern wird anhand der folgenden Benchmarks bewertet.
Status von Anthos-Cluster auf VMware
Wenn Sie einen neuen Cluster in Anthos-Cluster auf VMware mit der angegebenen Version erstellen, schneidet er im Vergleich zur CIS-Kubernetes-Benchmark wie unten beschrieben ab.
Status des Anthos-Cluster auf VMware-Administratorclusters:
| # | 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 | Gleichwertige Kontrolle |
| 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 | Gleichwertige Kontrolle |
| 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 | Gleichwertige Kontrolle |
| 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 | Gleichwertige Kontrolle |
| 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 | Bestanden |
| 1.1.10 | Achten Sie darauf, dass Eigentümerschaft für die Container Network Interface-Datei auf root:root festgelegt ist (manuell). |
S1 | Bestanden |
| 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 | Gleichwertige Kontrolle |
| 1.1.13 | Die Berechtigungen für die Datei „admin.conf“ sollten auf 600 festgelegt oder restriktiver sein (automatisch). |
S1 | Bestanden |
| 1.1.14 | Die Eigentümerschaft der Datei „admin.conf“ sollte auf root:root (Automatisch) festgelegt sein |
S1 | Bestanden |
| 1.1.15 | Achten Sie darauf, dass die Berechtigungen für die Datei „scheduler.conf“ auf 600 oder restriktiver (automatisch) festgelegt sind. |
S1 | Bestanden |
| 1.1.16 | Die Eigentümerschaft der Datei „scheduler.conf“ muss auf root:root (Automatisch) festgelegt sein |
S1 | Gleichwertige Kontrolle |
| 1.1.17 | Die Berechtigungen für die Datei „controller-manager.conf“ sollten auf 600 festgelegt oder restriktiver sein (automatisch) |
S1 | Bestanden |
| 1.1.18 | Die Eigentümerschaft der Datei „controller-manager.conf“ sollte auf root:root (Automatisch) festgelegt sein |
S1 | Gleichwertige Kontrolle |
| 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 | Bestanden |
| 1.1.20 | Achten Sie darauf, dass die Berechtigungen für die Kubernetes-PKI-Zertifikatsdatei auf 600 oder restriktiver festgelegt sind (manuell). |
S1 | Bestanden |
| 1.1.21 | Achten Sie darauf, dass die Berechtigungen für die Kubernetes-PKI-Schlüsseldatei auf 600 festgelegt sind (manuell). |
S1 | Bestanden |
| 1.2 | API-Server | ||
| 1.2.1 | Achten Sie darauf, dass das Argument --anonymous-auth auf "false" festgelegt ist (manuell). |
S1 | Bestanden |
| 1.2.2 | Der Parameter --token-auth-file darf nicht festgelegt sein (automatisiert). |
S1 | Bestanden |
| 1.2.3 | Achten Sie darauf, dass --DenyServiceExternalIPs festgelegt ist (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 | Umgebungsabhängig |
| 1.2.12 | Das Zugangskontroll-Plug-in "SecurityContextDeny" muss festgelegt sein, wenn "PodSecurityPolicy" nicht verwendet wird (manuell). | S1 | Gleichwertige Kontrolle |
| 1.2.13 | Das Zugangskontroll-Plug-in "ServiceAccount" muss festgelegt sein (automatisiert). | S1 | Bestanden |
| 1.2.14 | Das Zugangskontroll-Plug-in "NamespaceLifecycle" muss festgelegt sein (automatisiert). | S1 | Bestanden |
| 1.2.15 | Das Zugangskontroll-Plug-in "NodeRestriction" muss festgelegt sein (automatisiert). | S1 | Bestanden |
| 1.2.16 | Achten Sie darauf, dass das Argument --secure-port nicht auf 0 festgelegt ist. Hinweis: Diese Empfehlung ist veraltet und wird nach dem Konsensverfahren gelöscht (manuell). |
S1 | Bestanden |
| 1.2.17 | Achten Sie darauf, dass das Argument --profiling auf "false" festgelegt ist (automatisiert). |
S1 | Bestanden |
| 1.2.18 | Das Argument --audit-log-path muss festgelegt sein (automatisiert). |
S1 | Bestanden |
| 1.2.19 | Achten Sie darauf, dass das Argument --audit-log-maxage auf 30 oder nach Bedarf festgelegt ist (automatisiert). |
S1 | Gleichwertige Kontrolle |
| 1.2.20 | Achten Sie darauf, dass das Argument --audit-log-maxbackup auf 10 oder nach Bedarf festgelegt ist (automatisiert). |
S1 | Bestanden |
| 1.2.21 | Achten Sie darauf, dass das Argument --audit-log-maxsize auf 100 oder nach Bedarf festgelegt ist (automatisiert). |
S1 | Bestanden |
| 1.2.22 | Das Argument --request-timeout muss entsprechend festgelegt sein (manuell). |
S1 | Bestanden |
| 1.2.23 | Achten Sie darauf, dass das Argument --service-account-lookup auf "true" festgelegt ist (automatisiert). |
S1 | Bestanden |
| 1.2.24 | Das Argument --service-account-key-file muss entsprechend festgelegt sein (automatisiert). |
S1 | Bestanden |
| 1.2.25 | Die Argumente --etcd-certfile und --etcd-keyfile müssen entsprechend festgelegt sein (automatisiert). |
S1 | Bestanden |
| 1.2.26 | Die Argumente --tls-cert-file und --tls-private-key-file müssen entsprechend festgelegt sein (automatisiert). |
S1 | Bestanden |
| 1.2.27 | Das Argument --client-ca-file muss entsprechend festgelegt sein (automatisiert). |
S1 | Bestanden |
| 1.2.28 | Das Argument --etcd-cafile muss entsprechend festgelegt sein (automatisiert). |
S1 | Bestanden |
| 1.2.29 | Das Argument --encryption-provider-config muss entsprechend festgelegt sein (manuell). |
S1 | Bestanden |
| 1.2.30 | Verschlüsselungsanbieter sollten entsprechend konfiguriert sein (manuell). | S1 | Bestanden |
| 1.2.31 | 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 | Achten Sie darauf, dass das Argument --profiling auf "false" festgelegt ist (automatisiert). |
S1 | Bestanden |
| 1.3.3 | Achten Sie darauf, dass das Argument --use-service-account-credentials auf "true" festgelegt ist (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 | Bestanden |
| 1.4 | Planer | ||
| 1.4.1 | Achten Sie darauf, dass das Argument --profiling auf "false" festgelegt ist (automatisiert). |
S1 | Bestanden |
| 1.4.2 | Das Argument --bind-address muss auf 127.0.0.1 festgelegt sein (automatisiert). |
S1 | Bestanden |
| 2 | Etcd-Knotenkonfiguration | ||
| 2 | Etcd-Knotenkonfiguration | ||
| 2.1 | Die Argumente --cert-file und --key-file müssen entsprechend festgelegt sein (automatisiert). |
S1 | Bestanden |
| 2,2 | Achten Sie darauf, dass das Argument --client-cert-auth auf "true" festgelegt ist (automatisiert). |
S1 | Bestanden |
| 2,3 | Achten Sie darauf, dass das Argument --auto-tls nicht auf "true" festgelegt ist (automatisiert). |
S1 | Bestanden |
| 2.4 | Die Argumente --peer-cert-file und --peer-key-file müssen entsprechend festgelegt sein (automatisiert). |
S1 | Bestanden |
| 2,5 | Achten Sie darauf, dass das Argument --peer-client-cert-auth auf "true" festgelegt ist (automatisiert). |
S1 | Bestanden |
| 2,6 | Achten Sie darauf, dass das Argument --peer-auto-tls nicht auf "true" festgelegt ist (automatisiert). |
S1 | Bestanden |
| 2.7 | Für etcd muss eine eindeutige Zertifizierungsstelle verwendet werden (manuell). | S2 | Bestanden |
| 3 | Konfiguration der Steuerungsebene | ||
| 3.1 | Authentifizierung und Autorisierung | ||
| 3.1.1 | Die Clientzertifikatsauthentifizierung sollte nicht für Nutzer verwendet werden (manuell). | S2 | Bestanden |
| 3.1.2 | Die Authentifizierung des Dienstkontotokens sollte nicht für Nutzer verwendet werden (manuell) | S1 | Warnen |
| 3.1.3 | Die Bootstrap-Tokenauthentifizierung sollte nicht für Nutzer verwendet werden (manuell) | S1 | Warnen |
| 3.2 | Logging | ||
| 3.2.1 | Eine Audit-Mindestrichtlinie muss erstellt sein (manuell). | S1 | Bestanden |
| 3.2.2 | Die Audit-Richtlinie muss wichtige Sicherheitsaspekte abdecken (manuell). | S2 | Gleichwertige Kontrolle |
| 4 | Sicherheitskonfiguration des Worker-Knotens | ||
| 4.1 | Konfigurationsdateien der Worker-Knoten | ||
| 4.1.1 | Die Berechtigungen für die kubelet-Servicedatei müssen auf 600 festgelegt oder restriktiver sein (automatisiert). |
S1 | Nicht bestanden |
| 4.1.2 | Die Eigentümerschaft der kubelet-Servicedatei muss auf root:root festgelegt sein (automatisiert). |
S1 | Bestanden |
| 4.1.3 | Wenn die Proxy-kubeconfig-Datei vorhanden ist, müssen die Berechtigungen auf 600 oder restriktiver festgelegt sein (manuell). |
S1 | Bestanden |
| 4.1.4 | Wenn die Proxy-kubeconfig-Datei vorhanden ist, müssen Sie die Inhaberschaft auf root:root festlegen (manuell). |
S1 | Bestanden |
| 4.1.5 | Achten Sie darauf, dass die Dateiberechtigungen für --kubeconfig kubelet.conf auf 600 oder restriktiver (automatisch) festgelegt sind |
S1 | Bestanden |
| 4.1.6 | Achten Sie darauf, dass die --kubeconfigEigentümerschaft für kubelet.conf auf root:root (automatisch) festgelegt ist. |
S1 | Bestanden |
| 4.1.7 | Die Berechtigungen für die Zertifizierungsstellendatei muss auf 600 festgelegt oder restriktiver sein (manuell). |
S1 | Bestanden |
| 4.1.8 | Die Eigentümerschaft für die Client-Zertifizierungsstellendatei muss auf root:root festgelegt sein (manuell). |
S1 | Bestanden |
| 4.1.9 | Wenn die Konfigurationsdatei „kubelet config.yaml“ verwendet wird, prüfen Sie, ob die Berechtigungen auf 600 oder höher festgelegt sind (manuell) |
S1 | Warnen |
| 4.1.10 | Wenn die kubelet config.yaml-Konfigurationsdatei verwendet wird, prüfen Sie, ob die Eigentümerschaft der Datei auf root:root (Manuell) gesetzt ist |
S1 | Bestanden |
| 4.2 | Kubelet | ||
| 4.2.1 | Achten Sie darauf, dass das Argument --anonymous-auth auf "false" festgelegt ist (automatisiert). |
S1 | Bestanden |
| 4.2.2 | Das Argument --authorization-mode darf nicht auf "AlwaysAllow" festgelegt sein (automatisiert). |
S1 | Bestanden |
| 4.2.3 | Das Argument --client-ca-file muss entsprechend festgelegt sein (automatisiert). |
S1 | Bestanden |
| 4.2.4 | Das Argument --read-only-port muss auf 0 (manuell) gesetzt sein |
S1 | Nicht bestanden |
| 4.2.5 | Das Argument --streaming-connection-idle-timeout darf nicht auf 0 gesetzt sein (manuell). |
S1 | Bestanden |
| 4.2.6 | Achten Sie darauf, dass das Argument --make-iptables-util-chains auf "true" festgelegt ist (automatisiert). |
S1 | Bestanden |
| 4.2.7 | Das Argument --hostname-override darf nicht festgelegt sein (manuell). |
S1 | Bestanden |
| 4.2.8 | Achten Sie darauf, dass das Argument „eventRecordQPS“ auf eine Ebene festgelegt ist, die die entsprechende Ereigniserfassung gewährleistet (manuell). | S1 | Bestanden |
| 4.2.9 | Die Argumente --tls-cert-file und --tls-private-key-file müssen entsprechend festgelegt sein (manuell). |
S2 | Gleichwertige Kontrolle |
| 4.2.10 | Das Argument --rotate-certificates darf nicht auf „false” gesetzt sein (automatisiert). |
S1 | Bestanden |
| 4.2.11 | Das Argument "RotateletServerCertificate" muss auf "true" festgelegt sein (manuell). | S1 | Bestanden |
| 4.2.12 | Achten Sie darauf, dass das Kubelet nur starke kryptografische Chiffren verwendet (manuell). | S1 | Bestanden |
| 4.2.13 | Achten Sie darauf, dass ein Limit für Pod-PIDs festgelegt ist (manuell) | S1 | Warnen |
Beschreibungen von Fehlern und gleichwertigen Kontrollen für den Anthos-Cluster auf VMware-Administratorcluster:
| # | Empfehlung | Level | Status | Wert | Begründung |
|---|---|---|---|---|---|
| 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 | Gleichwertige Kontrolle | – | Im kubeception-Modus wird die API-Server-Pod-Spezifikation des Nutzerclusters in etcd gespeichert. |
| 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 | Gleichwertige Kontrolle | – | Im kubeception-Modus wird die Pod-Spezifikation des Controller-Managers des Nutzerclusters in etcd gespeichert. |
| 1.1.5 | Achten Sie darauf, dass die Berechtigungen für die Pod-Spezifikationsdatei des Planers auf 600 oder restriktiver festgelegt sind (automatisiert). |
S1 | Gleichwertige Kontrolle | – | Im kubeception-Modus wird die Planer-Pod-Spezifikation des Nutzerclusters in etcd gespeichert. |
| 1.1.7 | Achten Sie darauf, dass die Berechtigungen für die Pod-Spezifikationsdatei von etcd auf 600 oder restriktiver festgelegt sind (automatisiert). |
S1 | Gleichwertige Kontrolle | – | Im kubeception-Modus wird die etcd-Spezifikation des Nutzerclusters im etcd-Format des Administratorclusters gespeichert. |
| 1.1.12 | Achten Sie darauf, dass die Eigentümerschaft für das etcd-Datenverzeichnisses auf etcd:etcd festgelegt ist (automatisiert). |
S1 | Gleichwertige Kontrolle | 2001:2001 |
Der etcd-Container wird als 2001 ausgeführt und das etcd-Datenverzeichnis gehört 2001:2001. |
| 1.1.16 | Die Eigentümerschaft der Datei „scheduler.conf“ muss auf root:root (Automatisch) festgelegt sein |
S1 | Gleichwertige Kontrolle | 2000:2000 |
Der kube-scheduler-Container wird als 2000 ausgeführt und diese Datei gehört 2000:2000. |
| 1.1.18 | Die Eigentümerschaft der Datei „controller-manager.conf“ sollte auf root:root (Automatisch) festgelegt sein |
S1 | Gleichwertige Kontrolle | 2002:2002 |
Der Controller-Manager-Container wird 2002 ausgeführt und gehört zu 2002:2002. |
| 1.2.3 | Achten Sie darauf, dass --AblehnenServiceExterneIPs festgelegt (manuell) ist |
S1 | Warnen | nicht festgelegt | Anthos-Cluster auf VMware unterstützt den EventRateLimit-Zugangs-Controller nicht, da dies ein Kubernetes-Alphafeature ist. |
| 1.2.9 | Das Zugangskontroll-Plug-in "EventRateLimit" muss festgelegt sein (manuell). | S1 | Warnen | nicht festgelegt | Anthos-Cluster auf VMware unterstützt den EventRateLimit-Zugangs-Controller nicht, da dies ein Kubernetes-Alphafeature ist. |
| 1.2.11 | Das Zugangskontroll-Plug-in "AlwaysPullImages" muss festgelegt sein (manuell). | S1 | Umgebungsabhängig | Nicht definiert | Die Zugangssteuerung "AlwaysPullImages" bietet einen gewissen Schutz für private Registry-Images in nicht operativen Clustern mit mehreren Instanzen. Dafür müssen Container Registries als Single Point of Failure zur Erstellung neuer Pods im gesamten Cluster dienen. Anthos-Cluster auf VMware aktiviert nicht den AlwaysPullImages-Zugangs-Controller, sodass es im Ermessen der Clusteradministratoren liegt, diesen Kompromiss einzugehen und die Zugangsrichtlinie zu implementieren. |
| 1.2.12 | Das Zugangskontroll-Plug-in "SecurityContextDeny" muss festgelegt sein, wenn "PodSecurityPolicy" nicht verwendet wird (manuell). | S1 | Gleichwertige Kontrolle | nicht festgelegt | PodSecurityPolicy wird in 1.25 aus Kubernetes entfernt. Als Ersatz ist Pod Security Admission ab Version 1.23 standardmäßig aktiviert. |
| 1.2.19 | Achten Sie darauf, dass das Argument --audit-log-maxage auf 30 oder nach Bedarf festgelegt ist (automatisiert). |
S1 | Gleichwertige Kontrolle | Nicht definiert | Anthos-Cluster auf VMware erfasst Audit-Logs, verwendet diese Flags jedoch nicht zur Prüfung. Weitere Informationen finden Sie in der Audit-Richtlinie zu Anthos-Cluster auf VMware. |
| 3.1.2 | Die Authentifizierung des Dienstkontotokens sollte nicht für Nutzer verwendet werden (manuell) | S1 | Warnen | nicht festgelegt | Anthos-Cluster auf VMware unterstützt den EventRateLimit-Zugangs-Controller nicht, da dies ein Kubernetes-Alphafeature ist. |
| 3.1.3 | Die Bootstrap-Tokenauthentifizierung sollte nicht für Nutzer verwendet werden (manuell) | S1 | Warnen | nicht festgelegt | Anthos-Cluster auf VMware unterstützt den EventRateLimit-Zugangs-Controller nicht, da dies ein Kubernetes-Alphafeature ist. |
| 3.2.2 | Die Audit-Richtlinie muss wichtige Sicherheitsaspekte abdecken (manuell). | S2 | Gleichwertige Kontrolle | Nicht definiert | Anthos-Cluster auf VMware erfasst Audit-Logs, verwendet diese Flags jedoch nicht zur Prüfung. Weitere Informationen finden Sie in der Audit-Richtlinie zu Anthos-Cluster auf VMware. |
| 4.1.1 | Die Berechtigungen für die kubelet-Servicedatei müssen auf 600 festgelegt oder restriktiver sein (automatisiert). |
S1 | Nicht bestanden | Nicht definiert | Anthos-Cluster auf VMware unterstützt den EventRateLimit-Zugangs-Controller nicht, da dies ein Kubernetes-Alphafeature ist. |
| 4.1.9 | Wenn die Konfigurationsdatei „kubelet config.yaml“ verwendet wird, prüfen Sie, ob die Berechtigungen auf 600 oder höher festgelegt sind (manuell) |
S1 | Warnen | nicht festgelegt | Anthos-Cluster auf VMware unterstützt den EventRateLimit-Zugangs-Controller nicht, da dies ein Kubernetes-Alphafeature ist. |
| 4.2.4 | Das Argument --read-only-port muss auf 0 (manuell) gesetzt sein |
S1 | Nicht bestanden | 10255 |
Einige Anthos-Cluster auf VMware-Monitoring-Komponenten verwenden den schreibgeschützten Kubelet-Port, um Messwerte abzurufen. |
| 4.2.9 | Die Argumente --tls-cert-file und --tls-private-key-file müssen entsprechend festgelegt sein (manuell). |
S2 | Gleichwertige Kontrolle | Nicht definiert | Anthos-Cluster auf VMware verwaltet Kubelet-Server-TLS mit dem Flag --rotate-server-certificates. |
| 4.2.13 | Achten Sie darauf, dass ein Limit für Pod-PIDs festgelegt ist (manuell) | S1 | Warnen | nicht festgelegt | Anthos-Cluster auf VMware unterstützt den EventRateLimit-Zugangs-Controller nicht, da dies ein Kubernetes-Alphafeature ist. |
Status des Anthos-Cluster auf VMware-Nutzerclusters:
| # | 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 | Gleichwertige Kontrolle |
| 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 | Gleichwertige Kontrolle |
| 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 | Gleichwertige Kontrolle |
| 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 | Gleichwertige Kontrolle |
| 1.1.5 | Achten Sie darauf, dass die Berechtigungen für die Pod-Spezifikationsdatei des Planers auf 600 oder restriktiver festgelegt sind (automatisiert). |
S1 | Gleichwertige Kontrolle |
| 1.1.6 | Achten Sie darauf, dass die Eigentümerschaft für die Pod-Spezifikationsdatei des Planers auf root:root festgelegt ist (automatisiert). |
S1 | Gleichwertige Kontrolle |
| 1.1.7 | Achten Sie darauf, dass die Berechtigungen für die Pod-Spezifikationsdatei von etcd auf 600 oder restriktiver festgelegt sind (automatisiert). |
S1 | Gleichwertige Kontrolle |
| 1.1.8 | Achten Sie darauf, dass die Eigentümerschaft für die Pod-Spezifikationsdatei von etcd auf root:root festgelegt ist (automatisiert). |
S1 | Gleichwertige Kontrolle |
| 1.1.9 | Achten Sie darauf, dass die Berechtigungen für die Container Network Interface-Datei auf 600 oder restriktiver festgelegt sind (manuell). |
S1 | Bestanden |
| 1.1.10 | Achten Sie darauf, dass Eigentümerschaft für die Container Network Interface-Datei auf root:root festgelegt ist (manuell). |
S1 | Bestanden |
| 1.1.11 | Achten Sie darauf, dass die Berechtigungen für das etcd-Datenverzeichnis auf 700 oder restriktiver festgelegt sind (automatisiert). |
S1 | Gleichwertige Kontrolle |
| 1.1.12 | Achten Sie darauf, dass die Eigentümerschaft für das etcd-Datenverzeichnisses auf etcd:etcd festgelegt ist (automatisiert). |
S1 | Gleichwertige Kontrolle |
| 1.1.13 | Die Berechtigungen für die Datei „admin.conf“ sollten auf 600 festgelegt oder restriktiver sein (automatisch). |
S1 | Bestanden |
| 1.1.14 | Die Eigentümerschaft der Datei „admin.conf“ sollte auf root:root (Automatisch) festgelegt sein |
S1 | Bestanden |
| 1.1.15 | Achten Sie darauf, dass die Berechtigungen für die Datei „scheduler.conf“ auf 600 oder restriktiver (automatisch) festgelegt sind. |
S1 | Bestanden |
| 1.1.16 | Die Eigentümerschaft der Datei „scheduler.conf“ muss auf root:root (Automatisch) festgelegt sein |
S1 | Gleichwertige Kontrolle |
| 1.1.17 | Die Berechtigungen für die Datei „controller-manager.conf“ sollten auf 600 festgelegt oder restriktiver sein (automatisch) |
S1 | Bestanden |
| 1.1.18 | Die Eigentümerschaft der Datei „controller-manager.conf“ sollte auf root:root (Automatisch) festgelegt sein |
S1 | Gleichwertige Kontrolle |
| 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 | Bestanden |
| 1.1.20 | Achten Sie darauf, dass die Berechtigungen für die Kubernetes-PKI-Zertifikatsdatei auf 600 oder restriktiver festgelegt sind (manuell). |
S1 | Bestanden |
| 1.1.21 | Achten Sie darauf, dass die Berechtigungen für die Kubernetes-PKI-Schlüsseldatei auf 600 festgelegt sind (manuell). |
S1 | Bestanden |
| 1.2 | API-Server | ||
| 1.2.1 | Achten Sie darauf, dass das Argument --anonymous-auth auf "false" festgelegt ist (manuell). |
S1 | Bestanden |
| 1.2.2 | Der Parameter --token-auth-file darf nicht festgelegt sein (automatisiert). |
S1 | Bestanden |
| 1.2.3 | Achten Sie darauf, dass --DenyServiceExternalIPs festgelegt ist (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 | Umgebungsabhängig |
| 1.2.12 | Das Zugangskontroll-Plug-in "SecurityContextDeny" muss festgelegt sein, wenn "PodSecurityPolicy" nicht verwendet wird (manuell). | S1 | Gleichwertige Kontrolle |
| 1.2.13 | Das Zugangskontroll-Plug-in "ServiceAccount" muss festgelegt sein (automatisiert). | S1 | Bestanden |
| 1.2.14 | Das Zugangskontroll-Plug-in "NamespaceLifecycle" muss festgelegt sein (automatisiert). | S1 | Bestanden |
| 1.2.15 | Das Zugangskontroll-Plug-in "NodeRestriction" muss festgelegt sein (automatisiert). | S1 | Bestanden |
| 1.2.16 | Achten Sie darauf, dass das Argument --secure-port nicht auf 0 festgelegt ist. Hinweis: Diese Empfehlung ist veraltet und wird nach dem Konsensverfahren gelöscht (manuell). |
S1 | Bestanden |
| 1.2.17 | Achten Sie darauf, dass das Argument --profiling auf "false" festgelegt ist (automatisiert). |
S1 | Bestanden |
| 1.2.18 | Das Argument --audit-log-path muss festgelegt sein (automatisiert). |
S1 | Bestanden |
| 1.2.19 | Achten Sie darauf, dass das Argument --audit-log-maxage auf 30 oder nach Bedarf festgelegt ist (automatisiert). |
S1 | Gleichwertige Kontrolle |
| 1.2.20 | Achten Sie darauf, dass das Argument --audit-log-maxbackup auf 10 oder nach Bedarf festgelegt ist (automatisiert). |
S1 | Bestanden |
| 1.2.21 | Achten Sie darauf, dass das Argument --audit-log-maxsize auf 100 oder nach Bedarf festgelegt ist (automatisiert). |
S1 | Bestanden |
| 1.2.22 | Das Argument --request-timeout muss entsprechend festgelegt sein (manuell). |
S1 | Bestanden |
| 1.2.23 | Achten Sie darauf, dass das Argument --service-account-lookup auf "true" festgelegt ist (automatisiert). |
S1 | Bestanden |
| 1.2.24 | Das Argument --service-account-key-file muss entsprechend festgelegt sein (automatisiert). |
S1 | Bestanden |
| 1.2.25 | Die Argumente --etcd-certfile und --etcd-keyfile müssen entsprechend festgelegt sein (automatisiert). |
S1 | Bestanden |
| 1.2.26 | Die Argumente --tls-cert-file und --tls-private-key-file müssen entsprechend festgelegt sein (automatisiert). |
S1 | Bestanden |
| 1.2.27 | Das Argument --client-ca-file muss entsprechend festgelegt sein (automatisiert). |
S1 | Bestanden |
| 1.2.28 | Das Argument --etcd-cafile muss entsprechend festgelegt sein (automatisiert). |
S1 | Bestanden |
| 1.2.29 | Das Argument --encryption-provider-config muss entsprechend festgelegt sein (manuell). |
S1 | Bestanden |
| 1.2.30 | Verschlüsselungsanbieter sollten entsprechend konfiguriert sein (manuell). | S1 | Bestanden |
| 1.2.31 | 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 | Achten Sie darauf, dass das Argument --profiling auf "false" festgelegt ist (automatisiert). |
S1 | Bestanden |
| 1.3.3 | Achten Sie darauf, dass das Argument --use-service-account-credentials auf "true" festgelegt ist (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 | Bestanden |
| 1.4 | Planer | ||
| 1.4.1 | Achten Sie darauf, dass das Argument --profiling auf "false" festgelegt ist (automatisiert). |
S1 | Bestanden |
| 1.4.2 | Das Argument --bind-address muss auf 127.0.0.1 festgelegt sein (automatisiert). |
S1 | Bestanden |
| 2 | Etcd-Knotenkonfiguration | ||
| 2 | Etcd-Knotenkonfiguration | ||
| 2.1 | Die Argumente --cert-file und --key-file müssen entsprechend festgelegt sein (automatisiert). |
S1 | Bestanden |
| 2,2 | Achten Sie darauf, dass das Argument --client-cert-auth auf "true" festgelegt ist (automatisiert). |
S1 | Bestanden |
| 2,3 | Achten Sie darauf, dass das Argument --auto-tls nicht auf "true" festgelegt ist (automatisiert). |
S1 | Bestanden |
| 2.4 | Die Argumente --peer-cert-file und --peer-key-file müssen entsprechend festgelegt sein (automatisiert). |
S1 | Bestanden |
| 2,5 | Achten Sie darauf, dass das Argument --peer-client-cert-auth auf "true" festgelegt ist (automatisiert). |
S1 | Bestanden |
| 2,6 | Achten Sie darauf, dass das Argument --peer-auto-tls nicht auf "true" festgelegt ist (automatisiert). |
S1 | Bestanden |
| 2.7 | Für etcd muss eine eindeutige Zertifizierungsstelle verwendet werden (manuell). | S2 | Bestanden |
| 3 | Konfiguration der Steuerungsebene | ||
| 3.1 | Authentifizierung und Autorisierung | ||
| 3.1.1 | Die Clientzertifikatsauthentifizierung sollte nicht für Nutzer verwendet werden (manuell). | S2 | Bestanden |
| 3.1.2 | Die Authentifizierung des Dienstkontotokens sollte nicht für Nutzer verwendet werden (manuell) | S1 | Warnen |
| 3.1.3 | Die Bootstrap-Tokenauthentifizierung sollte nicht für Nutzer verwendet werden (manuell) | S1 | Warnen |
| 3.2 | Logging | ||
| 3.2.1 | Eine Audit-Mindestrichtlinie muss erstellt sein (manuell). | S1 | Bestanden |
| 3.2.2 | Die Audit-Richtlinie muss wichtige Sicherheitsaspekte abdecken (manuell). | S2 | Gleichwertige Kontrolle |
| 4 | Sicherheitskonfiguration des Worker-Knotens | ||
| 4.1 | Konfigurationsdateien der Worker-Knoten | ||
| 4.1.1 | Die Berechtigungen für die kubelet-Servicedatei müssen auf 600 festgelegt oder restriktiver sein (automatisiert). |
S1 | Nicht bestanden |
| 4.1.2 | Die Eigentümerschaft der kubelet-Servicedatei muss auf root:root festgelegt sein (automatisiert). |
S1 | Bestanden |
| 4.1.3 | Wenn die Proxy-kubeconfig-Datei vorhanden ist, müssen die Berechtigungen auf 600 oder restriktiver festgelegt sein (manuell). |
S1 | Bestanden |
| 4.1.4 | Wenn die Proxy-kubeconfig-Datei vorhanden ist, müssen Sie die Inhaberschaft auf root:root festlegen (manuell). |
S1 | Bestanden |
| 4.1.5 | Achten Sie darauf, dass die Dateiberechtigungen für --kubeconfig kubelet.conf auf 600 oder restriktiver (automatisch) festgelegt sind |
S1 | Bestanden |
| 4.1.6 | Achten Sie darauf, dass die --kubeconfigEigentümerschaft für kubelet.conf auf root:root (automatisch) festgelegt ist. |
S1 | Bestanden |
| 4.1.7 | Die Berechtigungen für die Zertifizierungsstellendatei muss auf 600 festgelegt oder restriktiver sein (manuell). |
S1 | Bestanden |
| 4.1.8 | Die Eigentümerschaft für die Client-Zertifizierungsstellendatei muss auf root:root festgelegt sein (manuell). |
S1 | Bestanden |
| 4.1.9 | Wenn die Konfigurationsdatei „kubelet config.yaml“ verwendet wird, prüfen Sie, ob die Berechtigungen auf 600 oder höher festgelegt sind (manuell) |
S1 | Warnen |
| 4.1.10 | Wenn die kubelet config.yaml-Konfigurationsdatei verwendet wird, prüfen Sie, ob die Eigentümerschaft der Datei auf root:root (Manuell) gesetzt ist |
S1 | Bestanden |
| 4.2 | Kubelet | ||
| 4.2.1 | Achten Sie darauf, dass das Argument --anonymous-auth auf "false" festgelegt ist (automatisiert). |
S1 | Bestanden |
| 4.2.2 | Das Argument --authorization-mode darf nicht auf "AlwaysAllow" festgelegt sein (automatisiert). |
S1 | Bestanden |
| 4.2.3 | Das Argument --client-ca-file muss entsprechend festgelegt sein (automatisiert). |
S1 | Bestanden |
| 4.2.4 | Das Argument --read-only-port muss auf 0 (manuell) gesetzt sein |
S1 | Nicht bestanden |
| 4.2.5 | Das Argument --streaming-connection-idle-timeout darf nicht auf 0 gesetzt sein (manuell). |
S1 | Bestanden |
| 4.2.6 | Achten Sie darauf, dass das Argument --make-iptables-util-chains auf "true" festgelegt ist (automatisiert). |
S1 | Bestanden |
| 4.2.7 | Das Argument --hostname-override darf nicht festgelegt sein (manuell). |
S1 | Bestanden |
| 4.2.8 | Achten Sie darauf, dass das Argument „eventRecordQPS“ auf eine Ebene festgelegt ist, die die entsprechende Ereigniserfassung gewährleistet (manuell). | S1 | Bestanden |
| 4.2.9 | Die Argumente --tls-cert-file und --tls-private-key-file müssen entsprechend festgelegt sein (manuell). |
S2 | Gleichwertige Kontrolle |
| 4.2.10 | Das Argument --rotate-certificates darf nicht auf „false” gesetzt sein (automatisiert). |
S1 | Bestanden |
| 4.2.11 | Das Argument "RotateletServerCertificate" muss auf "true" festgelegt sein (manuell). | S1 | Bestanden |
| 4.2.12 | Achten Sie darauf, dass das Kubelet nur starke kryptografische Chiffren verwendet (manuell). | S1 | Bestanden |
| 4.2.13 | Achten Sie darauf, dass ein Limit für Pod-PIDs festgelegt ist (manuell) | S1 | Warnen |
Beschreibungen von Fehlern und gleichwertigen Kontrollen für den Anthos-Cluster auf VMware-Nutzercluster:
| # | Empfehlung | Level | Status | Wert | Begründung |
|---|---|---|---|---|---|
| 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 | Gleichwertige Kontrolle | – | Im kubeception-Modus wird die API-Server-Pod-Spezifikation des Nutzerclusters in etcd gespeichert. |
| 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 | Gleichwertige Kontrolle | – | Im kubeception-Modus wird die API-Server-Pod-Spezifikation des Nutzerclusters in etcd gespeichert. |
| 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 | Gleichwertige Kontrolle | – | Im kubeception-Modus wird die Pod-Spezifikation des Controller-Managers des Nutzerclusters in etcd gespeichert. |
| 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 | Gleichwertige Kontrolle | – | Im kubeception-Modus wird die Pod-Spezifikation des Controller-Managers des Nutzerclusters in etcd gespeichert. |
| 1.1.5 | Achten Sie darauf, dass die Berechtigungen für die Pod-Spezifikationsdatei des Planers auf 600 oder restriktiver festgelegt sind (automatisiert). |
S1 | Gleichwertige Kontrolle | – | Im kubeception-Modus wird die Planer-Pod-Spezifikation des Nutzerclusters in etcd gespeichert. |
| 1.1.6 | Achten Sie darauf, dass die Eigentümerschaft für die Pod-Spezifikationsdatei des Planers auf root:root festgelegt ist (automatisiert). |
S1 | Gleichwertige Kontrolle | – | Im kubeception-Modus wird die Planer-Pod-Spezifikation des Nutzerclusters in etcd gespeichert. |
| 1.1.7 | Achten Sie darauf, dass die Berechtigungen für die Pod-Spezifikationsdatei von etcd auf 600 oder restriktiver festgelegt sind (automatisiert). |
S1 | Gleichwertige Kontrolle | – | Im kubeception-Modus wird die etcd-Spezifikation des Nutzerclusters im etcd-Format des Administratorclusters gespeichert. |
| 1.1.8 | Achten Sie darauf, dass die Eigentümerschaft für die Pod-Spezifikationsdatei von etcd auf root:root festgelegt ist (automatisiert). |
S1 | Gleichwertige Kontrolle | – | Im kubeception-Modus wird die etcd-Spezifikation des Nutzerclusters im etcd-Format des Administratorclusters gespeichert. |
| 1.1.11 | Achten Sie darauf, dass die Berechtigungen für das etcd-Datenverzeichnis auf 700 oder restriktiver festgelegt sind (automatisiert). |
S1 | Gleichwertige Kontrolle | 777 |
Das etcd-Datenverzeichnis wird über einen externen Speicher bereitgestellt. |
| 1.1.12 | Achten Sie darauf, dass die Eigentümerschaft für das etcd-Datenverzeichnisses auf etcd:etcd festgelegt ist (automatisiert). |
S1 | Gleichwertige Kontrolle | 2001:2001 |
Der etcd-Container wird als 2001 ausgeführt und das etcd-Datenverzeichnis gehört 2001:2001. |
| 1.1.16 | Die Eigentümerschaft der Datei „scheduler.conf“ muss auf root:root (Automatisch) festgelegt sein |
S1 | Gleichwertige Kontrolle | 2000:2000 |
Der kube-scheduler-Container wird als 2000 ausgeführt und diese Datei gehört 2000:2000. |
| 1.1.18 | Die Eigentümerschaft der Datei „controller-manager.conf“ sollte auf root:root (Automatisch) festgelegt sein |
S1 | Gleichwertige Kontrolle | 2002:2002 |
Der Controller-Manager-Container wird 2002 ausgeführt und gehört zu 2002:2002. |
| 1.2.3 | Achten Sie darauf, dass --AblehnenServiceExterneIPs festgelegt (manuell) ist |
S1 | Warnen | nicht festgelegt | Anthos-Cluster auf VMware unterstützt den EventRateLimit-Zugangs-Controller nicht, da dies ein Kubernetes-Alphafeature ist. |
| 1.2.9 | Das Zugangskontroll-Plug-in "EventRateLimit" muss festgelegt sein (manuell). | S1 | Warnen | nicht festgelegt | Anthos-Cluster auf VMware unterstützt den EventRateLimit-Zugangs-Controller nicht, da dies ein Kubernetes-Alphafeature ist. |
| 1.2.11 | Das Zugangskontroll-Plug-in "AlwaysPullImages" muss festgelegt sein (manuell). | S1 | Umgebungsabhängig | Nicht definiert | Die Zugangssteuerung "AlwaysPullImages" bietet einen gewissen Schutz für private Registry-Images in nicht operativen Clustern mit mehreren Instanzen. Dafür müssen Container Registries als Single Point of Failure zur Erstellung neuer Pods im gesamten Cluster dienen. Anthos-Cluster auf VMware aktiviert nicht den AlwaysPullImages-Zugangs-Controller, sodass es im Ermessen der Clusteradministratoren liegt, diesen Kompromiss einzugehen und die Zugangsrichtlinie zu implementieren. |
| 1.2.12 | Das Zugangskontroll-Plug-in "SecurityContextDeny" muss festgelegt sein, wenn "PodSecurityPolicy" nicht verwendet wird (manuell). | S1 | Gleichwertige Kontrolle | nicht festgelegt | PodSecurityPolicy wird in 1.25 aus Kubernetes entfernt. Als Ersatz ist Pod Security Admission ab Version 1.23 standardmäßig aktiviert. |
| 1.2.19 | Achten Sie darauf, dass das Argument --audit-log-maxage auf 30 oder nach Bedarf festgelegt ist (automatisiert). |
S1 | Gleichwertige Kontrolle | Nicht definiert | Anthos-Cluster auf VMware erfasst Audit-Logs, verwendet diese Flags jedoch nicht zur Prüfung. Weitere Informationen finden Sie in der Audit-Richtlinie zu Anthos-Cluster auf VMware. |
| 3.1.2 | Die Authentifizierung des Dienstkontotokens sollte nicht für Nutzer verwendet werden (manuell) | S1 | Warnen | nicht festgelegt | Anthos-Cluster auf VMware unterstützt den EventRateLimit-Zugangs-Controller nicht, da dies ein Kubernetes-Alphafeature ist. |
| 3.1.3 | Die Bootstrap-Tokenauthentifizierung sollte nicht für Nutzer verwendet werden (manuell) | S1 | Warnen | nicht festgelegt | Anthos-Cluster auf VMware unterstützt den EventRateLimit-Zugangs-Controller nicht, da dies ein Kubernetes-Alphafeature ist. |
| 3.2.2 | Die Audit-Richtlinie muss wichtige Sicherheitsaspekte abdecken (manuell). | S2 | Gleichwertige Kontrolle | Nicht definiert | Anthos-Cluster auf VMware erfasst Audit-Logs, verwendet diese Flags jedoch nicht zur Prüfung. Weitere Informationen finden Sie in der Audit-Richtlinie zu Anthos-Cluster auf VMware. |
| 4.1.1 | Die Berechtigungen für die kubelet-Servicedatei müssen auf 600 festgelegt oder restriktiver sein (automatisiert). |
S1 | Nicht bestanden | Nicht definiert | Anthos-Cluster auf VMware unterstützt den EventRateLimit-Zugangs-Controller nicht, da dies ein Kubernetes-Alphafeature ist. |
| 4.1.9 | Wenn die Konfigurationsdatei „kubelet config.yaml“ verwendet wird, prüfen Sie, ob die Berechtigungen auf 600 oder höher festgelegt sind (manuell) |
S1 | Warnen | nicht festgelegt | Anthos-Cluster auf VMware unterstützt den EventRateLimit-Zugangs-Controller nicht, da dies ein Kubernetes-Alphafeature ist. |
| 4.2.4 | Das Argument --read-only-port muss auf 0 (manuell) gesetzt sein |
S1 | Nicht bestanden | 10255 |
Einige Anthos-Cluster auf VMware-Monitoring-Komponenten verwenden den schreibgeschützten Kubelet-Port, um Messwerte abzurufen. |
| 4.2.9 | Die Argumente --tls-cert-file und --tls-private-key-file müssen entsprechend festgelegt sein (manuell). |
S2 | Gleichwertige Kontrolle | Nicht definiert | Anthos-Cluster auf VMware verwaltet Kubelet-Server-TLS mit dem Flag --rotate-server-certificates. |
| 4.2.13 | Achten Sie darauf, dass ein Limit für Pod-PIDs festgelegt ist (manuell) | S1 | Warnen | nicht festgelegt | Anthos-Cluster auf VMware unterstützt den EventRateLimit-Zugangs-Controller nicht, da dies ein Kubernetes-Alphafeature ist. |
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.
Geben Sie die richtige Version an. Beispiel:
kube-bench node --benchmark cis-1.6