CIS Kubernetes Benchmark umsetzen: kube-bench, Befunde und Distributionen

Härtungsstand des Clusters prüfen lassen? Das Cluster-Audit gleicht Ihren Cluster mit dem CIS Kubernetes Benchmark und dem BSI-Baustein APP.4.4 ab und liefert einen Bericht mit priorisierten Maßnahmen. Es ist ein Konfigurations-Review, kein Penetrationstest. Ab 1.490 € netto einmalig, anrechenbar auf den ersten Betriebsmonat (Stand Oktober 2026). Cluster-Audit ansehen

Der CIS Kubernetes Benchmark ist die verbreitete Vorlage für die Härtung von Kubernetes-Clustern, kube-bench das Werkzeug, das ihn prüft. Dieser Ratgeber beantwortet die Fragen nach dem ersten Lauf: Welche Version ist richtig, was bedeuten PASS, FAIL, WARN und INFO, welche Befunde kommen zuerst und was ändert sich bei EKS, AKS, Talos, k3s und RKE2. Stand 29.10.2026. Die neun Härtungsebenen mit kubectl-Prüfungen stehen im Härtungs-Ratgeber und werden hier nicht wiederholt.

Inhaltsverzeichnis

• Welche Version gilt: Benchmark, kube-bench und Kubernetes
• kube-bench einsetzen: Job, Ziele und Ausgabe
• Befunde lesen: PASS, FAIL, WARN und INFO
• Befunde priorisieren: eine Reihenfolge
• Abschnittsüberblick: Zuständigkeit je Betriebsmodell
• Managed-Cluster: EKS und AKS
• Talos, k3s und RKE2
• Abgleich mit BSI APP.4.4
• Unser Vorgehen bei WZ-IT
• Stand und Methodik
• Weiterführende Guides

Welche Version gilt: Benchmark, kube-bench und Kubernetes

Drei Versionsstände greifen ineinander und stimmen nicht überein.

Die Folge: Das Image aquasec/kube-bench:latest entspricht v0.16.0 und enthält cis-2.0 nicht (am 29.10.2026 im Image geprüft). Wer gegen cis-2.0 prüfen will, baut kube-bench aus dem Branch main. Andernfalls setzen Sie --benchmark cis-1.12 und nennen die Version im Bericht. Die Plattform-Tabelle bildet Kubernetes-Releases nicht 1:1 auf Benchmarks ab, und ihre Zeilen für EKS, AKS und RKE2 hinken den Verzeichnissen unter cfg hinterher.

kube-bench einsetzen: Job, Ziele und Ausgabe

kube-bench prüft Prozesse, Konfigurationsdateien und Dateirechte auf dem Node und braucht dafür die Host-PID und lesenden Zugriff auf Host-Pfade (README). Der Lauf erfolgt als Job. Ziele (--targets) sind master, etcd, controlplane, node und policies (Architektur).

Erzwingt die Pod Security Admission im Cluster baseline oder restricted, braucht der Job (Host-PID, hostPath-Volumes) einen Namespace mit der Stufe privileged:

kubectl create namespace kube-bench
kubectl label namespace kube-bench pod-security.kubernetes.io/enforce=privileged
curl -sLO https://raw.githubusercontent.com/aquasecurity/kube-bench/v0.16.0/job.yaml

In der job.yaml vergeben Sie je Lauf einen eigenen metadata.name (hier kube-bench-control-plane) und ändern im Pod-Template nodeSelector und tolerations für die Control Plane (Anleitung) sowie Ziele und Benchmark im command. Angewendet wird mit kubectl apply -n kube-bench -f job.yaml.

    spec:
      hostPID: true
      nodeSelector:
        node-role.kubernetes.io/control-plane: ""
      tolerations:
        - key: node-role.kubernetes.io/control-plane
          operator: Exists
          effect: NoSchedule
      containers:
        - name: kube-bench
          image: docker.io/aquasec/kube-bench:v0.16.0
          command: ["kube-bench", "run", "--targets", "master,etcd,controlplane,policies", "--benchmark", "cis-1.12"]

Für die Worker-Nodes (Name kube-bench-worker) entfallen nodeSelector und tolerations, der Befehl lautet ["kube-bench", "run", "--targets", "node", "--benchmark", "cis-1.12"]. Die Ausgabe holen Sie mit kubectl logs -n kube-bench job/kube-bench-control-plane | grep -E '^\[(FAIL|WARN)\]'. Drei Optionen aus der Flag-Referenz gehören in jeden Lauf:

