Kubernetes Penetration Testing: Schwachstellen systematisch aufdecken

TL;DR

• Kubernetes-Cluster haben spezifische Angriffsvektoren, die klassische Netzwerk-Pentests nicht abdecken: API-Server, etcd, Kubelet, RBAC-Fehlkonfigurationen und fehlende Network Policies.
• Automatisierte Tools wie kube-hunter und kube-bench liefern eine solide Basis, ersetzen aber nicht die manuelle Analyse von RBAC-Bindings und Pod Security Standards.
• Die drei haeufigsten Schwachstellen in der Praxis: zu weitreichende ClusterRoleBindings, fehlende Network Policies im default Namespace und unverschluesselte etcd-Daten.
• Ein sinnvoller Testzyklus kombiniert quartalsweises automatisiertes Scanning mit jaehrlichem manuellem Pen-Test.
• Container-Escapes sind realer als viele annehmen -- besonders bei privilegierten Containern und gemounteten Host-Pfaden.

Warum Kubernetes-spezifische Pen-Tests notwendig sind

Klassische Infrastruktur-Pentests pruefen Netzwerke, Firewalls und Betriebssysteme. Ein Kubernetes-Cluster bringt jedoch eine eigene Abstraktionsschicht mit, die voellig neue Angriffsvektoren eroeffnet. Der API-Server ist das zentrale Eingangstor. RBAC regelt, wer was darf. Network Policies kontrollieren die Pod-zu-Pod-Kommunikation. Und etcd speichert den gesamten Cluster-State inklusive Secrets im Klartext, sofern keine Verschluesselung konfiguriert ist.

Ein klassischer Netzwerk-Scanner sieht von all dem nichts. Er erkennt vielleicht einen offenen Port 6443, aber nicht, dass anonyme Anfragen am API-Server erlaubt sind oder dass ein ServiceAccount im default Namespace cluster-admin Rechte hat.

Genau hier setzt Kubernetes-spezifisches Penetration Testing an. Es prueft die Kubernetes-eigenen Sicherheitsmechanismen und simuliert Angriffe, die ein Angreifer nach initialem Zugriff auf einen Pod ausfuehren wuerde.

Die wichtigsten Angriffsvektoren

API-Server Exposition

Der API-Server ist das primaere Ziel. Wenn er oeffentlich erreichbar ist oder anonyme Authentifizierung erlaubt, hat ein Angreifer direkten Zugriff auf den Cluster-State. Pruefen Sie als erstes:

# Anonymen Zugriff testen
curl -k https://CLUSTER-IP:6443/api/v1/namespaces

# API-Server Discovery
curl -k https://CLUSTER-IP:6443/version

# Pruefen ob Kubelet Read-Only Port offen ist (sollte deaktiviert sein)
curl http://NODE-IP:10255/pods

# ServiceAccount Token aus einem Pod heraus nutzen
TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
curl -k -H "Authorization: Bearer $TOKEN" \
  https://kubernetes.default.svc/api/v1/namespaces

Wenn der letzte Befehl aus einem kompromittierten Pod heraus Namespace-Informationen zurueckgibt, hat der zugehoerige ServiceAccount zu weitreichende Rechte.

RBAC-Fehlkonfigurationen

RBAC ist das Berechtigungssystem in Kubernetes. In der Praxis sieht man haeufig, dass Convenience ueber Sicherheit gestellt wird. Ein typisches Anti-Pattern ist eine ClusterRoleBinding, die dem default ServiceAccount umfassende Rechte gibt:

# ANTI-PATTERN: Zu weitreichende Berechtigungen
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: permissive-binding
subjects:
- kind: ServiceAccount
  name: default
  namespace: default
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io
---
# BESSER: Minimale Berechtigungen pro Anwendung
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: app-reader
  namespace: production
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["get", "list"]
- apiGroups: [""]
  resources: ["secrets"]
  resourceNames: ["app-config"]
  verbs: ["get"]

Der Unterschied ist erheblich: Im ersten Fall kann jeder Pod im default Namespace den gesamten Cluster kontrollieren. Im zweiten Fall kann die Anwendung nur eine spezifische ConfigMap und ein benanntes Secret lesen.

Network Policy Luecken

Ohne Network Policies kann jeder Pod mit jedem anderen Pod kommunizieren -- ueber Namespace-Grenzen hinweg. Das ist das Standardverhalten und wird in vielen Clustern nie geaendert. Fuer einen Angreifer, der einen Pod kompromittiert hat, bedeutet das freie laterale Bewegung.

# Default-Deny Policy als Grundlage fuer jedes Namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
---
# Gezielt erlauben: Nur Frontend darf Backend erreichen
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080

Starten Sie immer mit einer Default-Deny-Policy und oeffnen Sie dann gezielt die benoetigten Kommunikationspfade. Ein Pen-Test deckt auf, ob Pods Verbindungen aufbauen koennen, die nicht vorgesehen sind.

Toolchain fuer automatisiertes Scanning

Bevor Sie manuell testen, liefern automatisierte Tools eine Baseline. Die folgende Tabelle zeigt die relevantesten Werkzeuge im Vergleich:

Ein sinnvoller Workflow sieht so aus:

# 1. CIS Benchmark pruefen
kube-bench run --targets=master,node

# 2. Aktive Schwachstellensuche im Cluster
kube-hunter --remote CLUSTER-IP --active

# 3. Alle Container-Images im Cluster scannen
kubectl get pods --all-namespaces \
  -o jsonpath='{range .items[*]}{.spec.containers[*].image}{"\n"}{end}' \
  | sort -u \
  | xargs -I {} trivy image --severity HIGH,CRITICAL {}

