Was macht Benchmarking von Kubernetes mit kube-bench?
Übersicht
kube-bench (von Aqua Security) ist ein Open-Source-Tool, das überprüft, ob ein Kubernetes-Cluster sicher bereitgestellt wurde, indem es die im CIS Kubernetes Benchmark dokumentierten Prüfungen durchführt. Es inspiziert die Control-Plane-Komponenten (API-Server, Controller-Manager, Scheduler, etcd), die kubelet- und Worker-Node-Konfiguration sowie clusterweite Richtlinieneinstellungen und meldet jede Prüfung als PASS, FAIL, WARN oder INFO mit einer Abhilfeempfehlung, die direkt aus dem CIS-Leitfaden stammt. Die Tests sind konfigurationsgesteuerte YAML-Dateien, sodass kube-bench neue Kubernetes-Versionen und Benchmark-Revisionen verfolgt und verwaltete Distributionen (EKS, GKE, AKS, ACK, OpenShift, RKE, k3s) unterstützt.
Die Härtung eines Clusters gemäß dem CIS Benchmark reduziert direkt die Angriffsfläche für T1610 (Deploy Container), bei dem ein Angreifer einen Container bereitstellt, um Code auszuführen oder Verteidigungsmaßnahmen zu umgehen – beispielsweise durch den Missbrauch privilegierter Container, Host-Namespaces, anonymem API-Zugriff oder unsicherer kubelet-Einstellungen, die ein ungehärteter Cluster offenlegt.
kube-bench kann als eigenständiges Binary auf einem Knoten, in einem Container oder – am häufigsten – als Kubernetes-Job ausgeführt werden, dessen Pod das Host-Dateisystem eingehängt hat, um die relevanten Konfigurationsdateien lesen zu können. Die Ausgabe erfolgt als menschenlesbarer Text, JSON, JUnit oder AWS Security Finding Format (ASFF) und kann zur Trendverfolgung an eine PostgreSQL-Datenbank gesendet werden.
Verwendungszweck
- Bei der Erstellung einer Sicherheitsbaseline für einen neuen Kubernetes-Cluster gemäß dem CIS Kubernetes Benchmark.
- Bei der Durchführung regelmäßiger Compliance-Audits der Control-Plane- und Node-Härtung.
- Bei der Validierung der Abhilfe nach Anwendung von Härtungsänderungen (erneute Ausführung, um zu bestätigen, dass die Prüfungen jetzt PASS lauten).
- Bei der Integration des Cluster-Compliance-Scans in CI/CD oder eine kontinuierliche Überwachungspipeline.
- Bei der Vorbereitung von Nachweisen für SOC 2, PCI DSS oder interne Härtungs-Compliance.
Voraussetzungen
- Zugriff auf den Cluster: entweder SSH-Zugriff auf einen Control-Plane-/Worker-Knoten (Binary-Modus) oder
kubectlmit Berechtigung zum Erstellen von Jobs (In-Cluster-Modus). - Kenntnis der Kubernetes-Version des Clusters (kube-bench erkennt automatisch oder kann mit
--version/--benchmarkangegeben werden). - Installation von kube-bench (offizielle Methoden von Aqua Security):
# Binary-Release (Linux)
KB_VERSION=0.10.7
curl -L -o kube-bench.tgz \
"https://github.com/aquasecurity/kube-bench/releases/download/v${KB_VERSION}/kube-bench_${KB_VERSION}_linux_amd64.tar.gz"
tar -xzf kube-bench.tgz
sudo mv kube-bench /usr/local/bin/
sudo cp -R cfg /etc/kube-bench/cfg
# Über Go installieren
install github.com/aquasecurity/kube-bench@latest
# Als einmaligen Container direkt auf einem Knoten ausführen (Host-Konfiguration einhängen)
docker run --rm --pid=host \
-v /etc:/etc:ro -v /var:/var:ro \
-t docker.io/aquasec/kube-bench:latest run --targets node
# Überprüfen
kube-bench version
Ziele
- Ausführung von kube-bench gegen den entsprechenden Benchmark für die Kubernetes-Version des Clusters.
- Scannen der Control-Plane (Master), Node, etcd, Control-Plane-Richtlinien und Managed-Service-Ziele.
- Erzeugung von maschinenlesbarer JSON-/JUnit-Ausgabe für Pipelines und Dashboards.
- Triage von FAIL- und WARN-Ergebnissen und Anwendung der CIS-Abhilfeanleitung.
- Erneute Ausführung, um zu validieren, dass Abhilfemaßnahmen jetzt PASS lauten.
MITRE ATT&CK Mapping
| Technik-ID | Name | Taktik | Relevanz |
|---|---|---|---|
| T1610 | Container bereitstellen | Ausführung / Verteidigungsumgehung | Die durch kube-bench erzwungene CIS-Benchmark-Härtung schränkt privilegierte/Host-Namespace-Bereitstellungen, anonymen API-Zugriff und unsichere kubelet-Einstellungen ein, die Angreifer beim Bereitstellen bösartiger Container missbrauchen. |
Arbeitsablauf
1. Standard-Scan ausführen (automatische Erkennung)
Alle zutreffenden Ziele ausführen und kube-bench die Kubernetes-Version und den Benchmark erkennen lassen:
sudo kube-bench
2. Als Kubernetes-Job ausführen (In-Cluster)
Das bereitgestellte Job-Manifest aus dem kube-bench-Repository anwenden und die Ergebnisse aus den Pod-Protokollen lesen:
# Allgemeiner Job
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml
# Warten, dann Ergebnisse abrufen
kubectl get pods -l app=kube-bench
kubectl logs -l app=kube-bench
# Plattformspezifische Jobs sind verfügbar, z. B. EKS:
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job-eks.yaml
3. Bestimmte Komponenten gezielt scannen
Mit run --targets den Scan auf bestimmte Komponentengruppen beschränken:
# Control-Plane (API-Server, Scheduler, Controller-Manager)
sudo kube-bench run --targets master
# Worker-Node (kubelet, Proxy)
sudo kube-bench run --targets node
# etcd-Datenspeicher
sudo kube-bench run --targets etcd
# Clusterweite Richtlinien (RBAC, Pod-Sicherheit, Netzwerkrichtlinien)
sudo kube-bench run --targets policies
# Mehrere Ziele kombinieren
sudo kube-bench run --targets master,node,etcd,policies
4. Einen bestimmten Benchmark oder eine bestimmte Kubernetes-Version festlegen
Wenn die automatische Erkennung falsch ist oder Sie gegen eine bestimmte Revision auditieren müssen, legen Sie den Benchmark explizit fest:
# Auf eine bestimmte CIS-Benchmark-Revision festlegen
sudo kube-bench run --benchmark cis-1.8
# Oder nach Kubernetes-Version zuordnen
sudo kube-bench --version 1.27
# Managed-/Distributionsspezifische Benchmarks
sudo kube-bench run --benchmark eks-1.5.0
sudo kube-bench run --benchmark gke-1.6.0
sudo kube-bench run --benchmark rke2-cis-1.7
5. Einzelne Prüfungen ausführen oder überspringen
Während Abhilfezyklen auf bestimmte Prüf-IDs konzentrieren oder diese ausschließen:
# Nur bestimmte Prüfungen ausführen
sudo kube-bench run --targets master --check 1.2.1,1.2.2
# Laute/akzeptierte Prüfungen überspringen
sudo kube-bench run --targets node --skip 4.2.6
6. Maschinenlesbare Ausgabe erzeugen
JSON oder JUnit zur Aufnahme in Pipelines, SIEM oder Dashboards ausgeben und in eine Datei schreiben:
# JSON in eine Datei
sudo kube-bench run --targets master,node --json --outputfile kube-bench-report.json
# JUnit (für CI-Testberichte)
sudo kube-bench --junit --outputfile kube-bench-junit.xml
# AWS Security Finding Format (für Security Hub)
sudo kube-bench run --targets node --asff
7. Triage und Abhilfe von FAIL-/WARN-Ergebnissen
Jede fehlgeschlagene Prüfung gibt eine Abhilfeempfehlung aus. Wenden Sie die CIS-empfohlenen Korrekturen auf dem Knoten/Manifest an, z. B. API-Server-Flags im statischen Pod-Manifest verschärfen:
# Beispiel-Abhilfe für einen häufigen Control-Plane-Fehler:
# CIS 1.2.x – sicherstellen, dass anonymous-auth auf dem API-Server deaktiviert ist.
# Das statische Pod-Manifest bearbeiten und das Flag setzen:
sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml
# - --anonymous-auth=false
# Der kubelet startet den statischen Pod automatisch neu.
# Beispiel-Knotenabhilfe – kubelet-Konfigurationsdateiberechtigungen (CIS 4.1.x):
sudo chmod 600 /etc/kubernetes/kubelet/kubelet-config.json
sudo chown root:root /etc/kubernetes/kubelet/kubelet-config.json
8. Nach der Abhilfe erneut validieren
Führen Sie das relevante Ziel erneut aus und bestätigen Sie, dass die zuvor fehlgeschlagenen Prüfungen jetzt PASS lauten, und verfolgen Sie die Punktzahl im Laufe der Zeit:
sudo kube-bench run --targets master --check 1.2.1 --json --outputfile recheck.json
# Optional: Ergebnisse zur Trendverfolgung in PostgreSQL persistieren
sudo kube-bench run --targets master,node --pgsql
Werkzeuge und Ressourcen
| Werkzeug / Ressource | Zweck | Link |
|---|---|---|
| kube-bench | CIS Kubernetes Benchmark-Prüfer | https://github.com/aquasecurity/kube-bench |
| kube-bench-Dokumentation | Ausführung / Plattformen / Flags | https://aquasecurity.github.io/kube-bench/ |
| CIS Kubernetes Benchmark | Quell-Härtungsstandard | https://www.cisecurity.org/benchmark/kubernetes |
| Trivy Operator | Kontinuierliche In-Cluster-Compliance + Schwachstellenscan | https://github.com/aquasecurity/trivy-operator |
| kube-hunter | Ergänzendes Penetrationstestwerkzeug | https://github.com/aquasecurity/kube-hunter |
Validierungskriterien
- kube-bench installiert (
kube-bench version) oder als Job ausgeführt. - Scan gegen den richtigen Benchmark für die Kubernetes-Version des Clusters ausgeführt.
- Ziele master, node, etcd und policies jeweils gescannt.
- JSON-/JUnit-Ausgabe für die Pipeline-/Dashboard-Aufnahme erstellt.
- FAIL- und WARN-Ergebnisse triagiert und priorisiert.
- CIS-Abhilfe auf Control-Plane-Manifeste und Knotenkonfigurationen angewendet.
- Erneute Ausführung bestätigt, dass zuvor fehlgeschlagene Prüfungen jetzt PASS lauten.
- Ergebnisse im Laufe der Zeit verfolgt (Dateiarchiv oder PostgreSQL).