• --json --outputfile <Datei> schreibt einen maschinenlesbaren Bericht. Er enthält die Summen unter .Totals und je Kontrolle test_number, status und scored.
• --skip "<IDs>" überspringt Kontrollen. Sie erscheinen als INFO und gehören mit Begründung in ein Ausnahmeregister.
• --exit-code 42 liefert bei mindestens einem FAIL diesen Exit-Code und eignet sich als Gate in der Pipeline. Ein WARN löst ihn nicht aus.

Aus dem JSON-Bericht ergibt jq -r '.Controls[].tests[].results[] | select(.status=="FAIL") | "\(.test_number) \(.test_desc)"' die FAIL-Liste.

Befunde lesen: PASS, FAIL, WARN und INFO

Die Referenz definiert vier Zustände. PASS und FAIL bewerten eine ausgeführte Kontrolle. WARN heißt: weitere Aufmerksamkeit nötig, etwa weil die Kontrolle manuell zu prüfen ist. INFO ist eine Information ohne Handlungsbedarf, so auch übersprungene Kontrollen. Zwei Regeln erklären die meisten Überraschungen:

• Bewertete Kontrollen (scored: true) enden bei Abweichung oder wenn die Prüfung nicht ausführbar ist mit FAIL. Nicht bewertete Kontrollen (scored: false) enden dann mit WARN, bei Erfolg mit PASS. Kontrollen vom Typ manual erzeugen immer WARN.
• Ein WARN zählt nicht als FAIL: Exit-Code und FAIL-Summe bilden WARN nicht ab.

Das hat Folgen für sicherheitskritische Kontrollen. In cis-2.0 ist 1.2.1 (--anonymous-auth am API-Server) im Benchmark als manuell gekennzeichnet und in kube-bench nicht bewertet. Im Test mit simuliertem API-Server-Prozess (kube-bench v0.16.0, Konfiguration cis-1.12) lieferte 1.2.1 bei --anonymous-auth=false PASS und bei =true WARN, während die bewertete Kontrolle 1.2.2 (--token-auth-file) bei gesetztem Parameter FAIL meldete. Ein offener anonymer Zugriff löst deshalb weder FAIL noch den Exit-Code aus. Auch 4.2.4 (Read-only-Port des kubelet) ist nicht bewertet (scored: false). Werten Sie diese WARN-Meldungen aus, statt sie zu übergehen.

In einem leeren Container ergibt cis-1.12 mit allen fünf Zielen 1 PASS, 64 FAIL und 66 WARN. Die 66 WARN sind die nicht bewerteten Kontrollen, davon sind 28 vom Typ manual (immer WARN, sie sinken nur durch Bewertung). Die übrigen 38 sinken durch Härtung zu PASS. Nach der Definition in der Microsoft-Dokumentation zum Benchmark beeinflussen nur automatisierte Empfehlungen den Benchmark-Score. Ein Wert wie "85 Prozent" ist deshalb nur vergleichbar, wenn Version, Ziele, Skip-Liste und der Umgang mit WARN angegeben sind.

Befunde priorisieren: eine Reihenfolge

Die Reihenfolge ist unsere Einordnung nach Wirkung, kein Teil des Benchmarks. Die Nummern folgen cis-2.0.

Zu Stufe 5: Microsoft führt beide Kontrollen für AKS als "Fail" mit der Begründung "Operational impact". Der Benchmark trennt Level 1 (grundlegend, wenig Einschränkung) von Level 2 (strenger, kann Funktionen einschränken).

Ein Ausnahmeregister führt je Eintrag Kontroll-ID, Befund, Begründung, Ersatzmaßnahme, verantwortliche Person und Prüfdatum. Falschmeldungen durch die Architektur der Distribution (siehe unten) gehören hinein.

Abschnittsüberblick: Zuständigkeit je Betriebsmodell

Die Tabelle fasst die Konfiguration cis-2.0 (kube-bench, Branch main) zusammen, gezählt nach den Kennzeichen "Automated" und "Manual" im Titel der Kontrollen.