# 4. RBAC-Berechtigungen analysieren
kubectl auth can-i --list --as=system:serviceaccount:default:default
kubectl get clusterrolebindings -o json | \
  jq '.items[] | select(.roleRef.name=="cluster-admin") | .subjects'

Der letzte Befehl ist besonders aufschlussreich: Er zeigt alle Subjects, die cluster-admin Rechte haben. In einem gehaerteten Cluster sollte diese Liste sehr kurz sein.

Systematisches Vorgehen in vier Phasen

Phase 1: Reconnaissance (Woche 1)

Erfassen Sie den Ist-Zustand. Welche Kubernetes-Version laeuft? Welche Nodes sind vorhanden? Welche Namespaces existieren? Welche Services sind nach aussen exponiert? Diese Phase ist rein passiv und verschafft Ihnen den Ueberblick.

Phase 2: Automatisiertes Scanning (Woche 2)

Fuehren Sie die oben beschriebene Toolchain aus. Dokumentieren Sie alle Findings mit Schweregrad. Typische Ergebnisse: veraltete Images mit bekannten CVEs, fehlende Pod Security Standards, zu offene RBAC-Bindings, fehlende Network Policies.

Phase 3: Manuelles Testing (Woche 3-4)

Hier beginnt die eigentliche Arbeit. Versuchen Sie aus einem kompromittierten Pod heraus:

• Auf den API-Server zuzugreifen und Rechte zu eskalieren
• Andere Pods im selben und in anderen Namespaces zu erreichen
• Secrets aus etcd oder ueber die API auszulesen
• Aus dem Container auf den Host auszubrechen (Container Escape)
• Die CI/CD-Pipeline zu manipulieren (Supply Chain Attack)

Phase 4: Reporting und Remediation (Woche 5-6)

Dokumentieren Sie jedes Finding mit Reproduktionsschritten, Schweregrad, Business Impact und konkreter Remediation-Empfehlung. Priorisieren Sie nach Risiko: Ein exponierter API-Server mit anonymem Zugriff hat Vorrang vor einem veralteten Image mit niedrigem CVSS-Score.

Pod Security Standards: Die oft vergessene Verteidigungslinie

Seit Kubernetes 1.25 ist PodSecurityPolicy entfernt. Der Nachfolger sind Pod Security Standards mit drei Profilen: Privileged, Baseline und Restricted. Viele Cluster laufen noch ohne Enforcement, weil die Migration als aufwaendig gilt.

Ein Pen-Test sollte explizit pruefen, ob privilegierte Container erstellt werden koennen:

# Pruefen ob privilegierte Pods erstellt werden koennen
kubectl run test-priv --image=alpine --restart=Never \
  --overrides='{
    "spec": {
      "containers": [{
        "name": "test",
        "image": "alpine",
        "securityContext": {"privileged": true}
      }]
    }
  }' -- sleep 3600

# Wenn dieser Pod startet, fehlt Pod Security Enforcement
kubectl get pod test-priv

# Aufraeumen
kubectl delete pod test-priv

Wenn dieser Pod ohne Fehler startet, ist keine wirksame Admission Control aktiv. Das ist ein kritisches Finding.

Typische Findings und ihre Behebung

Wie oft testen?

Die richtige Frequenz haengt von der Kritikalitaet ab. Als Faustregel:

• Automatisiertes Scanning (kube-bench, Trivy): In die CI/CD-Pipeline integrieren, bei jedem Deployment
• Umfassendes automatisiertes Assessment: Quartalsweise
• Manueller Penetration Test: Jaehrlich oder nach groesseren Architektur-Aenderungen
• Nach Kubernetes-Upgrades: Immer ein fokussiertes Assessment durchfuehren

Die Kombination aus kontinuierlichem Scanning und periodischem manuellem Testing gibt Ihnen die beste Abdeckung. Automatisierung faengt die bekannten Probleme, manuelle Tests finden die Konfigurationsfehler und Logikluecken.

Weitergehende Absicherung

Penetration Testing ist ein Baustein einer umfassenden Sicherheitsstrategie. Fuer die Absicherung im laufenden Betrieb ist Runtime Security mit Falco und Tetragon eine sinnvolle Ergaenzung, da sie Angriffe in Echtzeit erkennt.

Die Ergebnisse des Pen-Tests sollten auch in Ihre Verschluesselungsstrategie einfliessen -- insbesondere wenn unverschluesselte Secrets oder etcd-Daten gefunden werden.

Fuer den produktiven Betrieb gehaerteter Cluster liefert unser Artikel zum Kubernetes Cluster Setup fuer Production konkrete Konfigurationsbeispiele. Und fuer eine systematische Haertung nach CIS-Benchmark empfehlen wir die Security Hardening Checkliste.

Wenn Sie Kubernetes-Workloads unter DSGVO-Anforderungen betreiben, ist ein dokumentierter Pen-Test auch ein wirksamer Nachweis fuer technisch-organisatorische Massnahmen nach Art. 32 DSGVO. Mehr zu Compliance-Themen finden Sie in unserem DSGVO-Compliance-Guide.

Wenn Sie Unterstuetzung bei der Planung oder Durchfuehrung eines Kubernetes Security Assessments benoetigen, sprechen Sie uns an unter /kontakt. Wir fuehren sowohl automatisierte Audits als auch manuelle Pen-Tests fuer Kubernetes-Umgebungen durch.