Kubernetes Penetration Test: Ablauf, Tools & Kosten 2026

TL;DR

Ein Kubernetes Penetration Test prüft Ihren Cluster auf real ausnutzbare Schwachstellen: exponierte API-Server und Kubelets, überprivilegiertes RBAC, privilegierte Pods, verwundbare Container-Images und fehlende Netzwerksegmentierung. Der Ablauf gliedert sich in fünf Phasen von Scoping bis Retest. Automatisiert wird mit kube-hunter (Angreifer-Perspektive), kube-bench (CIS-Benchmark), Trivy (Image- und Config-Scan), ergänzt um manuelle RBAC- und Escape-Tests. Realistischer Aufwand für einen einzelnen Produktions-Cluster: 5 bis 10 Personentage extern, grob 6.000 bis 16.000 Euro (Schätzung, Stand 2026, DACH-Marktbeobachtung, Konfidenz mittel). Der Test liefert einen Momentaufnahme-Nachweis für NIS2 und ISO 27001, ersetzt aber kein kontinuierliches Hardening.

Rechtlicher Hinweis: Führen Sie Penetrationstests ausschließlich auf Clustern durch, für die eine schriftliche Beauftragung mit definiertem Scope vorliegt. Unautorisierte Tests erfüllen den Tatbestand des Ausspähens von Daten (§ 202a StGB). Bei Managed Kubernetes (EKS, AKS, GKE) gilt zusätzlich die Pentest-Policy des jeweiligen Cloud-Providers.

Problem: Der Kunde oder die Compliance fordert einen Pentest

Der Auslöser ist selten technische Neugier. In der Praxis kommt die Anforderung aus einer von drei Richtungen:

• NIS2: Seit der Umsetzung der EU-Richtlinie in nationales Recht müssen wesentliche und wichtige Einrichtungen "Verfahren zur Bewertung der Wirksamkeit von Risikomanagementmaßnahmen" nachweisen. Für einen Kubernetes-basierten Dienst heißt das konkret: regelmäßige technische Sicherheitsüberprüfungen der Produktionsumgebung.
• ISO 27001: Control A.8.8 (Management technischer Schwachstellen) und A.8.29 (Sicherheitstests in Entwicklung und Abnahme) verlangen belegbare Tests. Ein Auditor akzeptiert "wir nutzen Trivy im CI" als Teilnachweis, will für die Zertifizierung aber meist einen expliziten Penetrationstest sehen.
• Enterprise-Kunde im Sales-Prozess: Ihr größter Interessent schickt ein Security-Assessment-Formular. Feld 14: "Wann wurde zuletzt ein Penetrationstest der Produktionsumgebung durchgeführt? Bericht beifügen." Ohne Antwort platzt der Deal oder verzögert sich um ein Quartal.

Für ein SaaS-Unternehmen mit 10 bis 100 Mitarbeitenden ist der dritte Fall der häufigste und der teuerste, wenn er unbeantwortet bleibt. Die gute Nachricht: Ein sauber dokumentierter Kubernetes-Pentest deckt in der Regel alle drei Anforderungen gleichzeitig ab.

Grundlagen: Scope, Testtiefe und was NICHT getestet wird

Bevor ein einziges Tool läuft, wird der Scope definiert. Ohne klaren Scope wird der Test entweder zu teuer oder wertlos.

Black-, Grey- und White-Box

Für Kubernetes ist Grey-Box das produktivste Modell. Die meisten realen Cluster-Kompromittierungen beginnen nicht am API-Server von außen, sondern mit einer Schwachstelle in einer Anwendung, die dem Angreifer einen Pod verschafft. Von dort läuft der "Container-Breakout und Lateral-Movement"-Pfad. Genau den will man testen.

Was gehört in den Scope

• Control-Plane-Exposition: API-Server, etcd, Kubelet, Scheduler, Controller-Manager
• RBAC-Modell: ClusterRoleBindings, ServiceAccount-Rechte, Token-Handhabung
• Workload-Härtung: SecurityContext, Pod Security Standards, privilegierte Container
• Netzwerk: NetworkPolicies, Ingress-Konfiguration, Service-Exposition
• Supply Chain: Image-Schwachstellen, Image-Provenienz, Registry-Zugriff
• Secrets-Management: etcd-Verschlüsselung, gemountete Tokens, Klartext-Secrets

Was ausdrücklich NICHT im Scope ist

