CIS-Kubernetes-Benchmarks

In diesem Dokument wird die CIS Kubernetes-Benchmark vorgestellt. Außerdem erfahren Sie, wie Sie die Einhaltung des Benchmarks prüfen können. Bei Empfehlungen, die Sie nicht selbst umsetzen können, erklärt das Dokument, was Google Distributed Cloud tut, um die Empfehlung umzusetzen.

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.

Versionen

In der folgenden Tabelle sind die Versionen von Google Distributed Cloud, Kubernetes und dem CIS Kubernetes Benchmark aufgeführt, die zur Durchführung der in diesem Dokument beschriebenen Bewertung verwendet wurden:

1,29

Google Distributed Cloud-Version Kubernetes-Version Version der CIS-Kubernetes-Benchmark
1.29.0-gke.1449 1.29.3-gke.600 v1.8.0

1,28

Google Distributed Cloud-Version Kubernetes-Version Version der CIS-Kubernetes-Benchmark
1.28.0-gke.435 1.28.3-gke.700 v1.7.0

1.16

Google Distributed Cloud-Version Kubernetes-Version Version der CIS-Kubernetes-Benchmark
1.16.0 1.27.4-gke.1600 V1.23 (1.0.1)

Beachten Sie, dass die Versionsnummern für verschiedene Benchmarks möglicherweise nicht identisch sind.

CIS-Kubernetes-Benchmark

Die folgenden Abschnitte enthalten grundlegende Informationen zur Interpretation des CIS-Kubernetes-Benchmarkstatus für Google Distributed Cloud.

Auf die Benchmark zugreifen

Die CIS-Kubernetes-Benchmark steht auf der CIS-Website zur Verfügung.

Empfehlungsstufen

In der CIS-Kubernetes-Benchmark:

Stufe Beschreibung
Stufe 1

