Kubernetes-Security: Die 7 häufigsten Fehlkonfigurationen in Produktivsystemen

1 Min. Lesezeit

Kubernetes ist zum De-facto-Standard für Container-Orchestrierung geworden. Doch die Komplexität des Systems erzeugt eine enorme Angriffsfläche: Fehlkonfigurierte RBAC-Policies, exponierte API-Server und privilegierte Container sind in Produktionsumgebungen eher die Regel als die Ausnahme. Sieben Fehler, die sich sofort beheben lassen.

Das Wichtigste in Kürze

NSA/CISA: „Fehlkonfiguration ist die häufigste Schwachstelle in Kubernetes“
Über 380.000 öffentlich erreichbare Kubernetes-API-Server (Shadowserver 2024)
Red Hat Report: 67 Prozent der Unternehmen hatten Security-Incident in K8s
Die meisten Schwachstellen sind Konfigurationsfehler – nicht Software-Bugs

1-2: API-Server-Exposition und fehlende RBAC

Fehler 1: API-Server öffentlich erreichbar. Der Kubernetes API-Server ist das Gehirn des Clusters. Wer Zugriff hat, kontrolliert alles. Trotzdem finden Scanner wie Shodan hunderttausende öffentlich erreichbare API-Server. Lösung: API-Server ausschließlich über VPN oder Private Endpoint erreichbar machen.

Fehler 2: Überprivilegierte RBAC-Rollen. cluster-admin für jeden Entwickler, weil es „einfacher“ ist. Das Least-Privilege-Prinzip wird in Kubernetes oft ignoriert. Lösung: Namespace-spezifische Roles statt ClusterRoles, regelmäßige RBAC-Audits mit Tools wie rbac-police oder kubectl-who-can.

3-4: Privilegierte Container und fehlende Network Policies

Fehler 3: Privilegierte Container. Containers, die als root laufen oder das privileged-Flag gesetzt haben, können auf das Host-System ausbrechen. Ein Container-Escape gibt dem Angreifer Zugriff auf den gesamten Node. Lösung: SecurityContext mit runAsNonRoot, readOnlyRootFilesystem und Drop aller Linux Capabilities.

Fehler 4: Keine Network Policies. Ohne Network Policies kann jeder Pod mit jedem anderen Pod kommunizieren. Lateral Movement innerhalb des Clusters ist trivial. Lösung: Default-Deny-Policy für alle Namespaces, dann explizite Allow-Rules für benötigte Kommunikation.

5-6: Secrets im Klartext und veraltete Images

Fehler 5: Secrets als Base64 in etcd. Kubernetes Secrets sind nur Base64-kodiert, nicht verschlüsselt. Wer Zugriff auf etcd hat, liest alle Secrets im Klartext. Lösung: Encryption at Rest für etcd aktivieren oder externe Secret-Management-Lösungen (Vault, AWS Secrets Manager, Azure Key Vault) nutzen.

Fehler 6: Veraltete Container-Images. Images mit bekannten CVEs laufen monatelang in Produktion, weil niemand sie scannt. Lösung: Image Scanning in der CI/CD-Pipeline (Trivy, Snyk Container) und Admission Controller (OPA Gatekeeper, Kyverno), die unsichere Images blockieren.

7: Fehlende Pod Security Standards

Fehler 7: Keine Pod Security Standards/Admission. Seit Kubernetes 1.25 sind Pod Security Standards (PSS) der offizielle Nachfolger von PodSecurityPolicy. Drei Level: Privileged (alles erlaubt), Baseline (bekannte Eskalationsvektoren blockiert), Restricted (Best Practice). Viele Cluster laufen noch ohne jede Einschränkung.

Lösung: PSS im „Warn“-Modus aktivieren, Violations identifizieren und beheben, dann auf „Enforce“ umstellen. Für komplexere Policies: OPA Gatekeeper oder Kyverno als Admission Controller.

Key Facts

Exponierte API-Server: 380.000+ öffentlich erreichbar (Shadowserver Foundation)

Security Incidents: 67 Prozent der K8s-Nutzer hatten einen Vorfall (Red Hat 2024)

Image-Schwachstellen: Durchschnittlich 72 bekannte CVEs pro Container-Image (Sysdig 2024)

Häufige Fragen

Wie prüfe ich mein Cluster auf Fehlkonfigurationen?

Tools: kube-bench (CIS Benchmark Check), kubescape (NSA/CISA Hardening Guide), Trivy (Image + Config Scanning), rbac-police (RBAC-Audit). Alle Open Source und in Minuten einsatzbereit.

Reicht ein Managed Kubernetes (EKS, AKS, GKE)?

Managed K8s reduziert die Angriffsfläche der Control Plane, aber die Workload-Konfiguration (RBAC, Network Policies, Pod Security) bleibt in der Verantwortung des Nutzers. Die meisten der genannten Fehler betreffen genau diesen Bereich.

Was ist der schnellste Quick Win?

Network Policies mit Default-Deny. In den meisten Clustern ist Pod-zu-Pod-Kommunikation komplett uneingeschränkt. Eine einzige Default-Deny-Policy pro Namespace blockiert Lateral Movement sofort – mit minimalem Aufwand.