Das gehört in den Vertrag, sonst gibt es Streit:

• Managed Control Plane: Bei EKS, AKS und GKE betreibt der Provider die Control Plane. Sie können und dürfen den API-Server nicht mit einem DoS-Test überziehen. Der Test beschränkt sich auf Ihre Verantwortungsebene (Worker-Nodes, Workloads, RBAC, Netzwerk).
• Denial-of-Service: Standardmäßig ausgeschlossen. Niemand will die Produktion lahmlegen, um zu beweisen, dass man sie lahmlegen kann.
• Social Engineering und physischer Zugang: Anderer Test, anderer Scope.
• Fremde Tenant-Daten in Shared-Clustern.

Praxis: Der 5-Phasen-Ablauf

Phase 1 — Scoping und Recon

Zieldefinition, Genehmigung, Zugangsniveau. Dann die passive Erkundung: Was ist überhaupt erreichbar?

# Ist der API-Server anonym erreichbar? Erwartung: 401, nicht 200
curl -sk https://<cluster-ip>:6443/api/v1 | head -20

# Was darf ein anonymer Aufrufer? Erwartung: praktisch nichts
kubectl auth can-i --list --as=system:anonymous

# Kubelet-Port 10250 offen und unauthentifiziert? Kritisch, wenn ja
curl -sk https://<node-ip>:10250/pods | head -c 200

Bei Grey-Box startet der Tester mit den Rechten eines Standard-ServiceAccount und klärt zuerst den eigenen Bewegungsspielraum:

# Aus einem übernommenen Pod: Was kann mein Token?
kubectl auth can-i --list
# Rote Flaggen: "secrets [get,list]", "pods/exec [create]", "*/* [*]"

Phase 2 — Automatisiertes Scanning

Drei Tools decken den Großteil der maschinell findbaren Probleme ab. Sie ersetzen keine manuelle Analyse, sparen aber die stumpfe Fleißarbeit.

kube-bench — prüft die Cluster-Konfiguration gegen den CIS Kubernetes Benchmark:

# Als Job im Cluster, liest die tatsächliche Node-Konfiguration
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml
kubectl logs job/kube-bench

# Nur die fehlgeschlagenen Checks, maschinenlesbar
kube-bench run --json | jq '.Controls[].tests[].results[] | select(.status=="FAIL")'

kube-hunter — nimmt die Angreifer-Perspektive ein und sucht nach ausnutzbaren Netzwerk-Schwachstellen:

# Von innen, als Pod: findet, was ein kompromittierter Workload sieht
kubectl run kube-hunter --image=aquasec/kube-hunter \
  --restart=Never --rm -it -- --pod

# Ergebnis als JSON für den Bericht festhalten
kube-hunter --pod --report json > kube-hunter-report.json

Trivy — deckt die Supply-Chain- und Config-Seite ab, die kube-bench und kube-hunter nicht sehen:

# Alle laufenden Workloads im Cluster auf CVEs und Misconfigs scannen
trivy k8s --report summary cluster

# Ein konkretes Image tief prüfen, nur kritische und hohe CVEs
trivy image --severity CRITICAL,HIGH registry.example.de/app/api:1.8.2

# Manifeste vor dem Deployment auf Fehlkonfigurationen linten
trivy config ./k8s/

Phase 3 — Manuelle Analyse und Exploitation

Hier passiert die eigentliche Wertschöpfung. Scanner finden bekannte Muster, ein Tester findet Ketten.

RBAC-Enumeration deckt die häufigste Eskalationsursache auf:

# Wer hat cluster-admin? Die Kronjuwelen-Frage
kubectl get clusterrolebindings -o json | \
  jq -r '.items[] | select(.roleRef.name=="cluster-admin") |
  .subjects[]? | "\(.kind): \(.name) (ns: \(.namespace // "cluster-wide"))"'

# Wer darf Secrets clusterweit lesen?
rbac-lookup --kind serviceaccount | grep -i secret

# Wer darf Pods erstellen? Das ist oft ein Pfad zu Node-Root
kubectl-who-can create pods -A

Der klassische Eskalationspfad in Grey-Box-Tests: Ein ServiceAccount darf Pods erstellen. Der Tester deployt einen Pod, der das Host-Dateisystem mountet, und liest die kubelet-Credentials oder die Node-eigenen Tokens aus.