Die Empfehlungen sollen:

  • praxisnah und effektiv sein,
  • einen klaren Sicherheitsvorteil bieten und
  • den Nutzen der Technologie nicht über das akzeptable Maß hinaus beeinträchtigen.
  • Stufe 2

    Erweitert das Profil von Stufe 1.

    Die Empfehlungen weisen eine oder mehrere der folgenden Eigenschaften auf:

  • Sie sind für Umgebungen oder Anwendungsfälle vorgesehen, in denen Sicherheit oberste Priorität hat.
  • Sie dienen als Defense-in-Depth-Maßnahme.
  • Sie beeinträchtigen unter Umständen den Nutzen oder die Leistung der Technologie.
  • 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.

    Evaluierung in Google Distributed Cloud

    Mit den folgenden Werten legen wir den Status von Kubernetes-Empfehlungen in Google Distributed Cloud fest:

    Status Beschreibung
    Bestanden Entspricht einer Benchmarkempfehlung.
    Nicht bestanden Entspricht nicht einer Benchmarkempfehlung.
    Gleichwertige Kontrolle Entspricht nicht genau den Bedingungen, die in der Benchmarkempfehlung enthalten sind. Google Distributed Cloud bietet jedoch andere Mechanismen, um gleichwertige Sicherheitskontrollen bereitzustellen.
    Umgebungsabhängig Google Distributed Cloud konfiguriert keine Elemente für diese Empfehlung. Die Konfiguration des Nutzers bestimmt, ob die Umgebung einer Benchmarkempfehlung entspricht.

    Google Distributed Cloud-Architektur

    Google Distributed Cloud unterstützt mehrere Clusterkonfigurationen und Clustertypen. Jeder unterstützte Clustertyp, Administrator, Nutzer, Hybrid und eigenständige Cluster werden anhand der CIS-Benchmark bewertet. Die folgenden Prüfungen und Begründungen gelten für alle unterstützten Clustertypen. Weitere Informationen zu den von Google Distributed Cloud unterstützten Clusterkonfigurationen finden Sie unter Bereitstellungsmodelle auswählen.

    Status in Google Distributed Cloud

    Die folgenden Abschnitte enthalten die Bewertungen für neue Cluster, die mit der angegebenen Version von Google Distributed Cloud erstellt wurden. Diese Bewertungen sind ein Indikator dafür, wie neue Cluster ohne Nutzerarbeitslasten im Vergleich zur CIS-Kubernetes-Benchmark abschneiden. Wenn Sie Ihre eigenen Arbeitslasten bereitstellen, bevor Sie die Benchmarks selbst prüfen, können Ihre Ergebnisse anders ausfallen.

    Status von GKE on Bare Metal-Clustern:

    1,29

    # Empfehlung Level Status
    1 cis-1.8
    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). L1 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). L1 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). L1 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). L1 Bestanden
    1.1.5 Achten Sie darauf, dass die Berechtigungen für die Pod-Spezifikationsdatei des Planers auf 600 oder restriktiver festgelegt sind (automatisiert). L1 Bestanden
    1.1.6 Achten Sie darauf, dass die Eigentümerschaft für die Pod-Spezifikationsdatei des Planers auf root:root festgelegt ist (automatisiert). L1 Bestanden
    1.1.7 Achten Sie darauf, dass die Berechtigungen für die Pod-Spezifikationsdatei von etcd auf 600 oder restriktiver festgelegt sind (automatisiert). L1 Bestanden
    1.1.8 Achten Sie darauf, dass die Eigentümerschaft für die Pod-Spezifikationsdatei von etcd auf root:root festgelegt ist (automatisiert). L1 Bestanden
    1.1.9 Achten Sie darauf, dass die Berechtigungen für die Container Network Interface-Datei auf 600 oder restriktiver festgelegt sind (manuell). L1 Gleichwertige Kontrolle
    1.1.10 Achten Sie darauf, dass Eigentümerschaft für die Container Network Interface-Datei auf root:root festgelegt ist (manuell). L1 Bestanden
    1.1.11 Achten Sie darauf, dass die Berechtigungen für das etcd-Datenverzeichnis auf 700 oder restriktiver festgelegt sind (automatisiert). L1 Gleichwertige Kontrolle
    1.1.12 Achten Sie darauf, dass die Eigentümerschaft für das etcd-Datenverzeichnisses auf etcd:etcd festgelegt ist (automatisiert). L1 Gleichwertige Kontrolle
    1.1.13 Achten Sie darauf, dass die Berechtigungen für die admin.conf-Datei auf 600 oder restriktiver festgelegt sind (automatisiert). L1 Bestanden
    1.1.14 Achten Sie darauf, dass die Eigentümerschaft für die admin.conf-Datei auf root:root festgelegt ist (automatisiert). L1 Bestanden
    1.1.15 Achten Sie darauf, dass die Berechtigungen für die scheduler.conf-Datei auf 600 oder restriktiver festgelegt sind (automatisiert). L1 Bestanden
    1.1.16 Achten Sie darauf, dass die Eigentümerschaft für die scheduler.conf-Datei auf root:root festgelegt ist (automatisiert). L1 Gleichwertige Kontrolle
    1.1.17 Achten Sie darauf, dass die Berechtigungen für die controller-manager.conf-Datei auf 600 oder restriktiver festgelegt sind (automatisiert). L1 Bestanden
    1.1.18 Achten Sie darauf, dass die Eigentümerschaft für die controller-manager.conf-Datei auf root:root festgelegt ist (automatisiert). L1 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). L1 Gleichwertige Kontrolle
    1.1.20 Achten Sie darauf, dass die Berechtigungen für die Kubernetes-PKI-Zertifikatsdatei auf 600 oder restriktiver festgelegt sind (manuell). L1 Gleichwertige Kontrolle
    1.1.21 Achten Sie darauf, dass die Berechtigungen für die Kubernetes-PKI-Schlüsseldatei auf 600 festgelegt sind (manuell). L1 Gleichwertige Kontrolle
    1.2 API-Server
    1.2.1 Achten Sie darauf, dass das Argument --anonymous-auth auf "false" festgelegt ist (manuell). L1 Warnen
    1.2.2 Der Parameter --token-auth-file darf nicht festgelegt sein (automatisiert). L1 Bestanden
    1.2.3 Der Parameter --DenyServiceExternalIPs muss festgelegt sein (manuell). L1 Gleichwertige Kontrolle
    1.2.4 Die Argumente --kubelet-client-certificate und --kubelet-client-key müssen entsprechend festgelegt sein (automatisiert). L1 Bestanden
    1.2.5 Das Argument --kubelet-certificate-authority muss entsprechend festgelegt sein (automatisiert). L1 Bestanden
    1.2.6 Das Argument --authorization-mode darf nicht auf "AlwaysAllow" festgelegt sein (automatisiert). L1 Bestanden
    1.2.7 Das Argument --authorization-mode muss Node enthalten (automatisiert). L1 Bestanden
    1.2.8 Das Argument --authorization-mode muss RBAC enthalten (automatisiert). L1 Bestanden
    1.2.9 Das Zugangskontroll-Plug-in "EventRateLimit" muss festgelegt sein (manuell). L1 Warnen
    1.2.10 Das Zugangskontroll-Plug-in "AlwaysAdmit" darf nicht festgelegt sein (automatisiert). L1 Bestanden
    1.2.11 Das Zugangskontroll-Plug-in "AlwaysPullImages" muss festgelegt sein (manuell). L1 Warnen
    1.2.12 Das Zugangskontroll-Plug-in "SecurityContextDeny" muss festgelegt sein, wenn "PodSecurityPolicy" nicht verwendet wird (manuell). L1 Warnen
    1.2.13 Das Zugangskontroll-Plug-in "ServiceAccount" muss festgelegt sein (automatisiert). L1 Warnen
    1.2.14 Das Zugangskontroll-Plug-in "NamespaceLifecycle" muss festgelegt sein (automatisiert). L1 Bestanden
    1.2.15 Das Zugangskontroll-Plug-in "NodeRestriction" muss festgelegt sein (automatisiert). L1 Bestanden
    1.2.16 Achten Sie darauf, dass das Argument --profiling auf "false" festgelegt ist (automatisiert). L1 Bestanden
    1.2.17 Das Argument --audit-log-path muss festgelegt sein (automatisiert). L1 Bestanden
    1.2.18 Achten Sie darauf, dass das Argument --audit-log-maxage auf 30 oder nach Bedarf festgelegt ist (automatisiert). L1 Bestanden
    1.2.19 Achten Sie darauf, dass das Argument --audit-log-maxbackup auf 10 oder nach Bedarf festgelegt ist (automatisiert). L1 Bestanden
    1.2.20 Achten Sie darauf, dass das Argument --audit-log-maxsize auf 100 oder nach Bedarf festgelegt ist (automatisiert). L1 Bestanden
    1.2.21 Das Argument --request-timeout muss entsprechend festgelegt sein (manuell). L1 Bestanden
    1.2.22 Achten Sie darauf, dass das Argument --service-account-lookup auf "true" festgelegt ist (automatisiert). L1 Bestanden
    1.2.23 Das Argument --service-account-key-file muss entsprechend festgelegt sein (automatisiert). L1 Bestanden
    1.2.24 Die Argumente --etcd-certfile und --etcd-keyfile müssen entsprechend festgelegt sein (automatisiert). L1 Bestanden
    1.2.25 Die Argumente --tls-cert-file und --tls-private-key-file müssen entsprechend festgelegt sein (automatisiert). L1 Bestanden
    1.2.26 Das Argument --client-ca-file muss entsprechend festgelegt sein (automatisiert). L1 Bestanden
    1.2.27 Das Argument --etcd-cafile muss entsprechend festgelegt sein (automatisiert). L1 Bestanden
    1.2.28 Das Argument --encryption-provider-config muss entsprechend festgelegt sein (manuell). L1 Bestanden
    1.2.29 Verschlüsselungsanbieter sollten entsprechend konfiguriert sein (manuell). L1 Bestanden
    1.2.30 Der API-Server darf nur starke kryptografische Chiffren verwenden (manuell). L1 Bestanden
    1.3 Controller-Manager
    1.3.1 Das Argument --terminated-pod-gc-threshold muss entsprechend festgelegt sein (manuell). L1 Bestanden
    1.3.2 Achten Sie darauf, dass das Argument --profiling auf "false" festgelegt ist (automatisiert). L1 Bestanden
    1.3.3 Achten Sie darauf, dass das Argument --use-service-account-credentials auf "true" festgelegt ist (automatisiert). L1 Bestanden
    1.3.4 Das Argument --service-account-private-key-file muss entsprechend festgelegt sein (automatisiert). L1 Bestanden
    1.3.5 Das Argument --root-ca-file muss entsprechend festgelegt sein (automatisiert). L1 Bestanden
    1.3.6 Das Argument "RotateKubeletServerCertificate" muss auf "true" festgelegt sein (automatisiert). L2 Bestanden
    1.3.7 Das Argument --bind-address muss auf 127.0.0.1 festgelegt sein (automatisiert). L1 Warnen
    1.4 Planer
    1.4.1 Achten Sie darauf, dass das Argument --profiling auf "false" festgelegt ist (automatisiert). L1 Bestanden
    1.4.2 Das Argument --bind-address muss auf 127.0.0.1 festgelegt sein (automatisiert). L1 Warnen
    2 cis-1.8
    2 Etcd-Knotenkonfiguration
    2.1 Die Argumente --cert-file und --key-file müssen entsprechend festgelegt sein (automatisiert). L1 Bestanden
    2,2 Achten Sie darauf, dass das Argument --client-cert-auth auf "true" festgelegt ist (automatisiert). L1 Bestanden
    2,3 Achten Sie darauf, dass das Argument --auto-tls nicht auf "true" festgelegt ist (automatisiert). L1 Bestanden
    2.4 Die Argumente --peer-cert-file und --peer-key-file müssen entsprechend festgelegt sein (automatisiert). L1 Bestanden
    2,5 Achten Sie darauf, dass das Argument --peer-client-cert-auth auf "true" festgelegt ist (automatisiert). L1 Bestanden
    2,6 Achten Sie darauf, dass das Argument --peer-auto-tls nicht auf "true" festgelegt ist (automatisiert). L1 Bestanden
    2.7 Für etcd muss eine eindeutige Zertifizierungsstelle verwendet werden (manuell). L2 Bestanden
    3 cis-1.8
    3.1 Authentifizierung und Autorisierung
    3.1.1 Die Clientzertifikatsauthentifizierung sollte nicht für Nutzer verwendet werden (manuell). L2 Bestanden
    3.1.2 Die Authentifizierung von Dienstkonto-Tokens sollte nicht für Nutzer verwendet werden (manuell). L1 Bestanden
    3.1.3 Die Bootstrap-Tokenauthentifizierung sollte nicht für Nutzer verwendet werden (manuell). L1 Bestanden
    3.2 Logging
    3.2.1 Eine Audit-Mindestrichtlinie muss erstellt sein (manuell). L1 Bestanden
    3.2.2 Die Audit-Richtlinie muss wichtige Sicherheitsaspekte abdecken (manuell). L2 Gleichwertige Kontrolle
    4 cis-1.8
    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). L1 Nicht bestanden
    4.1.2 Die Eigentümerschaft der kubelet-Servicedatei muss auf root:root festgelegt sein (automatisiert). L1 Bestanden
    4.1.3 Wenn die Proxy-kubeconfig-Datei vorhanden ist, müssen die Berechtigungen auf 600 oder restriktiver festgelegt sein (manuell). L1 Bestanden
    4.1.4 Wenn die Proxy-kubeconfig-Datei vorhanden ist, müssen Sie die Inhaberschaft auf root:root festlegen (manuell). L1 Bestanden
    4.1.5 Die Berechtigungen für die Datei --kubeconfig kubelet.conf müssen auf 600 festgelegt oder restriktiver sein (automatisiert). L1 Bestanden
    4.1.6 Die Eigentümerschaft für die Datei --kubeconfig kubelet.conf muss auf root:root festgelegt sein (automatisiert). L1 Bestanden
    4.1.7 Die Berechtigungen für die Zertifizierungsstellendatei muss auf 600 festgelegt oder restriktiver sein (manuell). L1 Nicht bestanden
    4.1.8 Die Eigentümerschaft für die Client-Zertifizierungsstellendatei muss auf root:root festgelegt sein (manuell). L1 Bestanden
    4.1.9 Wenn die Kubelet-Konfigurationsdatei config.yaml verwendet wird, müssen die Berechtigungen auf 600 oder restriktiver gesetzt werden (automatisiert). L1 Nicht bestanden
    4.1.10 Wenn die kubelet-config.yaml-Konfigurationsdatei verwendet wird, prüfen Sie, ob die Eigentümerschaft für die Datei auf root:root festgelegt ist (automatisiert). L1 Bestanden
    4.2 Kubelet
    4.2.1 Achten Sie darauf, dass das Argument --anonymous-auth auf "false" festgelegt ist (automatisiert). L1 Bestanden
    4.2.2 Das Argument --authorization-mode darf nicht auf "AlwaysAllow" festgelegt sein (automatisiert). L1 Bestanden
    4.2.3 Das Argument --client-ca-file muss entsprechend festgelegt sein (automatisiert). L1 Bestanden
    4.2.4 Das Argument --read-only-port muss auf 0 festgelegt sein (manuell). L1 Bestanden
    4.2.5 Das Argument --streaming-connection-idle-timeout darf nicht auf 0 gesetzt sein (manuell). L1 Bestanden
    4.2.6 Achten Sie darauf, dass das Argument --make-iptables-util-chains auf "true" festgelegt ist (automatisiert). L1 Nicht bestanden
    4.2.7 Das Argument --hostname-override darf nicht festgelegt sein (manuell). L1 Bestanden
    4.2.8 Das Argument "eventRecordQPS" muss auf eine Ebene festgelegt sein, die geeignete Ereigniserfassung ermöglicht (manuell). L1 Bestanden
    4.2.9 Die Argumente --tls-cert-file und --tls-private-key-file müssen entsprechend festgelegt sein (manuell). L2 Gleichwertige Kontrolle
    4.2.10 Das Argument --rotate-certificates darf nicht auf „false” gesetzt sein (automatisiert). L1 Gleichwertige Kontrolle
    4.2.11 Das Argument "RotateletServerCertificate" muss auf "true" festgelegt sein (manuell). L1 Bestanden
    4.2.12 Achten Sie darauf, dass das Kubelet nur starke kryptografische Chiffren verwendet (manuell). L1 Bestanden
    4.2.13 Für die Pod-PIDs muss ein Limit festgelegt sein (manuell). L1 Warnen

    1,28

    # Empfehlung Level Status
    1 cis-1.7
    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). L1 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). L1 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). L1 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). L1 Bestanden
    1.1.5 Achten Sie darauf, dass die Berechtigungen für die Pod-Spezifikationsdatei des Planers auf 600 oder restriktiver festgelegt sind (automatisiert). L1 Bestanden
    1.1.6 Achten Sie darauf, dass die Eigentümerschaft für die Pod-Spezifikationsdatei des Planers auf root:root festgelegt ist (automatisiert). L1 Bestanden
    1.1.7 Achten Sie darauf, dass die Berechtigungen für die Pod-Spezifikationsdatei von etcd auf 600 oder restriktiver festgelegt sind (automatisiert). L1 Bestanden
    1.1.8 Achten Sie darauf, dass die Eigentümerschaft für die Pod-Spezifikationsdatei von etcd auf root:root festgelegt ist (automatisiert). L1 Bestanden
    1.1.9 Achten Sie darauf, dass die Berechtigungen für die Container Network Interface-Datei auf 600 oder restriktiver festgelegt sind (manuell). L1 Gleichwertige Kontrolle
    1.1.10 Achten Sie darauf, dass Eigentümerschaft für die Container Network Interface-Datei auf root:root festgelegt ist (manuell). L1 Bestanden
    1.1.11 Achten Sie darauf, dass die Berechtigungen für das etcd-Datenverzeichnis auf 700 oder restriktiver festgelegt sind (automatisiert). L1 Gleichwertige Kontrolle
    1.1.12 Achten Sie darauf, dass die Eigentümerschaft für das etcd-Datenverzeichnisses auf etcd:etcd festgelegt ist (automatisiert). L1 Gleichwertige Kontrolle
    1.1.13 Achten Sie darauf, dass die Berechtigungen für die admin.conf-Datei auf 600 oder restriktiver festgelegt sind (automatisiert). L1 Bestanden
    1.1.14 Achten Sie darauf, dass die Eigentümerschaft für die admin.conf-Datei auf root:root festgelegt ist (automatisiert). L1 Bestanden
    1.1.15 Achten Sie darauf, dass die Berechtigungen für die scheduler.conf-Datei auf 600 oder restriktiver festgelegt sind (automatisiert). L1 Bestanden
    1.1.16 Achten Sie darauf, dass die Eigentümerschaft für die scheduler.conf-Datei auf root:root festgelegt ist (automatisiert). L1 Gleichwertige Kontrolle
    1.1.17 Achten Sie darauf, dass die Berechtigungen für die controller-manager.conf-Datei auf 600 oder restriktiver festgelegt sind (automatisiert). L1 Bestanden
    1.1.18 Achten Sie darauf, dass die Eigentümerschaft für die controller-manager.conf-Datei auf root:root festgelegt ist (automatisiert). L1 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). L1 Gleichwertige Kontrolle
    1.1.20 Achten Sie darauf, dass die Berechtigungen für die Kubernetes-PKI-Zertifikatsdatei auf 600 oder restriktiver festgelegt sind (manuell). L1 Gleichwertige Kontrolle
    1.1.21 Achten Sie darauf, dass die Berechtigungen für die Kubernetes-PKI-Schlüsseldatei auf 600 festgelegt sind (manuell). L1 Gleichwertige Kontrolle
    1.2 API-Server
    1.2.1 Achten Sie darauf, dass das Argument --anonymous-auth auf "false" festgelegt ist (manuell). L1 Warnen
    1.2.2 Der Parameter --token-auth-file darf nicht festgelegt sein (automatisiert). L1 Bestanden
    1.2.3 Der Parameter --DenyServiceExternalIPs muss festgelegt sein (manuell). L1 Gleichwertige Kontrolle
    1.2.4 Die Argumente --kubelet-client-certificate und --kubelet-client-key müssen entsprechend festgelegt sein (automatisiert). L1 Bestanden
    1.2.5 Das Argument --kubelet-certificate-authority muss entsprechend festgelegt sein (automatisiert). L1 Bestanden
    1.2.6 Das Argument --authorization-mode darf nicht auf "AlwaysAllow" festgelegt sein (automatisiert). L1 Bestanden
    1.2.7 Das Argument --authorization-mode muss Node enthalten (automatisiert). L1 Bestanden
    1.2.8 Das Argument --authorization-mode muss RBAC enthalten (automatisiert). L1 Bestanden
    1.2.9 Das Zugangskontroll-Plug-in "EventRateLimit" muss festgelegt sein (manuell). L1 Warnen
    1.2.10 Das Zugangskontroll-Plug-in "AlwaysAdmit" darf nicht festgelegt sein (automatisiert). L1 Bestanden
    1.2.11 Das Zugangskontroll-Plug-in "AlwaysPullImages" muss festgelegt sein (manuell). L1 Warnen
    1.2.12 Das Zugangskontroll-Plug-in "SecurityContextDeny" muss festgelegt sein, wenn "PodSecurityPolicy" nicht verwendet wird (manuell). L1 Warnen
    1.2.13 Das Zugangskontroll-Plug-in "ServiceAccount" muss festgelegt sein (automatisiert). L1 Warnen
    1.2.14 Das Zugangskontroll-Plug-in "NamespaceLifecycle" muss festgelegt sein (automatisiert). L1 Bestanden
    1.2.15 Das Zugangskontroll-Plug-in "NodeRestriction" muss festgelegt sein (automatisiert). L1 Bestanden
    1.2.16 Das Argument --secure-port darf nicht auf 0 gesetzt sein. Beachten Sie, dass diese Empfehlung veraltet ist und gemäß dem Konsensprozess gelöscht wird (manuell). L1 Bestanden
    1.2.17 Achten Sie darauf, dass das Argument --profiling auf "false" festgelegt ist (automatisiert). L1 Bestanden
    1.2.18 Das Argument --audit-log-path muss festgelegt sein (automatisiert). L1 Bestanden
    1.2.19 Achten Sie darauf, dass das Argument --audit-log-maxage auf 30 oder nach Bedarf festgelegt ist (automatisiert). L1 Bestanden
    1.2.20 Achten Sie darauf, dass das Argument --audit-log-maxbackup auf 10 oder nach Bedarf festgelegt ist (automatisiert). L1 Nicht bestanden
    1.2.21 Achten Sie darauf, dass das Argument --audit-log-maxsize auf 100 oder nach Bedarf festgelegt ist (automatisiert). L1 Bestanden
    1.2.22 Das Argument --request-timeout muss entsprechend festgelegt sein (manuell). L1 Bestanden
    1.2.23 Achten Sie darauf, dass das Argument --service-account-lookup auf "true" festgelegt ist (automatisiert). L1 Bestanden
    1.2.24 Das Argument --service-account-key-file muss entsprechend festgelegt sein (automatisiert). L1 Bestanden
    1.2.25 Die Argumente --etcd-certfile und --etcd-keyfile müssen entsprechend festgelegt sein (automatisiert). L1 Bestanden
    1.2.26 Die Argumente --tls-cert-file und --tls-private-key-file müssen entsprechend festgelegt sein (automatisiert). L1 Bestanden
    1.2.27 Das Argument --client-ca-file muss entsprechend festgelegt sein (automatisiert). L1 Bestanden
    1.2.28 Das Argument --etcd-cafile muss entsprechend festgelegt sein (automatisiert). L1 Bestanden
    1.2.29 Das Argument --encryption-provider-config muss entsprechend festgelegt sein (manuell). L1 Bestanden
    1.2.30 Verschlüsselungsanbieter sollten entsprechend konfiguriert sein (manuell). L1 Bestanden
    1.2.31 Der API-Server darf nur starke kryptografische Chiffren verwenden (manuell). L1 Bestanden
    1.3 Controller-Manager
    1.3.1 Das Argument --terminated-pod-gc-threshold muss entsprechend festgelegt sein (manuell). L1 Bestanden
    1.3.2 Achten Sie darauf, dass das Argument --profiling auf "false" festgelegt ist (automatisiert). L1 Bestanden
    1.3.3 Achten Sie darauf, dass das Argument --use-service-account-credentials auf "true" festgelegt ist (automatisiert). L1 Bestanden
    1.3.4 Das Argument --service-account-private-key-file muss entsprechend festgelegt sein (automatisiert). L1 Bestanden
    1.3.5 Das Argument --root-ca-file muss entsprechend festgelegt sein (automatisiert). L1 Bestanden
    1.3.6 Das Argument "RotateKubeletServerCertificate" muss auf "true" festgelegt sein (automatisiert). L2 Bestanden
    1.3.7 Das Argument --bind-address muss auf 127.0.0.1 festgelegt sein (automatisiert). L1 Warnen
    1.4 Planer
    1.4.1 Achten Sie darauf, dass das Argument --profiling auf "false" festgelegt ist (automatisiert). L1 Bestanden
    1.4.2 Das Argument --bind-address muss auf 127.0.0.1 festgelegt sein (automatisiert). L1 Warnen
    2 cis-1.7
    2 Etcd-Knotenkonfiguration
    2.1 Die Argumente --cert-file und --key-file müssen entsprechend festgelegt sein (automatisiert). L1 Bestanden
    2,2 Achten Sie darauf, dass das Argument --client-cert-auth auf "true" festgelegt ist (automatisiert). L1 Bestanden
    2,3 Achten Sie darauf, dass das Argument --auto-tls nicht auf "true" festgelegt ist (automatisiert). L1 Bestanden
    2.4 Die Argumente --peer-cert-file und --peer-key-file müssen entsprechend festgelegt sein (automatisiert). L1 Bestanden
    2,5 Achten Sie darauf, dass das Argument --peer-client-cert-auth auf "true" festgelegt ist (automatisiert). L1 Bestanden
    2,6 Achten Sie darauf, dass das Argument --peer-auto-tls nicht auf "true" festgelegt ist (automatisiert). L1 Bestanden
    2.7 Für etcd muss eine eindeutige Zertifizierungsstelle verwendet werden (manuell). L2 Bestanden
    3 cis-1.7
    3.1 Authentifizierung und Autorisierung
    3.1.1 Die Clientzertifikatsauthentifizierung sollte nicht für Nutzer verwendet werden (manuell). L2 Bestanden
    3.1.2 Die Authentifizierung von Dienstkonto-Tokens sollte nicht für Nutzer verwendet werden (manuell). L1 Bestanden
    3.1.3 Die Bootstrap-Tokenauthentifizierung sollte nicht für Nutzer verwendet werden (manuell). L1 Bestanden
    3.2 Logging
    3.2.1 Eine Audit-Mindestrichtlinie muss erstellt sein (manuell). L1 Bestanden
    3.2.2 Die Audit-Richtlinie muss wichtige Sicherheitsaspekte abdecken (manuell). L2 Gleichwertige Kontrolle
    4 cis-1.7
    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). L1 Nicht bestanden
    4.1.2 Die Eigentümerschaft der kubelet-Servicedatei muss auf root:root festgelegt sein (automatisiert). L1 Bestanden
    4.1.3 Wenn die Proxy-kubeconfig-Datei vorhanden ist, müssen die Berechtigungen auf 600 oder restriktiver festgelegt sein (manuell). L1 Bestanden
    4.1.4 Wenn die Proxy-kubeconfig-Datei vorhanden ist, müssen Sie die Inhaberschaft auf root:root festlegen (manuell). L1 Bestanden
    4.1.5 Die Berechtigungen für die Datei --kubeconfig kubelet.conf müssen auf 600 festgelegt oder restriktiver sein (automatisiert). L1 Bestanden
    4.1.6 Die Eigentümerschaft für die Datei --kubeconfig kubelet.conf muss auf root:root festgelegt sein (automatisiert). L1 Bestanden
    4.1.7 Die Berechtigungen für die Zertifizierungsstellendatei muss auf 600 festgelegt oder restriktiver sein (manuell). L1 Nicht bestanden
    4.1.8 Die Eigentümerschaft für die Client-Zertifizierungsstellendatei muss auf root:root festgelegt sein (manuell). L1 Bestanden
    4.1.9 Wenn die Kubelet-Konfigurationsdatei config.yaml verwendet wird, müssen die Berechtigungen auf 600 oder restriktiver gesetzt werden (manuell). L1 Nicht bestanden
    4.1.10 Wenn die kubelet config.yaml-Konfigurationsdatei verwendet wird, prüfen Sie, ob der Eigentümer der Datei auf root:root (manuell) gesetzt ist. L1 Bestanden
    4.2 Kubelet
    4.2.1 Achten Sie darauf, dass das Argument --anonymous-auth auf "false" festgelegt ist (automatisiert). L1 Bestanden
    4.2.2 Das Argument --authorization-mode darf nicht auf "AlwaysAllow" festgelegt sein (automatisiert). L1 Bestanden
    4.2.3 Das Argument --client-ca-file muss entsprechend festgelegt sein (automatisiert). L1 Bestanden
    4.2.4 Das Argument --read-only-port muss auf 0 festgelegt sein (manuell). L1 Bestanden
    4.2.5 Das Argument --streaming-connection-idle-timeout darf nicht auf 0 gesetzt sein (manuell). L1 Bestanden
    4.2.6 Achten Sie darauf, dass das Argument --make-iptables-util-chains auf "true" festgelegt ist (automatisiert). L1 Nicht bestanden
    4.2.7 Das Argument --hostname-override darf nicht festgelegt sein (manuell). L1 Bestanden
    4.2.8 Das Argument "eventRecordQPS" muss auf eine Ebene festgelegt sein, die geeignete Ereigniserfassung ermöglicht (manuell). L1 Bestanden
    4.2.9 Die Argumente --tls-cert-file und --tls-private-key-file müssen entsprechend festgelegt sein (manuell). L2 Gleichwertige Kontrolle
    4.2.10 Das Argument --rotate-certificates darf nicht auf „false” gesetzt sein (automatisiert). L1 Gleichwertige Kontrolle
    4.2.11 Das Argument "RotateletServerCertificate" muss auf "true" festgelegt sein (manuell). L1 Bestanden
    4.2.12 Achten Sie darauf, dass das Kubelet nur starke kryptografische Chiffren verwendet (manuell). L1 Bestanden
    4.2.13 Für die Pod-PIDs muss ein Limit festgelegt sein (manuell). L1 Warnen

    1.16

    # Empfehlung Level Status
    1 cis-1.23
    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 644 oder restriktiver festgelegt sind (automatisiert). L1 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). L1 Bestanden
    1.1.3 Achten Sie darauf, dass die Berechtigungen für die Pod-Spezifikationsdatei des Controller-Managers auf 644 oder restriktiver festgelegt sind (automatisiert). L1 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). L1 Bestanden
    1.1.5 Achten Sie darauf, dass die Berechtigungen für die Pod-Spezifikationsdatei des Planers auf 644 oder restriktiver festgelegt sind (automatisiert). L1 Bestanden
    1.1.6 Achten Sie darauf, dass die Eigentümerschaft für die Pod-Spezifikationsdatei des Planers auf root:root festgelegt ist (automatisiert). L1 Bestanden
    1.1.7 Achten Sie darauf, dass die Berechtigungen für die Pod-Spezifikationsdatei von etcd auf 644 oder restriktiver festgelegt sind (automatisiert). L1 Bestanden
    1.1.8 Achten Sie darauf, dass die Eigentümerschaft für die Pod-Spezifikationsdatei von etcd auf root:root festgelegt ist (automatisiert). L1 Bestanden
    1.1.9 Achten Sie darauf, dass die Berechtigungen für die Container Network Interface-Datei auf 644 oder restriktiver festgelegt sind (manuell). L1 Gleichwertige Kontrolle
    1.1.10 Achten Sie darauf, dass Eigentümerschaft für die Container Network Interface-Datei auf root:root festgelegt ist (manuell). L1 Bestanden
    1.1.11 Achten Sie darauf, dass die Berechtigungen für das etcd-Datenverzeichnis auf 700 oder restriktiver festgelegt sind (automatisiert). L1 Gleichwertige Kontrolle
    1.1.12 Achten Sie darauf, dass die Eigentümerschaft für das etcd-Datenverzeichnisses auf etcd:etcd festgelegt ist (automatisiert). L1 Gleichwertige Kontrolle
    1.1.13 Achten Sie darauf, dass die Berechtigungen für die admin.conf-Datei auf 600 oder restriktiver festgelegt sind (automatisiert). L1 Bestanden
    1.1.14 Achten Sie darauf, dass die Eigentümerschaft für die admin.conf-Datei auf root:root festgelegt ist (automatisiert). L1 Bestanden
    1.1.15 Achten Sie darauf, dass die Berechtigungen für die scheduler.conf-Datei auf 644 oder restriktiver festgelegt sind (automatisiert). L1 Bestanden
    1.1.16 Achten Sie darauf, dass die Eigentümerschaft für die scheduler.conf-Datei auf root:root festgelegt ist (automatisiert). L1 Gleichwertige Kontrolle
    1.1.17 Achten Sie darauf, dass die Berechtigungen für die controller-manager.conf-Datei auf 644 oder restriktiver festgelegt sind (automatisiert). L1 Bestanden
    1.1.18 Achten Sie darauf, dass die Eigentümerschaft für die controller-manager.conf-Datei auf root:root festgelegt ist (automatisiert). L1 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). L1 Gleichwertige Kontrolle
    1.1.20 Achten Sie darauf, dass die Berechtigungen für die Kubernetes-PKI-Zertifikatsdatei auf 644 oder restriktiver festgelegt sind (manuell). L1 Bestanden
    1.1.21 Achten Sie darauf, dass die Berechtigungen für die Kubernetes-PKI-Schlüsseldatei auf 600 festgelegt sind (manuell). L1 Gleichwertige Kontrolle
    1.2 API-Server
    1.2.1 Achten Sie darauf, dass das Argument --anonymous-auth auf "false" festgelegt ist (manuell). L1 Warnen
    1.2.2 Der Parameter --token-auth-file darf nicht festgelegt sein (automatisiert). L1 Bestanden
    1.2.3 Der Parameter --DenyServiceExternalIPs darf nicht festgelegt sein (automatisiert). L1 Bestanden
    1.2.4 Achten Sie darauf, dass das Argument --kubelet-https auf "true" festgelegt ist (automatisiert). L1 Bestanden
    1.2.5 Die Argumente --kubelet-client-certificate und --kubelet-client-key müssen entsprechend festgelegt sein (automatisiert). L1 Bestanden
    1.2.6 Das Argument --kubelet-certificate-authority muss entsprechend festgelegt sein (automatisiert). L1 Bestanden
    1.2.7 Das Argument --authorization-mode darf nicht auf "AlwaysAllow" festgelegt sein (automatisiert). L1 Bestanden
    1.2.8 Das Argument --authorization-mode muss Node enthalten (automatisiert). L1 Bestanden
    1.2.9 Das Argument --authorization-mode muss RBAC enthalten (automatisiert). L1 Bestanden
    1.2.10 Das Zugangskontroll-Plug-in "EventRateLimit" muss festgelegt sein (manuell). L1 Warnen
    1.2.11 Das Zugangskontroll-Plug-in "AlwaysAdmit" darf nicht festgelegt sein (automatisiert). L1 Bestanden
    1.2.12 Das Zugangskontroll-Plug-in "AlwaysPullImages" muss festgelegt sein (manuell). L1 Warnen
    1.2.13 Das Zugangskontroll-Plug-in "SecurityContextDeny" muss festgelegt sein, wenn "PodSecurityPolicy" nicht verwendet wird (manuell). L1 Warnen
    1.2.14 Das Zugangskontroll-Plug-in "ServiceAccount" muss festgelegt sein (automatisiert). L1 Bestanden
    1.2.15 Das Zugangskontroll-Plug-in "NamespaceLifecycle" muss festgelegt sein (automatisiert). L1 Bestanden
    1.2.16 Das Zugangskontroll-Plug-in "NodeRestriction" muss festgelegt sein (automatisiert). L1 Bestanden
    1.2.17 Das Argument --secure-port darf nicht auf 0 festgelegt sein (automatisiert). L1 Bestanden
    1.2.18 Achten Sie darauf, dass das Argument --profiling auf "false" festgelegt ist (automatisiert). L1 Bestanden
    1.2.19 Das Argument --audit-log-path muss festgelegt sein (automatisiert). L1 Nicht bestanden
    1.2.20 Achten Sie darauf, dass das Argument --audit-log-maxage auf 30 oder nach Bedarf festgelegt ist (automatisiert). L1 Nicht bestanden
    1.2.21 Achten Sie darauf, dass das Argument --audit-log-maxbackup auf 10 oder nach Bedarf festgelegt ist (automatisiert). L1 Nicht bestanden
    1.2.22 Achten Sie darauf, dass das Argument --audit-log-maxsize auf 100 oder nach Bedarf festgelegt ist (automatisiert). L1 Nicht bestanden
    1.2.23 Das Argument --request-timeout muss entsprechend festgelegt sein (manuell). L1 Bestanden
    1.2.24 Achten Sie darauf, dass das Argument --service-account-lookup auf "true" festgelegt ist (automatisiert). L1 Bestanden
    1.2.25 Das Argument --service-account-key-file muss entsprechend festgelegt sein (automatisiert). L1 Bestanden
    1.2.26 Die Argumente --etcd-certfile und --etcd-keyfile müssen entsprechend festgelegt sein (automatisiert). L1 Bestanden
    1.2.27 Die Argumente --tls-cert-file und --tls-private-key-file müssen entsprechend festgelegt sein (automatisiert). L1 Bestanden
    1.2.28 Das Argument --client-ca-file muss entsprechend festgelegt sein (automatisiert). L1 Bestanden
    1.2.29 Das Argument --etcd-cafile muss entsprechend festgelegt sein (automatisiert). L1 Bestanden
    1.2.30 Das Argument --encryption-provider-config muss entsprechend festgelegt sein (manuell). L1 Bestanden
    1.2.31 Verschlüsselungsanbieter sollten entsprechend konfiguriert sein (manuell). L1 Bestanden
    1.2.32 Der API-Server darf nur starke kryptografische Chiffren verwenden (manuell). L1 Bestanden
    1.3 Controller-Manager
    1.3.1 Das Argument --terminated-pod-gc-threshold muss entsprechend festgelegt sein (manuell). L1 Bestanden
    1.3.2 Achten Sie darauf, dass das Argument --profiling auf "false" festgelegt ist (automatisiert). L1 Bestanden
    1.3.3 Achten Sie darauf, dass das Argument --use-service-account-credentials auf "true" festgelegt ist (automatisiert). L1 Bestanden
    1.3.4 Das Argument --service-account-private-key-file muss entsprechend festgelegt sein (automatisiert). L1 Bestanden
    1.3.5 Das Argument --root-ca-file muss entsprechend festgelegt sein (automatisiert). L1 Bestanden
    1.3.6 Das Argument "RotateKubeletServerCertificate" muss auf "true" festgelegt sein (automatisiert). L2 Bestanden
    1.3.7 Das Argument --bind-address muss auf 127.0.0.1 festgelegt sein (automatisiert). L1 Bestanden
    1.4 Planer
    1.4.1 Achten Sie darauf, dass das Argument --profiling auf "false" festgelegt ist (automatisiert). L1 Bestanden
    1.4.2 Das Argument --bind-address muss auf 127.0.0.1 festgelegt sein (automatisiert). L1 Bestanden
    2 cis-1.23
    2 Etcd-Knotenkonfiguration
    2.1 Die Argumente --cert-file und --key-file müssen entsprechend festgelegt sein (automatisiert). L1 Bestanden
    2,2 Achten Sie darauf, dass das Argument --client-cert-auth auf "true" festgelegt ist (automatisiert). L1 Bestanden
    2,3 Achten Sie darauf, dass das Argument --auto-tls nicht auf "true" festgelegt ist (automatisiert). L1 Bestanden
    2.4 Die Argumente --peer-cert-file und --peer-key-file müssen entsprechend festgelegt sein (automatisiert). L1 Bestanden
    2,5 Achten Sie darauf, dass das Argument --peer-client-cert-auth auf "true" festgelegt ist (automatisiert). L1 Bestanden
    2,6 Achten Sie darauf, dass das Argument --peer-auto-tls nicht auf "true" festgelegt ist (automatisiert). L1 Bestanden
    2.7 Für etcd muss eine eindeutige Zertifizierungsstelle verwendet werden (manuell). L2 Bestanden
    3 cis-1.23
    3.1 Authentifizierung und Autorisierung
    3.1.1 Die Clientzertifikatsauthentifizierung sollte nicht für Nutzer verwendet werden (manuell). L2 Bestanden
    3.2 Logging
    3.2.1 Eine Audit-Mindestrichtlinie muss erstellt sein (manuell). L1 Bestanden
    3.2.2 Die Audit-Richtlinie muss wichtige Sicherheitsaspekte abdecken (manuell). L2 Gleichwertige Kontrolle
    4 cis-1.23
    4.1 Konfigurationsdateien der Worker-Knoten
    4.1.1 Die Berechtigungen für die kubelet-Servicedatei müssen auf 644 festgelegt oder restriktiver sein (automatisiert). L1 Bestanden
    4.1.2 Die Eigentümerschaft der kubelet-Servicedatei muss auf root:root festgelegt sein (automatisiert). L1 Bestanden
    4.1.3 Wenn die Proxy-kubeconfig-Datei vorhanden ist, müssen die Berechtigungen auf 644 oder restriktiver festgelegt sein (manuell). L1 Bestanden
    4.1.4 Wenn die Proxy-kubeconfig-Datei vorhanden ist, müssen Sie die Inhaberschaft auf root:root festlegen (manuell). L1 Bestanden
    4.1.5 Die Berechtigungen für die Datei --kubeconfig kubelet.conf müssen auf 644 festgelegt oder restriktiver sein (automatisiert). L1 Bestanden
    4.1.6 Die Eigentümerschaft für die Datei --kubeconfig kubelet.conf muss auf root:root festgelegt sein (automatisiert). L1 Bestanden
    4.1.7 Die Berechtigungen für die Zertifizierungsstellendatei muss auf 644 festgelegt oder restriktiver sein (manuell). L1 Bestanden
    4.1.8 Die Eigentümerschaft für die Client-Zertifizierungsstellendatei muss auf root:root festgelegt sein (manuell). L1 Bestanden
    4.1.9 Die Berechtigungen für die Konfigurationsdatei kubelet --config müssen auf 644 festgelegt oder restriktiver sein (automatisiert). L1 Bestanden
    4.1.10 Die Eigentümerschaft für die Konfigurationsdatei kubelet --config muss auf root:root festgelegt sein (automatisiert). L1 Bestanden
    4.2 Kubelet
    4.2.1 Achten Sie darauf, dass das Argument --anonymous-auth auf "false" festgelegt ist (automatisiert). L1 Bestanden
    4.2.2 Das Argument --authorization-mode darf nicht auf "AlwaysAllow" festgelegt sein (automatisiert). L1 Bestanden
    4.2.3 Das Argument --client-ca-file muss entsprechend festgelegt sein (automatisiert). L1 Bestanden
    4.2.4 Das Argument --read-only-port muss auf 0 festgelegt ist (manuell). L1 Nicht bestanden
    4.2.5 Das Argument --streaming-connection-idle-timeout darf nicht auf 0 gesetzt sein (manuell). L1 Bestanden
    4.2.6 Achten Sie darauf, dass das Argument --protect-kernel-defaults auf "true" festgelegt ist (automatisiert). L1 Nicht bestanden
    4.2.7 Achten Sie darauf, dass das Argument --make-iptables-util-chains auf "true" festgelegt ist (automatisiert). L1 Bestanden
    4.2.8 Das Argument --hostname-override darf nicht festgelegt sein (manuell). L1 Bestanden
    4.2.9 Achten Sie darauf, dass das Argument --event-qps auf 0 oder eine Ebene gesetzt ist, die geeignete Ereigniserfassung ermöglicht (manuell). L2 Warnen
    4.2.10 Die Argumente --tls-cert-file und --tls-private-key-file müssen entsprechend festgelegt sein (manuell). L1 Gleichwertige Kontrolle
    4.2.11 Das Argument --rotate-certificates darf nicht auf „false” gesetzt sein (automatisiert). L1 Bestanden
    4.2.12 Das Argument "RotateletServerCertificate" muss auf "true" festgelegt sein (manuell). L1 Bestanden
    4.2.13 Achten Sie darauf, dass das Kubelet nur starke kryptografische Chiffren verwendet (manuell). L1 Gleichwertige Kontrolle

    Fehler und gleichwertige Kontrollen für einen GKE on Bare Metal-Administratorcluster:

    1,29

    # Empfehlung Level Status Wert Begründung
    1.1.9 Achten Sie darauf, dass die Berechtigungen für die Container Network Interface-Datei auf 600 oder restriktiver festgelegt sind (manuell). L1 Gleichwertige Kontrolle 755 Anthos Clusters on Bare Metal-Container Network Interface-Pfad ist /opt/cni/bin und seine Berechtigung ist für den normalen Clusterbetrieb auf 755 gesetzt.
    1.1.11 Achten Sie darauf, dass die Berechtigungen für das etcd-Datenverzeichnis auf 700 oder restriktiver festgelegt sind (automatisiert). L1 Gleichwertige Kontrolle 755 Das etcd-Datenverzeichnis hat die Standardberechtigungen 755, die zugehörigen Unterverzeichnisse sind jedoch 700.
    1.1.12 Achten Sie darauf, dass die Eigentümerschaft für das etcd-Datenverzeichnisses auf etcd:etcd festgelegt ist (automatisiert). L1 Gleichwertige Kontrolle 2003:2003 Das etcd-Datenverzeichnis /var/lib/etcd gehört 2003:2003 zu dem Ergebnis der rootlosen Steuerungsebene für erhöhte Sicherheit.
    1.1.16 Achten Sie darauf, dass die Eigentümerschaft für die scheduler.conf-Datei auf root:root festgelegt ist (automatisiert). L1 Gleichwertige Kontrolle 2002:2002 Anthos Clusters on Bare Metal ab Version 1.9.0 implementiert eine rootlose Steuerungsebene für erhöhte Sicherheit.
    1.1.18 Achten Sie darauf, dass die Eigentümerschaft für die controller-manager.conf-Datei auf root:root festgelegt ist (automatisiert). L1 Gleichwertige Kontrolle 2001:2001 Anthos Clusters on Bare Metal ab Version 1.9.0 implementiert eine rootlose Steuerungsebene für erhöhte Sicherheit.
    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). L1 Gleichwertige Kontrolle variable:variable Anthos Clusters on Bare Metal ab Version 1.9.0 implementiert eine rootlose Steuerungsebene für erhöhte Sicherheit.
    1.1.20 Achten Sie darauf, dass die Berechtigungen für die Kubernetes-PKI-Zertifikatsdatei auf 600 oder restriktiver festgelegt sind (manuell). L1 Gleichwertige Kontrolle 644 Anthos Clusters on Bare Metal ab Version 1.9.0 implementiert eine rootlose Steuerungsebene für erhöhte Sicherheit.
    1.1.21 Achten Sie darauf, dass die Berechtigungen für die Kubernetes-PKI-Schlüsseldatei auf 600 festgelegt sind (manuell). L1 Gleichwertige Kontrolle 600~640 Anthos Clusters on Bare Metal ab Version 1.9.0 implementiert eine rootlose Steuerungsebene für erhöhte Sicherheit.
    1.2.1 Achten Sie darauf, dass das Argument --anonymous-auth auf "false" festgelegt ist (manuell). L1 Warnen nicht festgelegt Einige Anthos-Cluster on Bare-Metal-Vorgänge wie HA erfordern die Aktivierung der anonymen Authentifizierung.
    1.2.3 Der Parameter --DenyServiceExternalIPs muss festgelegt sein (manuell). L1 Gleichwertige Kontrolle nicht festgelegt Diese Option ist in Kubernetes v1.25 und höher standardmäßig aktiviert.
    1.2.9 Das Zugangskontroll-Plug-in "EventRateLimit" muss festgelegt sein (manuell). L1 Warnen nicht festgelegt Wird in zukünftigen Versionen behoben.
    1.2.11 Das Zugangskontroll-Plug-in "AlwaysPullImages" muss festgelegt sein (manuell). L1 Warnen nicht festgelegt 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 on Bare-Metal 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). L1 Warnen nicht festgelegt Anthos-Cluster on Bare-Metal aktiviert keine Pod-Sicherheitsrichtlinie. Pod Security Admission ist in Kubernetes 1.23-Clustern standardmäßig aktiviert, siehe https://kubernetes.io/docs/concepts/security/pod-security-admission/.
    1.2.13 Das Zugangskontroll-Plug-in "ServiceAccount" muss festgelegt sein (automatisiert). L1 Warnen nicht festgelegt Wird in zukünftigen Versionen behoben.
    1.3.7 Das Argument --bind-address muss auf 127.0.0.1 festgelegt sein (automatisiert). L1 Warnen nicht festgelegt Wird in zukünftigen Versionen behoben.
    1.4.2 Das Argument --bind-address muss auf 127.0.0.1 festgelegt sein (automatisiert). L1 Warnen nicht festgelegt Wird in zukünftigen Versionen behoben.
    3.2.2 Die Audit-Richtlinie muss wichtige Sicherheitsaspekte abdecken (manuell). L2 Gleichwertige Kontrolle nicht festgelegt Anthos Clusters on Bare Metal erfasst Audit-Logs, verwendet diese Flags jedoch nicht für Audits. Weitere Informationen finden Sie unter Logging und Monitoring.
    4.1.1 Die Berechtigungen für die kubelet-Servicedatei müssen auf 600 festgelegt oder restriktiver sein (automatisiert). L1 Nicht bestanden 644 Wird in zukünftigen Versionen behoben.
    4.1.7 Die Berechtigungen für die Zertifizierungsstellendatei muss auf 600 festgelegt oder restriktiver sein (manuell). L1 Nicht bestanden 644 Wird in zukünftigen Versionen behoben.
    4.1.9 Wenn die Kubelet-Konfigurationsdatei config.yaml verwendet wird, müssen die Berechtigungen auf 600 oder restriktiver gesetzt werden (automatisiert). L1 Nicht bestanden 644 Wird in zukünftigen Versionen behoben.
    4.2.6 Achten Sie darauf, dass das Argument --make-iptables-util-chains auf "true" festgelegt ist (automatisiert). L1 Nicht bestanden false Anthos auf Bare-Metal-Clustermaschinen schützen die Kernel-Standardeinstellungen von Kubernetes nicht, da diese für Kundenarbeitslasten möglicherweise geändert werden sollen.
    4.2.9 Die Argumente --tls-cert-file und --tls-private-key-file müssen entsprechend festgelegt sein (manuell). L2 Gleichwertige Kontrolle nicht festgelegt Anthos Clusters on Bare Metal verwalten den Kubelet-Server TLS mit dem Flag --rotate-server-certificates.
    4.2.10 Das Argument --rotate-certificates darf nicht auf „false” gesetzt sein (automatisiert). L1 Gleichwertige Kontrolle nicht festgelegt Anthos-Cluster on Bare-Metal verwalten die Kubelet-Server-TLS mit dem Flag --rotate-server-certificates.
    4.2.13 Für die Pod-PIDs muss ein Limit festgelegt sein (manuell). L1 Warnen nicht festgelegt Anthos-Cluster on Bare-Metal-Kubelet --pod-max-pids sind nicht standardmäßig festgelegt, daher gibt es keine explizite Beschränkung für die Anzahl der PIDs, die ein Pod verwenden kann. Der Pod übernimmt das allgemeine PID-Limit des Hosts, das in der Regel durch den Kernelparameter pid_max des Betriebssystems festgelegt wird. Das Betriebssystem gehört dem Nutzer.

    1,28

    # Empfehlung Level Status Wert Begründung
    1.1.9 Achten Sie darauf, dass die Berechtigungen für die Container Network Interface-Datei auf 600 oder restriktiver festgelegt sind (manuell). L1 Gleichwertige Kontrolle 755 Anthos Clusters on Bare Metal-Container Network Interface-Pfad ist /opt/cni/bin und seine Berechtigung ist für den normalen Clusterbetrieb auf 755 gesetzt.
    1.1.11 Achten Sie darauf, dass die Berechtigungen für das etcd-Datenverzeichnis auf 700 oder restriktiver festgelegt sind (automatisiert). L1 Gleichwertige Kontrolle 755 Das etcd-Datenverzeichnis hat die Standardberechtigungen 755, die zugehörigen Unterverzeichnisse sind jedoch 700.
    1.1.12 Achten Sie darauf, dass die Eigentümerschaft für das etcd-Datenverzeichnisses auf etcd:etcd festgelegt ist (automatisiert). L1 Gleichwertige Kontrolle 2003:2003 Das etcd-Datenverzeichnis /var/lib/etcd gehört 2003:2003 zu dem Ergebnis der rootlosen Steuerungsebene für erhöhte Sicherheit.
    1.1.16 Achten Sie darauf, dass die Eigentümerschaft für die scheduler.conf-Datei auf root:root festgelegt ist (automatisiert). L1 Gleichwertige Kontrolle 2002:2002 Anthos Clusters on Bare Metal ab Version 1.9.0 implementiert eine rootlose Steuerungsebene für erhöhte Sicherheit.
    1.1.18 Achten Sie darauf, dass die Eigentümerschaft für die controller-manager.conf-Datei auf root:root festgelegt ist (automatisiert). L1 Gleichwertige Kontrolle 2001:2001 Anthos Clusters on Bare Metal ab Version 1.9.0 implementiert eine rootlose Steuerungsebene für erhöhte Sicherheit.
    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). L1 Gleichwertige Kontrolle variable:variable Anthos Clusters on Bare Metal ab Version 1.9.0 implementiert eine rootlose Steuerungsebene für erhöhte Sicherheit.
    1.1.20 Achten Sie darauf, dass die Berechtigungen für die Kubernetes-PKI-Zertifikatsdatei auf 600 oder restriktiver festgelegt sind (manuell). L1 Gleichwertige Kontrolle 644 Anthos Clusters on Bare Metal ab Version 1.9.0 implementiert eine rootlose Steuerungsebene für erhöhte Sicherheit.
    1.1.21 Achten Sie darauf, dass die Berechtigungen für die Kubernetes-PKI-Schlüsseldatei auf 600 festgelegt sind (manuell). L1 Gleichwertige Kontrolle 600~640 Anthos Clusters on Bare Metal ab Version 1.9.0 implementiert eine rootlose Steuerungsebene für erhöhte Sicherheit.
    1.2.1 Achten Sie darauf, dass das Argument --anonymous-auth auf "false" festgelegt ist (manuell). L1 Warnen nicht festgelegt Einige Anthos-Cluster on Bare-Metal-Vorgänge wie HA erfordern die Aktivierung der anonymen Authentifizierung.
    1.2.3 Der Parameter --DenyServiceExternalIPs muss festgelegt sein (manuell). L1 Gleichwertige Kontrolle nicht festgelegt Diese Option ist in Kubernetes v1.25 und höher standardmäßig aktiviert.
    1.2.9 Das Zugangskontroll-Plug-in "EventRateLimit" muss festgelegt sein (manuell). L1 Warnen nicht festgelegt Wird in zukünftigen Versionen behoben.
    1.2.11 Das Zugangskontroll-Plug-in "AlwaysPullImages" muss festgelegt sein (manuell). L1 Warnen nicht festgelegt 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 on Bare-Metal 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). L1 Warnen nicht festgelegt Anthos-Cluster on Bare-Metal aktiviert keine Pod-Sicherheitsrichtlinie. Pod Security Admission ist in Kubernetes 1.23-Clustern standardmäßig aktiviert, siehe https://kubernetes.io/docs/concepts/security/pod-security-admission/.
    1.2.13 Das Zugangskontroll-Plug-in "ServiceAccount" muss festgelegt sein (automatisiert). L1 Warnen nicht festgelegt Wird in zukünftigen Versionen behoben.
    1.2.20 Achten Sie darauf, dass das Argument --audit-log-maxbackup auf 10 oder nach Bedarf festgelegt ist (automatisiert). L1 Nicht bestanden 1 Wird in zukünftigen Versionen behoben.
    1.3.7 Das Argument --bind-address muss auf 127.0.0.1 festgelegt sein (automatisiert). L1 Warnen nicht festgelegt Wird in zukünftigen Versionen behoben.
    1.4.2 Das Argument --bind-address muss auf 127.0.0.1 festgelegt sein (automatisiert). L1 Warnen nicht festgelegt Wird in zukünftigen Versionen behoben.
    3.2.2 Die Audit-Richtlinie muss wichtige Sicherheitsaspekte abdecken (manuell). L2 Gleichwertige Kontrolle nicht festgelegt Anthos Clusters on Bare Metal erfasst Audit-Logs, verwendet diese Flags jedoch nicht für Audits. Weitere Informationen finden Sie unter Logging und Monitoring.
    4.1.1 Die Berechtigungen für die kubelet-Servicedatei müssen auf 600 festgelegt oder restriktiver sein (automatisiert). L1 Nicht bestanden 644 Wird in zukünftigen Versionen behoben.
    4.1.7 Die Berechtigungen für die Zertifizierungsstellendatei muss auf 600 festgelegt oder restriktiver sein (manuell). L1 Nicht bestanden 644 Wird in zukünftigen Versionen behoben.
    4.1.9 Wenn die Kubelet-Konfigurationsdatei config.yaml verwendet wird, müssen die Berechtigungen auf 600 oder restriktiver gesetzt werden (manuell). L1 Nicht bestanden 644 Wird in zukünftigen Versionen behoben.
    4.2.6 Achten Sie darauf, dass das Argument --make-iptables-util-chains auf "true" festgelegt ist (automatisiert). L1 Nicht bestanden false Anthos auf Bare-Metal-Clustermaschinen schützen die Kernel-Standardeinstellungen von Kubernetes nicht, da diese für Kundenarbeitslasten möglicherweise geändert werden sollen.
    4.2.9 Die Argumente --tls-cert-file und --tls-private-key-file müssen entsprechend festgelegt sein (manuell). L2 Gleichwertige Kontrolle nicht festgelegt Anthos Clusters on Bare Metal verwalten den Kubelet-Server TLS mit dem Flag --rotate-server-certificates.
    4.2.10 Das Argument --rotate-certificates darf nicht auf „false” gesetzt sein (automatisiert). L1 Gleichwertige Kontrolle nicht festgelegt Anthos-Cluster on Bare-Metal verwalten die Kubelet-Server-TLS mit dem Flag --rotate-server-certificates.
    4.2.13 Für die Pod-PIDs muss ein Limit festgelegt sein (manuell). L1 Warnen nicht festgelegt Anthos-Cluster on Bare-Metal-Kubelet --pod-max-pids sind nicht standardmäßig festgelegt, daher gibt es keine explizite Beschränkung für die Anzahl der PIDs, die ein Pod verwenden kann. Der Pod übernimmt das allgemeine PID-Limit des Hosts, das in der Regel durch den Kernelparameter pid_max des Betriebssystems festgelegt wird. Das Betriebssystem gehört dem Nutzer.

    1.16

    # Empfehlung Level Status Wert Begründung
    1.1.9 Achten Sie darauf, dass die Berechtigungen für die Container Network Interface-Datei auf 644 oder restriktiver festgelegt sind (manuell). L1 Gleichwertige Kontrolle 755 Anthos Clusters on Bare Metal-Container Network Interface-Pfad ist /opt/cni/bin und seine Berechtigung ist für den normalen Clusterbetrieb auf 755 gesetzt.
    1.1.11 Achten Sie darauf, dass die Berechtigungen für das etcd-Datenverzeichnis auf 700 oder restriktiver festgelegt sind (automatisiert). L1 Gleichwertige Kontrolle 755 Das etcd-Datenverzeichnis hat die Standardberechtigungen 755, die zugehörigen Unterverzeichnisse sind jedoch 700.
    1.1.12 Achten Sie darauf, dass die Eigentümerschaft für das etcd-Datenverzeichnisses auf etcd:etcd festgelegt ist (automatisiert). L1 Gleichwertige Kontrolle 2003:2003 Das etcd-Datenverzeichnis /var/lib/etcd gehört 2003:2003 zu dem Ergebnis der rootlosen Steuerungsebene für erhöhte Sicherheit.
    1.1.16 Achten Sie darauf, dass die Eigentümerschaft für die scheduler.conf-Datei auf root:root festgelegt ist (automatisiert). L1 Gleichwertige Kontrolle 2002:2002 Anthos Clusters on Bare Metal ab Version 1.9.0 implementiert eine rootlose Steuerungsebene für erhöhte Sicherheit.
    1.1.18 Achten Sie darauf, dass die Eigentümerschaft für die controller-manager.conf-Datei auf root:root festgelegt ist (automatisiert). L1 Gleichwertige Kontrolle 2001:2001 Anthos Clusters on Bare Metal ab Version 1.9.0 implementiert eine rootlose Steuerungsebene für erhöhte Sicherheit.
    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). L1 Gleichwertige Kontrolle variable:variable Anthos Clusters on Bare Metal ab Version 1.9.0 implementiert eine rootlose Steuerungsebene für erhöhte Sicherheit.
    1.1.21 Achten Sie darauf, dass die Berechtigungen für die Kubernetes-PKI-Schlüsseldatei auf 600 festgelegt sind (manuell). L1 Gleichwertige Kontrolle 600~640 Anthos Clusters on Bare Metal ab Version 1.9.0 implementiert eine rootlose Steuerungsebene für erhöhte Sicherheit.
    1.2.1 Achten Sie darauf, dass das Argument --anonymous-auth auf "false" festgelegt ist (manuell). L1 Warnen nicht festgelegt Einige Anthos-Cluster on Bare-Metal-Vorgänge wie HA erfordern die Aktivierung der anonymen Authentifizierung.
    1.2.10 Das Zugangskontroll-Plug-in "EventRateLimit" muss festgelegt sein (manuell). L1 Warnen
    1.2.12 Das Zugangskontroll-Plug-in "AlwaysPullImages" muss festgelegt sein (manuell). L1 Warnen nicht festgelegt 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 on Bare-Metal aktiviert nicht den AlwaysPullImages-Zugangs-Controller, sodass es im Ermessen der Clusteradministratoren liegt, diesen Kompromiss einzugehen und die Zugangsrichtlinie zu implementieren.
    1.2.13 Das Zugangskontroll-Plug-in "SecurityContextDeny" muss festgelegt sein, wenn "PodSecurityPolicy" nicht verwendet wird (manuell). L1 Warnen nicht festgelegt Anthos-Cluster on Bare-Metal aktiviert keine Pod-Sicherheitsrichtlinie. Pod Security Admission ist in Kubernetes 1.23-Clustern standardmäßig aktiviert, siehe https://kubernetes.io/docs/concepts/security/pod-security-admission/.
    1.2.19 Das Argument --audit-log-path muss festgelegt sein (automatisiert). L1 Nicht bestanden nicht standardmäßig festgelegt; Legen Sie /var/log/apiserver/audit.log nur fest, wenn Cloud-Audit-Logging deaktiviert ist Anthos-Cluster auf Bare-Metal-Clustern senden standardmäßig Kubernetes API-Server-Audit-Logs an Google Cloud.
    1.2.20 Achten Sie darauf, dass das Argument --audit-log-maxage auf 30 oder nach Bedarf festgelegt ist (automatisiert). L1 Nicht bestanden nicht standardmäßig festgelegt; Legen Sie 30 nur fest, wenn Cloud-Audit-Logging deaktiviert ist Anthos-Cluster auf Bare-Metal-Clustern senden standardmäßig Kubernetes API-Server-Audit-Logs an Google Cloud.
    1.2.21 Achten Sie darauf, dass das Argument --audit-log-maxbackup auf 10 oder nach Bedarf festgelegt ist (automatisiert). L1 Nicht bestanden Standardmäßig nicht festgelegt, legen Sie 10 nur fest, wenn Cloud-Audit-Logging deaktiviert ist Anthos-Cluster auf Bare-Metal-Clustern senden standardmäßig Kubernetes API-Server-Audit-Logs an Google Cloud.
    1.2.22 Achten Sie darauf, dass das Argument --audit-log-maxsize auf 100 oder nach Bedarf festgelegt ist (automatisiert). L1 Nicht bestanden Standardmäßig nicht festgelegt, legen Sie 100 nur fest, wenn Cloud-Audit-Logging deaktiviert ist Anthos-Cluster auf Bare-Metal-Clustern senden standardmäßig Kubernetes API-Server-Audit-Logs an Google Cloud.
    3.2.2 Die Audit-Richtlinie muss wichtige Sicherheitsaspekte abdecken (manuell). L2 Gleichwertige Kontrolle nicht festgelegt Anthos Clusters on Bare Metal erfasst Audit-Logs, verwendet diese Flags jedoch nicht für Audits. Weitere Informationen finden Sie unter Logging und Monitoring.
    4.2.4 Das Argument --read-only-port muss auf 0 festgelegt ist (manuell). L1 Nicht bestanden 10255 Anthos Clusters on Bare Metal setzt derzeit das Argument „--read-only-port“ auf 10255, um Messwerte aus kubelet zu erfassen.
    4.2.6 Achten Sie darauf, dass das Argument --protect-kernel-defaults auf "true" festgelegt ist (automatisiert). L1 Nicht bestanden false Anthos auf Bare-Metal-Clustermaschinen schützen die Kernel-Standardeinstellungen von Kubernetes nicht, da diese für Kundenarbeitslasten möglicherweise geändert werden sollen.
    4.2.9 Achten Sie darauf, dass das Argument --event-qps auf 0 oder eine Ebene gesetzt ist, die geeignete Ereigniserfassung ermöglicht (manuell). L2 Warnen nicht festgelegt 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.
    4.2.10 Die Argumente --tls-cert-file und --tls-private-key-file müssen entsprechend festgelegt sein (manuell). L1 Gleichwertige Kontrolle nicht festgelegt Anthos-Cluster on Bare-Metal verwalten die Kubelet-Server-TLS mit dem Flag --rotate-server-certificates.
    4.2.13 Achten Sie darauf, dass das Kubelet nur starke kryptografische Chiffren verwendet (manuell). L1 Gleichwertige Kontrolle In Anthos-Cluster on Bare-Metal-Knoten verwendet Kubelet die standardmäßigen Go-Cipher-Suites. Anthos-Cluster on Bare Metal bietet keine Konfigurationsoptionen für Nutzer, um die Auswahl von Cipher Suite anzupassen. Beachten Sie, dass moderne Clients Cipher Suites aushandeln und keine schwachen Chiffren verwenden, wenn starke Chiffren bei beiden verfügbar sind.

    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. Tools wie das im folgenden Abschnitt aufgeführte Tool können 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, wie im folgenden Beispiel gezeigt:

    kube-bench node --benchmark cis-1.8