TL;DR

• Die meisten Kubernetes-Security-Audits sind Checklisten-Abgleiche, keine echten Penetrationstests -- Sie zahlen 20.000-40.000 EUR fuer ein Dokument, das Ihnen nicht zeigt, wie ein Angreifer wirklich eindringt.
• Echte Pentester brechen in Ihren Cluster ein (kontrolliert), demonstrieren Angriffsketten und zeigen Ihnen, welche Schwachstellen in Kombination kritisch werden.
• Red Flags bei Auditoren: Kein Zugriff auf den Cluster noetig, Ergebnis nach 3 Tagen fertig, nur CVE-Scanner-Output im Bericht, keine Angriffsnarrative.
• Gute Security-Pruefer erklaeren Ihnen den Business Impact, priorisieren nach Ausnutzbarkeit (nicht nach CVSS-Score) und liefern umsetzbare Massnahmen.
• Managed Kubernetes mit integrierter Security macht viele Pentest-Findings obsolet, weil Haeufungspunkte wie RBAC, Network Policies und Image Scanning bereits abgedeckt sind.

Echter Pentest vs. Compliance-Theater: Woran Sie gute Security-Pruefer erkennen

Das Problem: Sie zahlen fuer Sicherheit und bekommen ein PDF

Als IT-Leiter im Mittelstand stehen Sie unter Druck. NIS2 verlangt Nachweise. Kunden fordern SOC-2-Berichte. Die Geschaeftsfuehrung will wissen, ob "alles sicher ist". Also beauftragen Sie einen Security-Audit fuer Ihre Kubernetes-Infrastruktur.

Vier Wochen spaeter erhalten Sie ein 80-seitiges PDF. Darin: 247 Findings, bunt sortiert nach Kritikalitaet. Rot, Gelb, Gruen. Der Executive Summary sagt: "Die Infrastruktur weist mehrere kritische Schwachstellen auf. Wir empfehlen die zeitnahe Behebung."

Sie geben das Dokument an Ihr DevOps-Team. Die lesen es, seufzen, und fragen: "Was davon ist wirklich gefaehrlich? Und was ist nur theoretisch relevant?"

Das ist der Moment, in dem Sie erkennen, dass Sie gerade 25.000 EUR fuer Compliance-Theater bezahlt haben.

Was Compliance-Theater ist -- und was nicht

Compliance-Theater

Compliance-Theater entsteht, wenn der Zweck einer Security-Pruefung nicht die Sicherheit ist, sondern das Abhaken einer Anforderung. Der Auditor produziert ein Dokument, der Kunde legt es in den Ordner "Compliance", und beide Seiten sind zufrieden -- bis der erste echte Angriff kommt.

Typische Merkmale:

Compliance-Theater erkennen Sie an:

├── Der Auditor braucht keinen Cluster-Zugriff
│   ("Wir arbeiten mit Screenshots und Konfigurationsdateien")
│
├── Der Bericht ist nach 3-5 Tagen fertig
│   (Ein echter Pentest dauert mindestens 2 Wochen)
│
├── Findings sind 1:1 aus einem Tool kopiert
│   (Trivy-Output, kube-bench-Report, Nessus-Scan)
│
├── Keine Angriffsketten beschrieben
│   ("CVE-2025-1234 in nginx:1.24 -- Critical")
│   (Aber: Ist der nginx ueberhaupt von aussen erreichbar?)
│
├── Empfehlungen sind generisch
│   ("Aktualisieren Sie alle Container-Images")
│   (Statt: "Dieses spezifische Image erlaubt Container Escape")
│
└── Kein Retest angeboten
    ("Unser Auftrag endet mit dem Bericht")

Echte Security-Pruefung

Ein echter Kubernetes-Pentest folgt einem anderen Ansatz. Der Pruefer denkt wie ein Angreifer: Welche Angriffsflaeche gibt es? Was passiert, wenn ein Pod kompromittiert wird? Wie weit komme ich von dort?

Echte Security-Pruefung erkennen Sie an:

├── Der Pruefer arbeitet im Cluster
│   (Read-Only-Zugriff oder eigener Test-Namespace)
│
├── Der Test dauert 2-4 Wochen
│   (Davon 1-2 Wochen aktives Testing)
│
├── Angriffsketten werden demonstriert
│   ("Von Pod A ueber ServiceAccount B zu Secret C")
│
├── Business Impact wird erklaert
│   ("Ein Angreifer koennte Kundendaten exportieren")
│
├── Findings werden nach Ausnutzbarkeit priorisiert
│   (Nicht: 247 Findings. Sondern: 5 kritische Pfade)
│
└── Retest ist Teil des Auftrags
    ("Nach Behebung pruefen wir erneut")

Was ein guter Kubernetes-Pentest abdeckt

Phase 1: Reconnaissance und Angriffsflaeche

Der Pruefer kartiert, was von aussen sichtbar ist:

# Was sieht ein Angreifer von aussen?

# Ingress-Endpunkte und exponierte Services
# (Der Pruefer testet, nicht Sie -- hier zur Illustration)

# Typische Fragen:
# - Welche Services sind ueber Ingress erreichbar?
# - Gibt es exponierte NodePorts?
# - Ist der API-Server aus dem Internet erreichbar?
# - Welche TLS-Versionen und Cipher Suites sind aktiv?
# - Gibt es Default-Credentials auf exponierten Diensten?

Warum das wichtig ist: Viele Mittelstaendler exponieren versehentlich Services, die nur intern sein sollten. Ein NodePort 30000-32767, der nicht durch eine Firewall blockiert ist, oeffnet den gesamten Service-Katalog.

Phase 2: Authentifizierung und Autorisierung

RBAC-Analyse (Auszug aus einem echten Pentest-Bericht):

Finding: ServiceAccount "monitoring" in Namespace "kube-system"
hat ClusterRole "cluster-admin" gebunden.

Angriffskette:
1. Angreifer kompromittiert beliebigen Pod im Cluster
2. Pod mounted automatisch ServiceAccount-Token
3. Angreifer findet monitoring-SA Token via Volume Mount
4. Mit cluster-admin kann der Angreifer:
   - Alle Secrets lesen (inkl. DB-Passwoerter)
   - Neue Pods erstellen (Crypto Mining, Datenexfiltration)
   - Andere Namespaces manipulieren

Business Impact: Vollstaendige Cluster-Uebernahme
Ausnutzbarkeit: Hoch (kein Spezialwissen noetig)

Ein Checklisten-Audit haette hier nur gemeldet: "ServiceAccount mit cluster-admin gefunden -- Risiko: Hoch". Der Pentest zeigt die konkrete Angriffskette und den Business Impact.

Phase 3: Container und Image Security

Nicht nur CVEs zaehlen -- der Kontext macht den Unterschied:

CVE-Scanner-Output (Compliance-Theater):
├── nginx:1.24 -- 3 Critical, 12 High, 47 Medium CVEs
├── node:18 -- 1 Critical, 8 High, 23 Medium CVEs
└── postgres:15 -- 2 Critical, 5 High, 15 Medium CVEs
    "67 kritische und hohe Schwachstellen gefunden"

Pentest-Analyse (echter Wert):
├── nginx:1.24 CVE-2024-XXXX -- nicht ausnutzbar
│   (Betrifft Mail-Modul, das nicht kompiliert ist)
├── node:18 CVE-2025-YYYY -- ausnutzbar, aber:
│   (Container laeuft als non-root, kein Host-Zugriff)
└── postgres:15 CVE-2025-ZZZZ -- KRITISCH
    (Erlaubt SQL Injection, DB enthaelt Kundendaten,
     keine Network Policy limitiert den Zugriff)

    "1 ausnutzbare Schwachstelle mit Business Impact"

Der Unterschied: 67 Findings vs. 1 Finding das zaehlt. Ihr DevOps-Team weiss jetzt genau, was Prioritaet hat.

Phase 4: Network Policies und Lateral Movement

Typischer Pentest-Ablauf:

1. Angreifer ist in Pod "webapp" (Namespace: production)