Die Spalte "EKS und AKS" folgt der Aussage in der kube-bench-Dokumentation, dass sich Control-Plane-Nodes verwalteter Cluster nicht prüfen lassen (Anleitung), und dem Shared-Responsibility-Modell von AWS, nach dem AWS die Control-Plane-Nodes und die etcd-Datenbank verantwortet. "Anbieter" heißt: Der Betreiber kann es nicht prüfen und belegt es mit der Anbieter-Dokumentation.

Managed-Cluster: EKS und AKS

Bei EKS und AKS prüft kube-bench den Teil des Betreibers. Dafür gibt es eigene Konfigurationen: eks-1.8.0 (50 Kontrollen, 27 automatisiert) und aks-1.8 (51 Kontrollen, 16 automatisiert) mit den Zielen node, policies, controlplane und managedservices. Die managedservices-Kontrollen zu Image-Registry, IAM, Schlüsselverwaltung und Netzwerk sind in beiden durchgehend manuell (12 bei EKS, 13 bei AKS). Die CIS-Seite nennt für beide die Version 2.0.0, kube-bench main reicht bis eks-1.8.0 und aks-1.8. Die Beispiel-Jobs sind älter: job-eks.yaml setzt eks-1.5.0, job-aks.yaml setzt aks-1.7. Prüfen Sie die Benchmark-Zeile vor dem Lauf.

Für die Control Plane liefert der Anbieter die Belege:

• AKS: Microsoft veröffentlicht den Status je Empfehlung des Kubernetes-Benchmarks v1.12.0 für AKS 1.32 bis 1.34 (Dokumentation). Die Tabelle enthält 125 Empfehlungen: 54 Pass, 37 "Depends on Environment", 23 "N/A", 7 Fail und 4 "Equivalent Control". Alle 21 Empfehlungen aus 1.1 sind N/A, weil AKS die Control-Plane-Pods per Helm-Chart ausrollt und keine Dateien auf einer Node-VM nutzt. Bei 1.2.2 (--token-auth-file) steht Fail mit dem Hinweis, dass der Parameter von AKS gesetzt und rotiert wird und nicht konfigurierbar ist. Die 33 Empfehlungen aus 5.1, 5.2, 5.3.2, 5.4 und 5.6 (RBAC, Pod Security, NetworkPolicies, Secrets, allgemeine Richtlinien) stehen auf "Depends on Environment", sie liegen beim Betreiber.
• EKS: Control-Plane-Logs, darunter das Audit-Log, sind standardmäßig aus und werden pro Log-Typ aktiviert (Dokumentation). aws eks update-cluster-config --name <cluster> --logging '{"clusterLogging":[{"types":["api","audit","authenticator","controllerManager","scheduler"],"enabled":true}]}' schaltet alle fünf ein. Ab Kubernetes 1.28 verschlüsselt EKS alle Kubernetes-API-Daten standardmäßig per Envelope Encryption (Dokumentation). Das ist der Anbieterbeleg zur Secrets-Verschlüsselung (Kontrollen 1.2.27 und 1.2.28).

Der Anbieterstatus gehört mit Stichtag in die Nachweise, er ändert sich mit der Kubernetes-Version.

Talos, k3s und RKE2

Hier weichen Pfade und Prozesse von kubeadm ab. Die Tabelle nennt je Distribution die Konfiguration in kube-bench main, die Zahl der Kontrollen (davon automatisiert) und die dokumentierte Abweichung.

Lizenzen laut LICENSE-Datei: kube-bench, RKE2 (LICENSE) und k3s (LICENSE) stehen unter Apache-2.0, Talos Linux unter MPL-2.0 (LICENSE).

Talos. Talos hat keine SSH-Schnittstelle, keine Shell und ein unveränderliches Root-Dateisystem, die Verwaltung läuft über die Talos-API. Kontrollen, die Manifest-Dateien oder kubeadm-Pfade erwarten, finden dort nichts. Die Talos-Dokumentation bewertet diese Meldungen als Falschmeldungen und nennt Skip-Listen für Control Plane und Worker, mit denen ein Lauf ohne FAIL endet. Die Listen sind mit Kubernetes 1.35 und cis-1.10 geprüft, bei einer anderen Benchmark-Version prüfen Sie die Nummern neu. Workload-Kontrollen bleiben beim Betreiber (Pod-Security-Ausnahmen, NetworkPolicies, RBAC).

RKE2 und k3s. Die Self-Assessments gelten für den gehärteten Zustand nach Anleitung und begründen "Not Applicable" je Kontrolle. In kube-bench main fehlt für beide eine Konfiguration zu CIS 2.0: Bei k3s ab v1.34 und RKE2 ab v1.35 dienen deren Audit-Befehle als Grundlage.

