Kubernetes Penetration Testing: Praxis-Anleitung

TL;DR

Kubernetes-Penetrationstests prüfen Ihren Cluster auf reale Angriffsvektoren: exponierte API-Server, überprivilegierte RBAC-Rollen, unsichere Pod-Konfigurationen und erreichbare etcd-Instanzen. Tools wie kube-hunter (Netzwerk-Scan), kubeaudit (Config-Audit) und kubectl-who-can (RBAC-Analyse) automatisieren die wichtigsten Checks. Führen Sie diese Tests nur auf eigenen Clustern und mit schriftlicher Genehmigung durch.

Wichtig: Führen Sie Penetrationstests ausschließlich auf Clustern durch, für die Sie eine schriftliche Genehmigung haben. Unautorisierte Tests sind nach § 202a StGB (Ausspähen von Daten) strafbar. Bei Managed Kubernetes (EKS, AKS, GKE) benötigen Sie zusätzlich die Genehmigung des Cloud-Providers.

Kubernetes-Cluster sind komplexe Systeme mit vielen Angriffsflächen. Ein regelmäßiger Sicherheitstest hilft, Fehlkonfigurationen zu finden, bevor es Angreifer tun. Dieser Guide zeigt die Methodik und die wichtigsten Tools.

# Erster Check: Ist der API-Server von außen erreichbar?
# Nur auf eigenen Systemen ausführen!
curl -sk https://<cluster-ip>:6443/api/v1 | head -20
# Erwartung: 401 Unauthorized (nicht 200 OK oder Versionsinformationen)

Phase 1: Reconnaissance

Bevor Sie gezielt testen, verschaffen Sie sich einen Überblick über die Angriffsfläche.

API-Server-Exposition prüfen

# Prüfen, ob anonyme Authentifizierung aktiv ist
kubectl auth can-i --list --as=system:anonymous

# API-Server-Version und Features abfragen
kubectl version --short
kubectl api-resources | wc -l

# Offene Ports auf Master-Nodes scannen (nur eigene Infrastruktur!)
nmap -sT -p 2379,6443,10250,10251,10252 <master-node-ip>
# 2379  = etcd (darf NICHT extern erreichbar sein)
# 6443  = API-Server
# 10250 = Kubelet API (kritisch wenn unauthentifiziert)

RBAC-Enumeration

Überprivilegierte ServiceAccounts sind der häufigste Angriffsvektor in Kubernetes-Clustern.

# Welche ServiceAccounts haben cluster-admin-Rechte?
kubectl get clusterrolebindings -o json | \
  jq -r '.items[] | select(.roleRef.name=="cluster-admin") |
  .subjects[]? | "\(.kind): \(.name) (ns: \(.namespace // "cluster-wide"))"'

# kubectl-who-can: Wer darf Secrets lesen?
kubectl-who-can get secrets --all-namespaces

# Wer darf Pods erstellen? (potenziell gefährlich)
kubectl-who-can create pods -n default

# Wer darf exec in Pods ausführen?
kubectl-who-can create pods/exec --all-namespaces

Phase 2: Automatisierte Scans

kube-hunter: Netzwerk-basierter Cluster-Scan

kube-hunter simuliert die Perspektive eines Angreifers und sucht nach Schwachstellen im Netzwerk.

# kube-hunter als Pod im Cluster ausführen
kubectl run kube-hunter --image=aquasec/kube-hunter \
  --restart=Never --rm -it -- \
  --pod --quick

# Alternativ: Remote-Scan von außerhalb
pip install kube-hunter
kube-hunter --remote <cluster-ip>

# Report als JSON für Weiterverarbeitung
kube-hunter --remote <cluster-ip> --report json > kube-hunter-report.json

Typische Findings von kube-hunter:

kubeaudit: Konfigurationsbasierter Audit

kubeaudit prüft Kubernetes-Manifeste und laufende Workloads auf Sicherheitsprobleme.

# Alle Namespaces auf Security-Probleme prüfen
kubeaudit all

# Nur bestimmte Checks ausführen
kubeaudit nonroot     # Container als Root?
kubeaudit privesc     # Privilege Escalation möglich?
kubeaudit rootfs      # Read-Only Filesystem?
kubeaudit capabilities # Unnötige Linux Capabilities?
kubeaudit netpols     # NetworkPolicies vorhanden?

# Manifest vor dem Deployment prüfen
kubeaudit all -f deployment.yaml