# escape-test.yaml — NUR in autorisiertem Scope, dokumentiert
apiVersion: v1
kind: Pod
metadata:
  name: node-escape-poc
  namespace: default
spec:
  hostPID: true
  containers:
    - name: shell
      image: alpine:3.20
      command: ["sh", "-c", "sleep 3600"]
      securityContext:
        privileged: true            # Escape-Vektor: voller Node-Zugriff
      volumeMounts:
        - name: host
          mountPath: /host
  volumes:
    - name: host
      hostPath:
        path: /                     # Mountet das gesamte Host-Root

Gelingt das Deployment, ist bewiesen: Ein kompromittierter Workload in diesem Namespace kann zum Node-Root werden. Der Gegen-Nachweis ist, dass Pod Security Standards (restricted) oder eine Admission-Policy (Kyverno, Gatekeeper) das Manifest ablehnen.

Ergänzend prüft der Tester privilegierte Pods im Bestand:

# Bereits laufende privilegierte oder host-nahe Pods
kubectl get pods -A -o json | jq -r '.items[] | select(
  .spec.hostNetwork==true or .spec.hostPID==true or
  (.spec.containers[].securityContext.privileged==true)
) | "\(.metadata.namespace)/\(.metadata.name)"'

Phase 4 — Bewertung und Berichterstellung

Findings werden nach CVSS und Ausnutzbarkeit im konkreten Kontext bewertet, nicht nur nach abstraktem Schweregrad. Ein privilegierter Pod im isolierten Batch-Namespace ohne eingehenden Traffic ist ein anderes Risiko als derselbe Pod hinter dem öffentlichen Ingress. Der Bericht enthält pro Finding: Reproduktionsschritte, Nachweis, konkreten Fix und eine Risikoeinstufung.

Phase 5 — Retest

Nach der Behebung wird gezielt nachgetestet, ob die kritischen und hohen Findings wirklich geschlossen sind. Erst der Retest liefert den belastbaren Nachweis für Auditor und Kunde. Ohne Retest ist der Bericht eine Mängelliste, kein Compliance-Beleg.

Typische Findings

Aus wiederkehrenden Mustern in Kubernetes-Umgebungen mittelständischer SaaS-Betreiber (Beobachtung, keine Einzelfallstudie, Konfidenz mittel):

Aufwand und Kosten: eine ehrliche Schätzung

Alle Zahlen sind Marktbeobachtung DACH, Stand Mitte 2026, als Schätzung zu verstehen (Konfidenz mittel). Die Spanne hängt stark von Cluster-Anzahl, Multi-Tenancy und Testtiefe ab.

Externer Dienstleister, einzelner Produktions-Cluster

Bei einem marktüblichen Tagessatz von grob 1.200 bis 1.600 Euro für spezialisierte Kubernetes-Security ergibt das eine Größenordnung von 6.000 bis 16.000 Euro für einen einzelnen Cluster inklusive Retest. Ein reiner Compliance-Nachweis am unteren Ende, eine tiefe Grey-Box-Analyse mit mehreren Clustern am oberen.

Intern vs. extern

Die sinnvolle Aufteilung: Kontinuierliches automatisiertes Scanning intern (kube-bench, Trivy im CI, wöchentlicher kube-hunter-Lauf) plus jährlicher externer Pentest für den unabhängigen Nachweis. Für NIS2 und ISO 27001 zählt die Unabhängigkeit des Prüfers, deshalb kommt man am externen Test für die Zertifizierung selten vorbei.

Fallstricke: Der Pentest ist eine Momentaufnahme

Der teuerste Denkfehler: den bestandenen Pentest als Dauerzustand zu verbuchen. Ein Cluster ist am Tag nach dem Test schon wieder ein anderer. Jedes Deployment, jedes neue Image, jede RBAC-Änderung verschiebt die Angriffsfläche.

• Ein Pentest ist eine Momentaufnahme, kein Zustand. Der Bericht beschreibt den Cluster vom Testtag. Ohne kontinuierliche Kontrollen ist er nach drei Sprints veraltet.
• Scanner-Findings sind keine Exploits. Ein CVE-Report von Trivy ist eine Hypothese. Ob die Schwachstelle in Ihrem Kontext ausnutzbar ist, entscheidet die manuelle Analyse. Umgekehrt: Ein sauberer Scanner-Lauf ist kein Freibrief.
• Der Retest wird gern gespart. Ohne Retest bleibt offen, ob die kritischen Findings tatsächlich behoben sind. Genau danach fragt der Auditor.
• Härtung ersetzt der Pentest nicht. Der Test findet Lücken. Schließen müssen Sie sie selbst, und zwar kontinuierlich über Admission-Policies, PSS, gemanagte RBAC und ein Trivy-Gate im CI.

