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
Kubernetes-Härtung heißt: Der Konfigurationszustand des Clusters ist festgelegt, prüfbar und belegt. Diese Checkliste ordnet die Prüfpunkte nach neun Ebenen. Je Ebene stehen ein Bestehenskriterium, eine Prüfung mit kubectl oder kube-bench und der Bezug zu CIS Kubernetes Benchmark, BSI-Baustein APP.4.4 und den NIS2-Mindestbereichen. Stand Oktober 2026. Sie prüft Konfiguration und ist weder Penetrationstest noch Rechtsberatung.
Inhaltsverzeichnis
- Welche Vorgaben gelten: CIS, BSI und NIS2
- Betriebskonzept: was APP.4.4 vor der Inbetriebnahme verlangt
- Die Checkliste: neun Ebenen mit Prüfkriterien
- Was kube-bench abdeckt und was nicht
- NIS2: welche technischen Nachweise der Cluster liefert
- Unser Vorgehen bei WZ-IT
- Stand und Methodik
- Weiterführende Guides
Welche Vorgaben gelten: CIS, BSI und NIS2
CIS Kubernetes Benchmark. Konfigurationsempfehlungen für Control Plane, etcd, Worker Nodes und Richtlinien (CIS). Die CIS-Seite nennt für Kubernetes die Version 2.1.0. kube-bench ordnet seine Konfiguration cis-2.0 den Kubernetes-Versionen 1.34 und 1.35 zu (Tabelle), für 1.36 und 1.37 fehlt eine Zuordnung. Die Konfiguration cis-2.0 liegt seit dem 18.08.2026 im Branch main, das Release v0.16.0 (05.08.2026) und sein Image enthalten sie nicht (neueste Konfiguration dort: cis-1.12). Für cis-2.0 muss kube-bench aus main gebaut werden, mit dem Release setzen Sie --benchmark cis-1.12. Wählen Sie die Version deshalb selbst und ordnen Sie Abweichungen manuell ein. Die Kontrollnummern folgen cis-2.0.
BSI IT-Grundschutz. Der Baustein APP.4.4 Kubernetes (Edition 2023) enthält 21 Anforderungen und ist immer zusammen mit SYS.1.6 Containerisierung anzuwenden. Der Baustein regelt zusätzlich Planung vor der Inbetriebnahme und Datensicherung im Cluster. Dafür enthält die kube-bench-Konfiguration cis-2.0 keine Kontrolle.
NIS2. § 30 Absatz 2 des BSI-Gesetzes setzt Artikel 21 der NIS-2-Richtlinie (EU) 2022/2555 um und nennt zehn Mindestbereiche. Verlangt sind geeignete, verhältnismäßige und wirksame Maßnahmen mit Dokumentation (§ 30 Absatz 1), aber ohne Werkzeugvorgabe. Ob eine Einrichtung unter NIS2 fällt, klärt sie selbst.
Betriebskonzept: was APP.4.4 vor der Inbetriebnahme verlangt
Die fünf Basis-Anforderungen (MUSS) bilden den Rahmen eines Betriebskonzepts:
| Nr. | Anforderung | Prüffrage |
|---|---|---|
| A1 | Planung der Separierung der Anwendungen | Welche Namespaces, Cluster und Netze trennen Test und Produktion? |
| A2 | Planung der Automatisierung mit CI/CD | Sind bei CI/CD-Einsatz Lebenszyklus, Rollen und Rechte sowie die Absicherung der Secrets geplant? |
| A3 | Identitäts- und Berechtigungsmanagement | Wird jede Aktion authentifiziert und autorisiert, ohne anonyme Administration? |
| A4 | Separierung von Pods | Isoliert der Kernel der Nodes Prozesse, IPC, Dateisystem und Netz der Pods? |
| A5 | Datensicherung im Cluster | Sind Volumes, Konfiguration, Clusterzustand, etcd, Infrastrukturanwendungen und Registry-Daten gesichert? |
Die Standard-Anforderungen A6 bis A12 betreffen unter anderem Netztrennung mit Whitelisting (A7), versionierte Konfiguration (A8), Service-Accounts (A9), Health Checks (A11) und Registries (A12). Bei erhöhtem Schutzbedarf kommen automatisierte Auditierung gegen Benchmarks (A13), Mikro-Segmentierung (A18), Hochverfügbarkeit (A19) und verschlüsselte etcd-Daten (A20) hinzu.
Die Checkliste: neun Ebenen mit Prüfkriterien
Ebene 1: Control Plane und etcd
Bestanden, wenn API-Server, kubelet-API und etcd nicht aus dem Internet erreichbar sind (Security Checklist), anonyme Anfragen abgewiesen werden, die Autorisierung Node und RBAC enthält, etcd nur mit Client-Zertifikaten und eigener CA erreichbar ist und der kubelet weder anonymen Zugriff noch einen Read-only-Port erlaubt (privater Zugang: NetBird).
Prüfen: curl -sk -o /dev/null -w '%{http_code}\n' https://<api-server>:6443/api liefert 401, wenn anonymer Zugriff aus ist. 403 bedeutet: anonym aktiv, aber ohne Rechte. 200 ist ein Befund. Auf selbst betriebenen Control-Plane-Nodes prüft kube-bench die CIS-Abschnitte 1 und 2.
Warum: Anonymer Zugriff ist standardmäßig aktiv, sobald ein anderer Autorisierungsmodus als AlwaysAllow läuft. Das BSI nennt mangelhafte Authentisierung in der Control Plane als erste Gefährdung: Schutzmechanismen sind „nicht bei allen Produkten standardmäßig aktiviert“.
Maßstab: CIS 1.2.1, 1.2.6 bis 1.2.8, 2.1 bis 2.7, 4.2.1, 4.2.4. BSI A3, A20.
Ebene 2: Zugriffe und RBAC
Bestanden, wenn jede cluster-admin-Bindung einer Person oder Rolle zugeordnet und begründet ist (CIS 5.1.1), kein Konto zu system:masters gehört (5.1.7), keine Wildcard-Rollen bestehen (5.1.3), Menschen sich über OIDC am Identity Provider anmelden statt mit Client-Zertifikaten oder Service-Account-Token (3.1.1, 3.1.2) und der default-Service-Account weder Rechte hat noch genutzt wird (5.1.5, BSI A9). Eine datierte Zugriffsüberprüfung liegt vor.
Prüfen:
kubectl get clusterrolebindings -o json | jq -r '.items[] | select(.roleRef.name=="cluster-admin") | .metadata.name + ": " + ([.subjects[]? | .kind + "/" + .name] | join(", "))'
kubectl auth can-i --list --as=system:serviceaccount:<namespace>:default -n <namespace>
Warum: list und watch auf Secrets legen deren Inhalt offen, und wer Pods anlegen darf, erreicht die Secrets und Service-Accounts des Namespaces (RBAC Good Practices).
Maßstab: CIS 3.1.1 bis 3.1.3, 5.1.1 bis 5.1.13. BSI A3, A9.
Ebene 3: Pod Security
Bestanden, wenn jeder Namespace ein enforce-Label der Pod Security Admission trägt, Anwendungs-Namespaces auf restricted stehen, Ausnahmen auf baseline begründet sind und privileged nur in benannten System-Namespaces gilt. warn und audit auf restricted zeigen Verstöße vor der Umstellung.
Prüfen: kubectl get namespaces --selector='!pod-security.kubernetes.io/enforce' muss leer sein. Eine Umstellung testen Sie mit kubectl label --dry-run=server --overwrite ns <namespace> pod-security.kubernetes.io/enforce=restricted (Anleitung).
Warum: enforce wirkt auf Pods, nicht auf Deployments. Ein verletzendes Deployment wird angelegt, seine Pods werden abgelehnt, und der Grund erscheint als Event am ReplicaSet.
Maßstab: CIS 5.2.1 bis 5.2.12, 5.6.3. BSI: APP.4.4 nennt die Pod Security Standards nicht. A4 verlangt Kernel-Isolation zwischen Pods, SYS.1.6.A17 Container ohne Privilegien.
Ebene 4: Netzwerk-Richtlinien
Bestanden, wenn das CNI NetworkPolicies durchsetzt (CIS 5.3.1), jeder Namespace eine Default-Deny-Richtlinie für Ingress und, wo möglich, Egress plus benannte Freigaben hat (5.3.2) und der Zugriff aus Pods auf die Cloud-Metadaten-API 169.254.169.254 gefiltert ist.
Prüfen: Namespaces ohne NetworkPolicy:
comm -23 <(kubectl get ns -o name | cut -d/ -f2 | sort) <(kubectl get netpol -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\n"}{end}' | sort -u)
Funktionstest: Eine Verbindung aus Namespace A zu einem Service in Namespace B läuft in einen Timeout.
Warum: Eine NetworkPolicy ohne umsetzenden Controller hat keine Wirkung, und Pods sind ohne Richtlinie nicht isoliert. Ein Default-Deny für Egress blockiert auch DNS, geben Sie es ausdrücklich frei.
Maßstab: CIS 5.3.1, 5.3.2. BSI A7 (alle Verbindungen zwischen Namespaces untersagen, benötigte freigeben), A18 (innerhalb des Namespace).
Ebene 5: Secrets
Bestanden, wenn --encryption-provider-config gesetzt und der erste Provider nicht identity ist (CIS 1.2.27, 1.2.28), Secrets als Dateien statt als Umgebungsvariablen eingebunden werden (5.4.1), ein externer Secret-Store bewertet ist (5.4.2), keine Zugangsdaten in Images (SYS.1.6.A8), ConfigMaps oder Git liegen und Service-Account-Token nur in Pods gemountet sind, die sie brauchen (automountServiceAccountToken: false, 5.1.6).
Prüfen: Ein Secret direkt aus etcd lesen, etcdctl get /registry/secrets/<namespace>/<name> | hexdump -C, mit den Zertifikats-Parametern des Clusters. Verschlüsselt ist es, wenn nach dem Pfad k8s:enc: steht (Anleitung).
Warum: Secrets sind base64-kodiert und liegen standardmäßig unverschlüsselt in etcd (Secrets Good Practices).
Maßstab: CIS 1.2.27, 1.2.28, 5.4.1, 5.4.2. BSI A2 (Absicherung der Secrets als Teil der CI/CD-Planung), SYS.1.6.A8.
Ebene 6: Images und Lieferkette
Zur Container-Härtung gehört das Image selbst.
Bestanden, wenn Container nicht als root laufen und nur enthalten, was die Anwendung braucht, Images per Digest referenziert oder beim Deploy per Signatur geprüft werden, die Pipeline Images scannt, Basis-Images nicht abgekündigt sind und eindeutige Versionsnummern tragen (SYS.1.6.A6). Eine eigene Registry hat personenbezogene Accounts, verschlüsselte Kommunikation, Protokollierung und Datensicherung (BSI A12).
Prüfen: Images ohne Digest:
kubectl get pods -A -o jsonpath='{range .items[*]}{range .spec.containers[*]}{.image}{"\n"}{end}{end}' | sort -u | grep -v '@sha256:'
Dazu der Scan-Bericht der Pipeline mit Datum.
Warum: Das Image hinter einem Tag lässt sich in der Registry ändern (Security Checklist), ein Digest nicht.
Maßstab: CIS 5.5.1 (ImagePolicyWebhook). BSI SYS.1.6.A6, APP.4.4 A12.
Ebene 7: Logging und Audit
Bestanden, wenn der API-Server mit --audit-policy-file startet, die Policy sicherheitsrelevante Ereignisse abdeckt (CIS 3.2.1, 3.2.2), die Logs außerhalb des Clusters liegen (SYS.1.6.A7 verlangt für Container-Logs mindestens eine Ablage außerhalb des Containers), die Aufbewahrungsfrist festgelegt ist und die Audit-Logs vor allgemeinem Zugriff geschützt sind.
Prüfen: Flags im API-Server-Manifest, bei kubeadm /etc/kubernetes/manifests/kube-apiserver.yaml. Stichprobe: einen Test-Namespace anlegen und löschen. Bestanden, wenn das Log-Ziel beide Aktionen mit Benutzer und Zeit enthält.
Warum: Ohne --audit-policy-file werden keine Ereignisse protokolliert (Auditing).
Maßstab: CIS 1.2.16 bis 1.2.19, 3.2.1, 3.2.2. BSI: APP.4.4 enthält keine Anforderung an das Audit-Log der API. A12 nennt die Protokollierung von Veränderungen an Infrastrukturanwendungen.
Ebene 8: Upgrades und Patchstand
Bestanden, wenn die Minor-Version noch gepflegt wird, die kubelet-Versionen innerhalb der Version Skew Policy liegen (höchstens drei Minor-Versionen unter dem API-Server, nie darüber), die Zertifikate der Control Plane nicht innerhalb von 30 Tagen ablaufen, kein Client veraltete APIs aufruft und der Patchstand der Node-Betriebssysteme dokumentiert ist. Stand 28.10.2026 pflegt das Projekt 1.35, 1.36 und 1.37. Die Version 1.34 endete am 27.10.2026 (Releases).
Prüfen:
kubectl version
kubectl get nodes -o wide
# nur bei kubeadm, auf einem Control-Plane-Node
kubeadm certs check-expiration
kubectl get --raw /metrics | grep apiserver_requested_deprecated_apis
Warum: Nach dem Support-Ende erscheinen keine Sicherheitskorrekturen mehr. Von kubeadm erzeugte Zertifikate gelten standardmäßig ein Jahr, die CA-Zertifikate zehn Jahre, die Metrik beschreibt die Deprecation Policy.
Maßstab: CIS enthält keine Update-Kontrolle. BSI SYS.1.6.A2 (Planung der Verwaltung über den Lebenszyklus inklusive Updates), SYS.1.6.A14 (Aktualisierung von Images).
Ebene 9: Backup und Restore
Bestanden, wenn die Sicherung alle Posten aus APP.4.4 A5 enthält (Persistent Volumes, Konfiguration der Control Plane, Clusterzustand mit Erweiterungen, etcd, Infrastrukturanwendungen, Registry-Daten), Snapshots sie nicht ersetzen, das Ziel getrennt vom Cluster liegt, etcd-Snapshot-Dateien verschlüsselt sind (etcd-Dokumentation) und ein Restore-Test mit Datum, Dauer und Ergebnis protokolliert ist.
Prüfen: etcdctl snapshot save und etcdutl --write-out=table snapshot status snapshot.db, dann ein Restore in eine leere Umgebung (Kubernetes-Backup).
Warum: Die Konfiguration cis-2.0 enthält keine Kontrolle zu Backup. Das BSI stuft die Datensicherung als Basis-Anforderung ein und schreibt, dass Snapshots die Datensicherung nicht ersetzen dürfen.
Maßstab: BSI A5.
Was kube-bench abdeckt und was nicht
Wir haben die Konfiguration cis-2.0 von kube-bench ausgezählt:
| CIS-Abschnitt | Kontrollen | automatisiert | manuell |
|---|---|---|---|
| 1 Control Plane (Dateien, API-Server, Controller Manager, Scheduler) | 60 | 47 | 13 |
| 2 etcd | 7 | 6 | 1 |
| 3 Authentifizierung und Logging | 5 | 0 | 5 |
| 4 Worker Nodes (kubelet, Dateien, kube-proxy) | 25 | 12 | 13 |
| 5 Richtlinien (RBAC, Pod Security, Netzwerk, Secrets) | 34 | 0 | 34 |
| Summe | 131 | 65 | 66 |
Ein grüner Lauf sagt damit nichts über RBAC, Pod Security, Netzwerk-Richtlinien und den Umgang mit Secrets und nichts über den Inhalt der Audit-Policy. Diese Ebenen prüfen die kubectl-Befehle oben. Für Control-Plane-Prüfungen muss der Pod aus dem job.yaml auf einem Control-Plane-Node laufen (nodeSelector und Tolerations). Bei Managed Kubernetes sind diese Nodes nicht erreichbar (Dokumentation).
NIS2: welche technischen Nachweise der Cluster liefert
Die Zuordnung ist unsere Lesehilfe, kein offizielles Mapping. Der Cluster liefert technische Nachweise, die Bewertung der Angemessenheit bleibt bei der Einrichtung.
| § 30 Abs. 2 BSIG | Mindestbereich | Nachweis aus dem Cluster |
|---|---|---|
| Nr. 1 | Konzepte zu Risikoanalyse und IT-Sicherheit | Betriebskonzept mit Separierung, Rollen und CI/CD-Planung (APP.4.4 A1, A2) |
| Nr. 2 | Bewältigung von Sicherheitsvorfällen | Audit-Log im externen Ziel mit festgelegter Aufbewahrung |
| Nr. 3 | Aufrechterhaltung des Betriebs, Backup, Wiederherstellung | Restore-Protokoll mit Datum, Dauer und Ergebnis |
| Nr. 4 | Sicherheit der Lieferkette | Image-Herkunft (Digest, Signaturprüfung), Registry-Zugriffe |
| Nr. 5 | Wartung, Schwachstellenmanagement | Versionsliste mit Support-Ende, Scan-Berichte, Upgrade-Protokolle |
| Nr. 6 | Bewertung der Wirksamkeit | Datierter kube-bench- oder Audit-Bericht mit Maßnahmenliste |
| Nr. 8 | Kryptographie | Verschlüsselungskonfiguration für Secrets, TLS-Konfiguration von etcd, Zertifikatsliste |
| Nr. 9 | Zugriffskontrolle | RBAC-Export mit Stichtag, cluster-admin-Liste mit Begründung |
| Nr. 10 | Multi-Faktor-Authentifizierung | OIDC-Anbindung, MFA-Richtlinie am Identity Provider |
Nr. 7 (Schulungen) hat keinen Cluster-Nachweis.
Unser Vorgehen bei WZ-IT
Das Cluster-Audit gleicht den Cluster mit dem CIS Kubernetes Benchmark und APP.4.4 ab. Geprüft werden unter anderem Versionen und Upgrade-Pfad, RBAC und Service-Accounts, Secrets, Network Policies sowie Backup und Restore-Weg. 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.
Das Cluster-Audit kostet ab 1.490 € netto einmalig und wird auf den ersten Betriebsmonat angerechnet. Managed Kubernetes ab 590 € netto je Cluster und Monat inklusive drei Worker-Nodes betreibt den Cluster mit Monitoring, Upgrades, Backups mit Restore-Test und Härtung. Maßnahmen aus dem Bericht setzen wir alternativ über den Kubernetes-Support um, 120 € netto je Stunde ohne Vertrag. Preise netto, Stand Oktober 2026.
Stand und Methodik
- Stand: 28.10.2026, alle Quellen an diesem Tag abgerufen.
- kube-bench-Zählung: Die Dateien in
cfg/cis-2.0(Branch main, Stand 05.10.2026) wurden nach den Kennzeichen „Automated“ und „Manual“ ausgezählt. cis-2.0 ist nicht Teil des Releases v0.16.0, auf das dasjob.yamlverweist. - CIS: Das Benchmark-PDF ist ohne Registrierung nicht abrufbar. Die Kontrollnummern folgen kube-bench cis-2.0 und können in Version 2.1.0 abweichen.
- BSI: APP.4.4 und SYS.1.6, Edition 2023, vollständig gelesen, Anforderungen mit Nummer genannt. Die Edition 2023 des Kompendiums ist seit dem 1. Februar 2023 verfügbar (BSI).
- NIS2: § 30 BSIG gelesen. Die Nachweis-Tabelle ist eine Lesehilfe.
- Planungswerte: Die 30 Tage für Zertifikate sind ein Richtwert. Die Antwort 401 oder 403 beim Test des API-Servers bildet die Standard-RBAC-Regeln ab; eigene Regeln für
system:anonymousändern das Ergebnis.
Weiterführende Guides
- Kubernetes Go-Live-Checkliste - 25 Prüfpunkte als Selbsttest vor dem Produktivbetrieb
- Kubernetes-Backup: die vier Ebenen - Ebene 9 im Detail
- Kubernetes-Cluster übernehmen: Audit-Checkliste - der Betriebsteil
- Kubernetes privat über NetBird erreichen - keine öffentliche API
Cluster-Prüfung oder Betriebsübergabe? Das Audit liefert den Bericht, Managed Kubernetes setzt die Maßnahmen um. Cluster-Audit · Managed Kubernetes
Weiterführend: CIS Kubernetes Benchmark umsetzen: kube-bench und Befunde