2. Netzwerk-Scan aus dem Pod:
   Ergebnis: Alle Pods im Cluster erreichbar
   (Keine Network Policies konfiguriert)

3. Angreifer erreicht:
   ├── PostgreSQL auf Port 5432 (kein Passwort noetig
   │   von innerhalb des Clusters)
   ├── Redis auf Port 6379 (Standard, kein Auth)
   ├── Elasticsearch auf Port 9200 (volle Daten)
   └── Kubernetes API auf Port 443
       (mit dem ServiceAccount-Token des Pods)

4. Business Impact: Ein kompromittierter Pod fuehrt zu
   vollstaendigem Zugriff auf alle Datenbanken

Das ist der Moment, in dem IT-Leiter blass werden. Nicht weil die einzelne Schwachstelle kritisch ist, sondern weil die Kombination aus fehlenden Network Policies, schwachen ServiceAccounts und exponierten Datenbanken einen trivialen Angriffspfad eroeffnet.

Ein Checklisten-Audit haette drei separate Findings erzeugt. Der Pentest zeigt, wie sie zusammenspielen.

Red Flags: Woran Sie schlechte Auditoren erkennen

Red Flag 1: "Wir brauchen keinen Cluster-Zugriff"

Ein Kubernetes-Security-Audit ohne Cluster-Zugriff ist wie eine Gebaeude-Inspektion per Google Street View. Sie koennen die Fassade beurteilen, aber nicht den Brandschutz pruefen.

Minimum: Read-Only-Zugriff auf die Kubernetes-API (RBAC: view-ClusterRole) und Netzwerkzugriff zum Cluster.

Red Flag 2: "Der Bericht ist in einer Woche fertig"

Ein serioeser Kubernetes-Pentest braucht:

• 2-3 Tage Vorbereitung und Scoping
• 5-10 Tage aktives Testing
• 3-5 Tage Bericht und Priorisierung
• Gesamt: 2-4 Wochen

Wenn jemand nach 3 Tagen ein Ergebnis liefert, hat er Tools laufen lassen und den Output formatiert. Das koennen Sie auch selbst.

Red Flag 3: Nur automatisierte Scans

So sieht ein reiner Tool-Report aus:

1. kube-bench CIS Benchmark: 45 von 120 Checks failed
2. Trivy Scan: 312 CVEs in 24 Images
3. kubeaudit: 18 misconfigurations
4. Polaris: Score 62/100

"Empfehlung: Beheben Sie alle Findings."

Das ist kein Pentest. Das ist ein Shell-Script mit PDF-Wrapper. Die Tools sind nuetzlich als Input, aber der Wert eines Pentests liegt in der manuellen Analyse, die zeigt, welche Findings in Ihrer spezifischen Umgebung wirklich ausnutzbar sind.

Red Flag 4: CVSS-Score als einziges Priorisierungskriterium

CVSS (Common Vulnerability Scoring System) bewertet Schwachstellen isoliert. Ein CVSS 9.8 in einem Container, der keine Netzwerkverbindung hat und als non-root laeuft, ist in der Praxis weniger gefaehrlich als ein CVSS 6.5 in einem privilegierten Pod mit Host-Zugriff.

Gute Pruefer nutzen CVSS als Ausgangspunkt und bewerten dann:

• Ist die Schwachstelle in dieser Umgebung erreichbar?
• Welche Voraussetzungen muss ein Angreifer erfuellen?
• Was ist der tatsaechliche Business Impact?

Red Flag 5: Kein Retest im Angebot

Ein Audit ohne Retest ist eine Diagnose ohne Nachuntersuchung. Sie erhalten eine Liste von Problemen, beheben sie (hoffentlich), aber niemand prueft, ob die Behebung wirksam war. Gute Pruefer bieten einen Retest 4-8 Wochen nach dem initialen Bericht an.

Fragen, die Sie jedem Auditor stellen sollten

Die Antworten verraten Ihnen, ob Sie einen echten Pruefer oder einen Compliance-Dienstleister vor sich haben:

1. "Welche Kubernetes-spezifischen Angriffe testen Sie?"

Gute Antwort: "Container Escape, RBAC Privilege Escalation, ServiceAccount Token Abuse, etcd Access, Kubelet API Exploitation, Supply Chain Attacks ueber kompromittierte Images."

Schlechte Antwort: "Wir pruefen gegen den CIS Benchmark und scannen Ihre Images."

2. "Wie priorisieren Sie Findings?"

Gute Antwort: "Nach Ausnutzbarkeit in Ihrer konkreten Umgebung. Ein CVSS 9.8 in einem isolierten Pod ist weniger relevant als ein CVSS 6.5 mit direktem Weg zu Ihren Datenbanken."

Schlechte Antwort: "Nach CVSS-Score. Critical zuerst, dann High, dann Medium."

3. "Koennen Sie ein Beispiel fuer eine Angriffskette zeigen?"

Gute Antwort: Der Pruefer beschreibt eine mehrstufige Attacke aus einem frueheren Engagement (anonymisiert). Zum Beispiel: "Wir sind ueber eine SSRF-Luecke in den Cluster gekommen, haben den ServiceAccount-Token extrahiert und konnten damit alle Secrets im Namespace lesen."

Schlechte Antwort: "Das koennen wir erst nach dem Audit sagen."

4. "Wer fuehrt den Test durch?"

Gute Antwort: Namentliche Nennung des Testers, Kubernetes-spezifische Zertifizierungen (CKS, OSCP/OSEP mit K8s-Erfahrung), Referenzen.

Schlechte Antwort: "Unser Team." (Koennte der Junior sein, der letzte Woche angefangen hat.)

5. "Was passiert, wenn wir die Findings behoben haben?"

Gute Antwort: "Im Retest pruefen wir, ob die Behebung wirksam ist und keine neuen Schwachstellen eingefuehrt wurden. Das ist im Preis enthalten."

Schlechte Antwort: "Dann bestellen Sie einen neuen Audit." (Kaching.)

Was ein Kubernetes-Pentest kosten sollte

Preisrahmen

Was fuer den Preis enthalten sein sollte

Minimum-Scope fuer einen sinnvollen Kubernetes-Pentest:

├── RBAC und ServiceAccount-Analyse
├── Network Policy Validation (Lateral Movement)
├── Container Image Security (ueber CVE-Scan hinaus)
├── Secrets Management (Wie werden Secrets gespeichert?)
├── Ingress/Egress-Analyse
├── Pod Security Standards Pruefung
├── Supply Chain (Container Registry, CI/CD Pipeline)
├── Dokumentierter Bericht mit Angriffsketten
├── Management Summary (fuer Nicht-Techniker)
├── Priorisierte Massnahmen (Top 5 zuerst)
└── Retest nach Behebung

Wenn ein Anbieter deutlich unter 8.000 EUR liegt, bekommen Sie wahrscheinlich einen automatisierten Scan mit huebschem Report. Das kann nuetzlich sein, ist aber kein Pentest.

Mehr zur Security-Automatisierung, die Sie selbst umsetzen koennen, finden Sie im Security-Scanning-Guide.

Grosse Beratungshaeuser vs. spezialisierte Pentester

Die grossen Wirtschaftspruefungshaeuser bieten Kubernetes-Security-Audits an. Der Name wirkt vertrauenswuerdig im Compliance-Ordner. Aber: Die Senior-Spezialisten schreiben das Angebot, die Junior-Consultants fuehren den Audit durch. Sie zahlen den Overhead einer globalen Organisation fuer standardisierte Checklisten.

Wann Big Four sinnvoll sind: SOC-2-Reports und ISO-27001-Zertifizierungen, bei denen der Name des Pruefhauses entscheidend ist. Verwechseln Sie das aber nicht mit einem Pentest -- fuer echte Angriffsszenarien brauchen Sie spezialisierte Kubernetes-Security-Tester.

Der bessere Ansatz: Security als Teil des Betriebs

Die eigentliche Frage ist nicht "Welchen Pentester buchen wir?", sondern "Wie bauen wir Security in den laufenden Betrieb ein?"