Wer den internen Ist-Zustand vor der Beauftragung selbst prüfen will, macht vorab den kostenlosen Kubernetes Security Quick-Check.

FAQ

Wie oft sollte ein Kubernetes-Pentest durchgeführt werden?

Mindestens einmal jährlich und nach jeder größeren Architekturänderung (neuer Cluster, Wechsel des CNI, Multi-Tenancy-Umbau, Major-Version-Upgrade). Automatisierte Scans (kube-bench, Trivy, kube-hunter) laufen unabhängig davon kontinuierlich im CI und als Cronjob. Der jährliche externe Test liefert den unabhängigen Nachweis, das automatisierte Scanning die laufende Absicherung dazwischen.

Wer darf einen Pentest durchführen?

Jeder mit schriftlicher Beauftragung und definiertem Scope. Intern ist das rechtlich unkompliziert, taugt aber wegen fehlender Unabhängigkeit nur bedingt als Compliance-Nachweis. Für NIS2 und ISO 27001 ist ein unabhängiger Dritter mit nachweisbarer Kubernetes-Kompetenz die belastbare Variante. Achten Sie auf Referenzen speziell für Container- und Cluster-Security, nicht auf generische Web-Pentest-Zertifikate.

Kann ich einen Managed Cluster (EKS, AKS, GKE) überhaupt testen lassen?

Ja, aber die Control Plane gehört dem Provider und ist tabu für aggressive Tests. Getestet wird Ihre Verantwortungsebene: Worker-Nodes, Workloads, RBAC, NetworkPolicies, Ingress, Secrets-Handhabung. AWS, Azure und Google erlauben Kunden-initiierte Pentests der eigenen Ressourcen im Rahmen ihrer jeweiligen Policy, teils ohne Vorab-Genehmigung, teils mit Anmeldung. Prüfen Sie die aktuelle Policy des Providers vor Testbeginn.

Kann ich in der Produktion testen oder brauche ich Staging?

Passive Prüfungen (kube-bench, Trivy, kubectl-basierte RBAC-Analyse, kube-hunter im Erkundungsmodus) sind in der Produktion unbedenklich. Aktive Exploitation, etwa das Deployen privilegierter Escape-Pods, gehört in ein möglichst produktionsnahes Staging. Ist die Konfiguration von Staging und Produktion nachweislich identisch (GitOps, gleiche Manifeste), überträgt sich das Ergebnis. Weicht sie ab, ist der Staging-Test nur bedingt aussagekräftig.

Was bekomme ich als Nachweis für Kunden und Auditoren?

Einen Bericht mit Management-Summary, Finding-Liste nach Schweregrad mit Reproduktionsschritten und Fixes, sowie das Retest-Attest, das die Behebung der kritischen und hohen Findings bestätigt. Für den Sales-Prozess wird oft eine kürzere, teilbare Zusammenfassung (Attestation Letter) ohne technische Details erstellt, die Sie an Interessenten weitergeben können, ohne die Schwachstellen-Details preiszugeben.

Fazit

Ein Kubernetes Penetration Test ist kein Nice-to-have, sondern für NIS2, ISO 27001 und die meisten Enterprise-Sales-Prozesse eine harte Anforderung. Der Fünf-Phasen-Ablauf mit kube-hunter, kube-bench und Trivy plus manueller RBAC- und Escape-Analyse ist etabliert und liefert für 6.000 bis 16.000 Euro (Schätzung) einen belastbaren Nachweis pro Cluster. Der Test bleibt aber eine Momentaufnahme. Der Wert entsteht erst, wenn die Findings behoben, im Retest bestätigt und durch kontinuierliches Hardening dauerhaft gehalten werden.

Bevor Sie ein mehrtägiges externes Mandat beauftragen, lohnt der schnelle Blick auf den Ist-Zustand. Unser kostenloser Kubernetes Security Quick-Check zeigt Ihnen die häufigsten kritischen Fehlkonfigurationen in Ihrem Cluster und schafft die Grundlage für ein präzises Pentest-Scoping, das Ihr Budget nicht in der Recon-Phase verbrennt.