Phase 3: Manuelle Tests

Automatisierte Tools finden nicht alles. Diese manuellen Checks decken subtilere Schwachstellen auf.

Privilegierte Pods erkennen

# Pods mit privilegiertem Security Context finden
kubectl get pods -A -o json | \
  jq -r '.items[] | select(
    .spec.containers[].securityContext.privileged == true or
    .spec.initContainers[]?.securityContext.privileged == true
  ) | "\(.metadata.namespace)/\(.metadata.name)"'

# Pods mit hostNetwork, hostPID oder hostIPC
kubectl get pods -A -o json | \
  jq -r '.items[] | select(
    .spec.hostNetwork == true or
    .spec.hostPID == true or
    .spec.hostIPC == true
  ) | "\(.metadata.namespace)/\(.metadata.name)"'

Service Account Token Theft testen

In älteren Kubernetes-Versionen (vor 1.24) werden Tokens automatisch als Secrets erstellt. Selbst in neueren Versionen können projizierte Tokens missbraucht werden, wenn RBAC zu weitreichend ist.

# Prüfen ob default ServiceAccount Token automatisch gemounted wird
kubectl run test-sa --image=busybox --restart=Never -- \
  cat /var/run/secrets/kubernetes.io/serviceaccount/token
kubectl logs test-sa
kubectl delete pod test-sa

# Wenn ein Token existiert: Was kann dieser ServiceAccount?
TOKEN=$(kubectl exec <pod-name> -- \
  cat /var/run/secrets/kubernetes.io/serviceaccount/token)
kubectl auth can-i --list --token=$TOKEN

etcd-Zugriff prüfen

Direkter Zugriff auf etcd bedeutet vollständige Kontrolle über den Cluster - einschließlich aller Secrets im Klartext.

# Prüfen ob etcd-Client-Zertifikate auf Nodes liegen
ls -la /etc/kubernetes/pki/etcd/

# Wenn Zugriff besteht: Secrets im Klartext auslesen
ETCDCTL_API=3 etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  get /registry/secrets --prefix --keys-only | head -20

Wenn das funktioniert, ist etcd Encryption at Rest nicht aktiv. Konfigurieren Sie eine EncryptionConfiguration auf dem API-Server.

Ergebnisse dokumentieren und beheben

Strukturieren Sie Ihre Findings nach Kritikalität:

Führen Sie den Scan nach der Behebung erneut durch und dokumentieren Sie die Ergebnisse. Für BSI-Grundschutz (SYS.1.6.A13) ist ein regelmäßiger Turnus von mindestens einmal jährlich vorgesehen.

FAQ

Brauche ich eine Genehmigung für Penetrationstests?

Ja, immer. Bei eigener Infrastruktur reicht eine interne Freigabe. Bei Managed Kubernetes müssen Sie die Pentest-Policy des Cloud-Providers einhalten. AWS, Azure und Google haben jeweils eigene Genehmigungsprozesse.

Wie oft sollte ich Kubernetes-Pentests durchführen?

Mindestens einmal jährlich und nach jedem größeren Cluster-Upgrade. Automatisierte Scans (kube-hunter, kubeaudit) sollten als Cronjob wöchentlich laufen. Manuelle Tests durch spezialisierte Dienstleister einmal pro Jahr.

Kann ich Pentests in Produktions-Clustern durchführen?

Ja, aber mit Einschränkungen. Passive Scans (kube-hunter im Passive-Modus, kubeaudit, kubectl-who-can) sind sicher. Aktive Tests wie das Erstellen privilegierter Pods sollten Sie in einem separaten Staging-Cluster durchführen.

Was ist der Unterschied zwischen kube-hunter und kube-bench?

kube-hunter simuliert einen Angreifer und sucht nach ausnutzbaren Schwachstellen im Netzwerk. kube-bench prüft die Cluster-Konfiguration gegen den CIS Kubernetes Benchmark. Beides ergänzt sich - kube-bench ist ein Compliance-Check, kube-hunter ist ein aktiver Security-Scan.

Welche Kubernetes-Versionen sind besonders anfällig?

Versionen vor 1.24 haben automatische Secret-basierte ServiceAccount-Tokens, die leichter gestohlen werden können. Versionen vor 1.25 unterstützen noch die veraltete PodSecurityPolicy statt Pod Security Standards. Halten Sie Ihren Cluster immer auf einer unterstützten Version (n-2).