CIS-Benchmark-Tests für klare Schwachstellenanalysen im Cluster Kube-bench überprüft Kubernetes-Sicherheit

Mithilfe von „Kube-bench“ lassen sich Kubernetes-Cluster anhand des CIS Benchmarks überprüfen und sicherheitsrelevante Fehlkonfigurationen aufdecken. Das Tool unterstützt verschiedene Plattformen wie „EKS“, „GKE“, „AKS“, „Openshift“ und „Rancher“ Das Tool läuft direkt auf Nodes als auch in Containern und Pods.

Mit der Software Kube-bench prüfen Admins Kubernetes-Deployments anhand des CIS Kubernetes Benchmarks und erkennen Konfigurationsfehler, die die Sicherheit gefährden können. Die Tests sind in YAML-Dateien hinterlegt und lassen sich flexibel erweitern oder anpassen, wenn sich Benchmark-Spezifikationen ändern.

Funktionsweise und Prinzip

Das Werkzeug führt die in den CIS-Benchmarks definierten Prüfungen automatisiert aus. Es erkennt die laufende Kubernetes-Version und ordnet sie der passenden Benchmark-Version zu, beispielsweise Kubernetes 1.15 mit cis-1.15.

Zusätzlich prüft Kube-bench die Rolle des Knotens und führt nur relevante Tests aus, etwa Master-Node-Prüfungen, wenn der API-Server läuft. Da in Managed-Umgebungen wie GKE, EKS, AKS oder „ACK“ kein Zugriff auf Master-Nodes möglich ist, beschränkt sich die Analyse dort auf Worker-Knoten.

Das Tool lässt sich direkt von der Kommandozeile ausführen. Root- oder Sudo-Rechte sind erforderlich, da Konfigurationsdateien eingesehen werden müssen. Eine Alternative ist der Betrieb in einem Container. Dabei werden die Host-Verzeichnisse „/etc“ und „/var“ eingebunden, um Konfigurationen und Dateiberechtigungen zu prüfen.

Über den Befehl

lässt sich Kube-bench starten. Für die automatische Erkennung der Kubernetes-Version sind „kubelet“ oder „kubectl“ im Pfad erforderlich, zudem muss „kubeconfig“ bereitgestellt werden. Eigene Konfigurationen können über Mounts in /opt/kube-bench/cfg/ eingebunden werden.

Nutzung im Kubernetes-Cluster

Kube-bench kann als Pod im Cluster betrieben werden. Dafür ist Zugriff auf den PID-Namespace und bestimmte Host-Verzeichnisse erforderlich. Mit dem bereitgestellten job.yaml-Manifest lässt sich ein Kubernetes-Job erzeugen, der die Prüfungen ausführt und die Ergebnisse in den Pod-Logs bereitstellt.

Soll der Master-Node getestet werden, muss der Pod gezielt auf diesem Node gestartet werden. Da sich die Labels für Master-Knoten seit Kubernetes 1.11 geändert haben, ist eine Anpassung des nodeSelector und der Tolerations bei älteren Versionen notwendig.

Besondere Anforderungen in Cloud-Umgebungen

Auf AKS-Cluster lassen sich Worker-Nodes prüfen, jedoch nicht die Master-Nodes. Dort ist die Nutzung von „Docker“-basierten Tests möglich, beispielsweise mit „kubectl-enter“, um in die Node-Shell zu gelangen.

In EKS-Umgebungen wird ein spezielles job-eks.yaml genutzt. Der Container wird zuvor in ein eigenes Amazon ECR Repository geladen und von dort als Pod gestartet. Die Ergebnisse können über kubectl logs gesichert werden. Neben den Standard-Benchmarks steht in EKS auch die Ausführung von DISA STIG-Tests über job-eks-stig.yaml bereit.

In GKE-Umgebungen unterstützt kube-bench mehrere Benchmarks wie gke-1.0, gke-1.2.0 und gke-1.6.0. Die Ausführung erfolgt über job-gke.yaml. Für ACK-Cluster von Alibaba Cloud existiert job-ack.yaml mit Benchmark ack-1.0. „VMware TKGI“-Umgebungen nutzen job-tkgi.yaml und das Benchmark tkgi-1.2.53.

Einsatz in Openshift und Rancher

Für Openshift stehen Testdateien bereit, die den „Red Hat Hardening Guide“ abbilden. Ab „OCP 3.10“ gilt rh-0.7, ab OCP 4.1 rh-1.0. Kube-bench erkennt Openshift-Umgebungen automatisch. Da privilegierte Rechte notwendig sind, muss der ServiceAccount mit der SecurityContextConstraint „privileged“ ausgestattet werden.

Rancher-Cluster werden ebenfalls abgedeckt. Für „RKE“ gibt es den Benchmark rke-cis-1.7, für RKE2 rke2-cis-1.7 und für K3s k3s-cis-1.7. In allen Fällen wird der jeweilige Benchmark explizit angegeben, damit die Prüfungen korrekt zugeordnet werden.

Integration in Trivy

Kube-bench ist auch Teil des Sicherheitsscanners „Trivy“. Sowohl die CLI-Version als auch der „Trivy Operator“ unterstützen CIS-Benchmark-Scans zusätzlich zu anderen Sicherheitsprüfungen. Damit können CIS-Checks in bestehende Sicherheits-Workflows integriert werden, ohne Kube-bench separat auszuführen.

Ergebnisse und Auswertung

Die Resultate der Tests werden strukturiert ausgegeben und enthalten Informationen zu Konfigurationsbereichen wie API-Server, Master-Node oder „etcd“. Administratoren:innen können nachvollziehen, welche Anforderungen erfüllt sind und wo Anpassungen erforderlich sind. Die Ergebnisse lassen sich zur Dokumentation exportieren und in Sicherheitsberichte einbinden.

(ID:50569979)