Ein Pentest ist eine Momentaufnahme. Am Tag nach dem Test deployen Ihre Entwickler neuen Code, aendern RBAC-Regeln und fuegen Namespaces hinzu. Die Ergebnisse veralten sofort.

Continuous Security statt jaehrlichem Audit

Jaehrlicher Pentest:
├── Monat 1: Audit (25.000 EUR)
├── Monat 2-3: Findings beheben
├── Monat 4-12: Keine Pruefung
│   (Neue Schwachstellen entstehen unbemerkt)
└── Monat 13: Naechster Audit
    ("Die Haelfte der alten Findings ist wieder da")

Continuous Security (Managed):
├── Taeglich: Image Scanning in CI/CD Pipeline
├── Taeglich: Policy Enforcement via Kyverno/OPA
├── Woechentlich: kube-bench CIS Benchmark
├── Monatlich: RBAC-Review
├── Quartalsweise: Manueller Security Review
└── Jaehrlich: Externer Pentest (als Validierung)

Der jaehrliche Pentest wird zum Validierungsinstrument statt zur einzigen Security-Massnahme. Und die Findings fallen drastisch geringer aus, weil die Basis bereits stimmt.

Wie Sie Policy-as-Code fuer Continuous Compliance einsetzen, beschreibt unser Compliance-Automatisierungs-Guide.

Was ein Managed Kubernetes Service abdeckt

Ein guter Managed Kubernetes Partner liefert Security als integralen Bestandteil des Betriebs:

Das macht den jaehrlichen Pentest nicht ueberfluessig, aber es macht ihn produktiver: Der Pruefer findet die wirklich subtilen Schwachstellen, statt seine Zeit mit fehlenden Network Policies zu verschwenden.

Mehr zum Thema Security-Automatisierung finden Sie im Runtime Security Guide.

Kurzcheck: Pentester auswaehlen

Must-Have: Kubernetes-spezifische Erfahrung, namentlich benannte Tester, Cluster-Zugriff als Voraussetzung, Mindestdauer 2 Wochen, Retest enthalten, Angriffsketten im Beispiel-Bericht.

Ausschlusskriterien: "Wir brauchen keinen Cluster-Zugriff", Ergebnis in unter 5 Tagen versprochen, nur automatisierte Scans im Scope, kein Retest im Angebot.

Fazit: Zahlen Sie fuer Sicherheit, nicht fuer Papier

Der Unterschied zwischen einem echten Pentest und Compliance-Theater ist der Unterschied zwischen "Wir wissen, wo ein Angreifer eindringen koennte" und "Wir haben ein Dokument, das sagt, wir haetten 247 Findings beheben sollen."

Fuer mittelstaendische IT-Leiter ist die Empfehlung klar:

1. Bauen Sie Continuous Security in den Betrieb ein -- ueber Policy-as-Code, automatisierte Scans und Managed Services.
2. Beauftragen Sie einen echten Pentest als Validierung, nicht als primaere Security-Massnahme.
3. Stellen Sie die richtigen Fragen, bevor Sie einen Auditor beauftragen.

Ein guter Pentest zeigt Ihnen fuenf Dinge, die Ihre automatisierten Tools nicht finden. Ein schlechter Pentest zeigt Ihnen 247 Dinge, die Sie schon wussten. Der Preisunterschied ist gering. Der Wertunterschied ist enorm.

Verwandte Artikel

• Kubernetes Security Scanning automatisiert umsetzen
• Kubernetes Compliance ohne Vollzeit-Security-Team
• Kubernetes Compliance-Automatisierung
• Kubernetes Runtime Security im Praxiseinsatz
• NIS2-Audit bestehen: Die Checkliste

Sie wollen wissen, wie sicher Ihre Kubernetes-Infrastruktur wirklich ist -- nicht nur auf dem Papier? Wir verbinden Managed Kubernetes mit echter Security-Expertise und helfen Ihnen, den richtigen Pentester auszuwaehlen. Sprechen Sie uns an.