Ein einziger privilegierter Container reicht aus, um ein gesamtes Kubernetes-Cluster zu übernehmen — und damit potenziell alle darauf laufenden Anwendungen und Daten.
Container Escape — vom isolierten Prozess zum Host-Root
Container sind keine Virtualisierung — sie teilen sich den Kernel des Host-Systems. Die Isolation basiert auf Linux-Kernel-Features: Namespaces (PID, Network, Mount, UTS, IPC, User, Cgroup) trennen die Sichtbarkeit von Ressourcen, und Cgroups begrenzen den Ressourcenverbrauch. Seccomp-Profile filtern Systemaufrufe, und AppArmor/SELinux-Profile schränken Dateizugriffe ein. Aber: Wenn ein Container als privileged läuft (--privileged bei Docker, securityContext.privileged: true bei Kubernetes), werden alle diese Schutzmechanismen deaktiviert. Der Container hat dann vollen Zugriff auf den Host-Kernel, alle Geräte (/dev), alle Capabilities und kann den Host vollständig übernehmen.
Der klassische Container-Escape über einen privilegierten Container ist erschreckend einfach: mkdir /mnt/host && mount /dev/sda1 /mnt/host && chroot /mnt/host — damit mountet der Angreifer das Host-Root-Dateisystem und hat eine Root-Shell auf dem Host. Aber auch nicht-privilegierte Container können verwundbar sein, wenn bestimmte Capabilities vergeben werden: CAP_SYS_ADMIN ermöglicht das Mounten von Dateisystemen (→ cgroup-basierter Escape via release_agent), CAP_SYS_PTRACE erlaubt das Debuggen von Host-Prozessen, CAP_NET_RAW ermöglicht Netzwerk-Sniffing und ARP-Spoofing im Host-Netzwerk. Der berüchtigte CVE-2022-0185 (Linux Kernel Heap Overflow in der File-System-Context-Verarbeitung) ermöglichte einen Container-Escape selbst ohne erhöhte Capabilities — allein über einen unvollständigen Namespace.
- Docker Socket Escape: Wenn der Docker-Socket (
/var/run/docker.sock) in einen Container gemountet wird (häufig für CI/CD-Pipelines oder Monitoring), kann der Angreifer beliebige Container auf dem Host starten — inklusive privilegierter Container.docker -H unix:///var/run/docker.sock run -v /:/mnt --privileged -it alpine chroot /mntgibt sofort Root auf dem Host. Alternatives Muster: Starten eines neuen Containers im Host-PID/Network-Namespace. - Cgroup Release Agent Escape (CVE-2022-0492): Container mit
CAP_SYS_ADMINund beschreibbarem cgroupfs können denrelease_agent-Mechanismus missbrauchen: Erstelle eine neue Cgroup, setzerelease_agentauf ein Skript im Host-Dateisystem, und triggere den Agent durch Beenden des letzten Prozesses in der Cgroup. Das Skript wird als Root auf dem Host ausgeführt. - Kernel-Exploit Escape: Da Container den Host-Kernel teilen, betrifft jede Kernel-Schwachstelle potenziell alle Container auf dem Host. Bekannte Escapes: Dirty Pipe (CVE-2022-0847) — überschreibt beliebige Read-Only-Dateien, einschließlich Host-Dateien über ProcFS. Dirty COW (CVE-2016-5195) — Race Condition im Memory-Management. Verteidigung: Kernel Live-Patching (kpatch/livepatch) und gVisor/Kata Containers (Kernel-Isolation).
- Sensitive Volume Mounts erkennen:
kubectl get pods -A -o json | jq '.items[] | select(.spec.volumes[]?.hostPath) | {name: .metadata.name, ns: .metadata.namespace, paths: [.spec.volumes[] | select(.hostPath) | .hostPath.path]}'— listet alle Pods mit Host-Path-Mounts. Kritische Pfade:/,/etc,/var/run/docker.sock,/proc,/sys. Jeder dieser Mounts ist ein potenzieller Escape-Vektor.
Kubernetes-Angriffsvektoren — vom Pod zum Cluster-Admin
Der Kubernetes API-Server ist das zentrale Nervensystem des Clusters und lauscht standardmäßig auf TCP 6443. Wenn der API-Server Anonymous Authentication erlaubt (Standard in vielen älteren Installationen), kann ein Angreifer ohne Credentials Cluster-Informationen abfragen: curl -k https://api-server:6443/api/v1/namespaces. Schlimmer: Wenn die system:anonymous-ClusterRoleBinding Rechte hat (in manchen Managed-Kubernetes-Setups der Fall), kann der Angreifer Pods erstellen, Secrets lesen oder sogar kubectl exec in laufende Container ausführen. Der prominenteste Fall: Tesla (2018) — ein exponiertes Kubernetes-Dashboard ohne Authentifizierung ermöglichte Cryptomining im Tesla-Cluster.
RBAC-Fehlkonfigurationen sind der häufigste Kubernetes-Angriffsvektor. Das Problem liegt oft in übermäßig breiten ClusterRoleBindings: Eine Service-Account-Rolle mit verbs: ["*"], resources: ["*"] gibt dem Pod effektiv Cluster-Admin-Rechte. Besonders gefährlich sind die Rechte create pods (Angreifer startet privilegierten Pod), get secrets (liest alle Kubernetes-Secrets inklusive TLS-Zertifikaten und Datenbankpasswörtern) und create/patch clusterrolebindings (Angreifer gibt sich selbst Cluster-Admin). Das Tool rbac-police und kubectl-who-can identifizieren diese überprivilegierten Rollen.
- Service Account Token Theft: Jeder Pod erhält standardmäßig ein Service Account Token unter
/var/run/secrets/kubernetes.io/serviceaccount/token. Dieses JWT-Token authentifiziert den Pod gegen den API-Server. Ein Angreifer im Pod kann damit alle Aktionen ausführen, die dem Service Account erlaubt sind. Ab Kubernetes 1.24+ sind projizierte Tokens mit Ablaufzeit Standard — ältere Cluster verwenden noch langlebige Secrets. Deaktivieren mit:automountServiceAccountToken: falsein der Pod-Spec. - ETCD-Direktzugriff: etcd (TCP 2379/2380) ist die Key-Value-Datenbank, in der Kubernetes alle Cluster-Daten speichert — inklusive aller Secrets im Klartext (Base64 ist keine Verschlüsselung!). Wenn etcd ohne TLS-Client-Authentifizierung exponiert ist:
etcdctl --endpoints=http://etcd:2379 get /registry/secrets --prefix --keys-onlylistet alle Secrets. Verteidigung: etcd nur über localhost oder über mTLS erreichbar machen, EncryptionConfiguration für Secrets-at-Rest aktivieren. - Metadata Service Exploitation: In Cloud-Umgebungen (AWS, GCP, Azure) kann ein Pod auf den Instance Metadata Service (IMDS) zugreifen:
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/liefert temporäre IAM-Credentials der Node-Instanz. Mit diesen Credentials kann der Angreifer Cloud-Ressourcen außerhalb des Clusters kontrollieren. Verteidigung: IMDSv2 (AWS, erfordert Session-Token), Network Policies die Zugriff auf 169.254.169.254 blockieren, oder Pod Identity (EKS Pod Identity / GKE Workload Identity). - Supply-Chain-Angriff über Container Images: Ein kompromittiertes Base-Image (z. B. ein öffentliches Image von Docker Hub mit eingebettetem Cryptominer) infiziert alle darauf basierenden Container. Verteidigung: Trivy / Grype für Image-Scanning in der CI/CD-Pipeline, Cosign (Sigstore) für Image-Signaturvalidierung, Admission Controller (OPA Gatekeeper oder Kyverno) der unsignierte oder verwundbare Images blockiert. Policy-Beispiel:
Nur Images aus der internen Registry erlauben + keine Images mit Critical-CVEs.
Cluster-Härtung — Defense in Depth für Kubernetes
Die wichtigste Härtungsmaßnahme ist die Implementierung von Pod Security Standards (PSS), dem Nachfolger der veralteten PodSecurityPolicies (PSP, entfernt in K8s 1.25). PSS definiert drei Profile: Privileged (keine Einschränkungen), Baseline (verhindert bekannte Privilege-Escalations) und Restricted (Best Practice mit minimalen Rechten). Die Durchsetzung erfolgt über den Pod Security Admission Controller: kubectl label namespace production pod-security.kubernetes.io/enforce=restricted. Im Restricted-Profil müssen alle Container als Non-Root laufen (runAsNonRoot: true), dürfen keine Capabilities anfordern (außer NET_BIND_SERVICE), müssen ein Read-Only Root Filesystem verwenden und dürfen keine hostPath-Volumes mounten.
Network Policies sind die Kubernetes-native Mikrosegmentierung — und werden in über 90 % aller Cluster nicht verwendet. Standardmäßig kann jeder Pod mit jedem anderen Pod im Cluster kommunizieren — ein kompromittierter Frontend-Pod kann direkt die Datenbank kontaktieren. Network Policies definieren Ingress- und Egress-Regeln auf Pod-Ebene, basierend auf Labels und Namespaces. Voraussetzung: Ein CNI-Plugin, das Network Policies unterstützt (Calico, Cilium, Antrea — nicht Flannel!). Best Practice: Starten Sie mit einer Default-Deny-Policy pro Namespace und erlauben Sie dann gezielt die benötigten Verbindungen.
- Falco für Runtime-Detection: Falco (CNCF Graduated Project) überwacht Systemaufrufe in Echtzeit und erkennt anomales Verhalten: Shell-Zugriff in Containern (
kubectl exec), Dateizugriffe auf sensible Pfade (/etc/shadow), Netzwerkverbindungen zu unerwarteten Zielen, Prozess-Spawning (z. B. Cryptominer). Deployment als DaemonSet auf allen Nodes. Falco-Regeln sind YAML-basiert und leicht anpassbar. - OPA/Gatekeeper Admission Control: Open Policy Agent (OPA) mit Gatekeeper erzwingt Policies bei der Pod-Erstellung. Beispiel-Policies: Keine Container als Root, keine Images von Docker Hub, keine hostPath-Mounts, alle Container müssen Resource-Limits haben, keine
latest-Tags. Alternative: Kyverno — nativ in Kubernetes, einfacher zu konfigurieren als OPA/Rego. - Secrets-Management: Kubernetes-Secrets sind nur Base64-kodiert, nicht verschlüsselt. Alternativen: HashiCorp Vault mit dem Vault Secrets Operator (injiziert Secrets direkt in Pods), External Secrets Operator (synchronisiert Secrets aus AWS Secrets Manager, Azure Key Vault), Sealed Secrets (Bitnami — verschlüsselte Secrets, die sicher in Git gespeichert werden können). Für etcd-at-rest:
EncryptionConfigurationmitaescbcodersecretboxProvider. - CIS Kubernetes Benchmark automatisieren:
kube-bench(Aqua Security, Open Source) prüft Ihr Cluster automatisch gegen den CIS Kubernetes Benchmark: API-Server-Konfiguration, etcd-Sicherheit, kubelet-Härtung, RBAC-Konfiguration.kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml && kubectl logs job/kube-bench. Ziel: Alle Checks bestanden oder bewusst akzeptierte Ausnahmen dokumentiert.
Sie benötigen Unterstützung?
Container-Sicherheit erfordert Expertise auf mehreren Ebenen — vom Image-Build über die Runtime bis zur Cluster-Konfiguration. Wir auditieren Ihre Kubernetes-Umgebung, implementieren Pod Security Standards, Network Policies und Runtime-Detection mit Falco.
Cloud & Azure ansehen →