Abgleich mit BSI APP.4.4

APP.4.4 Kubernetes (Edition 2023) sieht in A13, einer Anforderung bei erhöhtem Schutzbedarf (SOLLTE), ein automatisches Audit der Einstellungen von Nodes, Kubernetes und Pods gegen eine definierte Liste erlaubter Einstellungen und gegen standardisierte Benchmarks. Der Baustein nennt den CIS Benchmark unter den weiterführenden Informationen. kube-bench kann dafür den datierten Bericht liefern. Ein Lauf deckt aber nur einen Teil des Bausteins ab.

Die Ebenen mit Bestehenskriterien je Anforderung stehen im Härtungs-Ratgeber, die Nachweise zu NIS2 im Ratgeber Kubernetes NIS2 und ISO 27001: Nachweise im Cluster.

Unser Vorgehen bei WZ-IT

Das Cluster-Audit gleicht den Cluster mit dem CIS Kubernetes Benchmark und APP.4.4 ab. Ergebnis ist ein Bericht mit Befunden nach Priorität und empfohlenen Maßnahmen. Das Audit ist ein Konfigurations-Review ohne Änderungen am Cluster, kein Penetrationstest. Es kostet ab 1.490 € netto einmalig und wird auf den ersten Betriebsmonat angerechnet.

Den laufenden Betrieb übernimmt Managed Kubernetes ab 590 € netto je Cluster und Monat inklusive drei Worker-Nodes, mit Monitoring, Upgrades, Backups mit Restore-Test und Härtung. Monitoring erfolgt 24/7, die Reaktion auf P1-Incidents erfolgt entsprechend Service Level. Maßnahmen aus einem Bericht setzen wir alternativ über den Kubernetes-Support um, 120 € netto je Stunde ohne Vertrag. Preise netto, Stand Oktober 2026.

Stand und Methodik

• Stand: 29.10.2026. Alle verlinkten Quellen wurden an diesem Tag abgerufen.
• kube-bench: Release v0.16.0 und Branch main (Commit e278a591 vom 05.10.2026). Die Kontrollzahlen stammen aus den YAML-Dateien unter cfg/. Die Flags --benchmark, --targets, --skip, --exit-code, --json, --outputfile und der jq-Pfad liefen lokal im Container aquasec/kube-bench:v0.16.0. Der Test zu 1.2.1 und 1.2.2 (Konfiguration cis-1.12) nutzte einen simulierten API-Server-Prozess, der Ausgaben von ps nachbildet, die Job-Änderungen sind nur auf gültiges YAML geprüft. Ein Lauf in einem Cluster fand nicht statt.
• AKS-Zahlen: Statustabelle von Microsoft zu Benchmark v1.12.0 und AKS 1.32 bis 1.34, selbst ausgezählt (125 Zeilen). Sie gilt nicht für die Nummerierung von cis-2.0. Die Seite trägt den Änderungsvermerk 2025-08-05.
• RKE2, k3s, Talos: Zählung der "Result"-Zeilen in den Self-Assessment-Guides zu CIS 2.0. Die Talos-Aussagen stammen aus der Dokumentation (Version 1.14) und sind nicht selbst geprüft.
• Einordnung: Die Prioritätsstufen sind unsere Einschätzung. Das Benchmark-PDF ist laut CIS für nicht-kommerzielle Nutzung frei verfügbar und erfordert ein Konto; die Version 2.1.0 wurde nicht ausgewertet.

Weiterführende Guides

• Kubernetes-Härtung: Checkliste nach CIS, BSI und NIS2 - neun Ebenen mit Prüfkriterien und kubectl-Befehlen
• Kubernetes Go-Live Checkliste: 25 Prüfpunkte - 25 Prüfpunkte vor dem Produktivbetrieb
• k3s vs. RKE2 vs. Talos - Distributionen im Vergleich
• Was ist Talos Linux? Betriebssystem für Kubernetes - das Betriebssystem im Überblick
• Kubernetes-Cluster übernehmen: Audit-Checkliste - der Betriebsteil bei einer Übernahme

Cluster-Prüfung oder Betriebsübergabe? Das Audit liefert den Bericht, Managed Kubernetes setzt die Maßnahmen um. Cluster-Audit · Managed Kubernetes