Kubernetes absichern: Die 8 häufigsten Fehlkonfigurationen und wie Sie sie beheben
7 Min. Lesezeit
Ihr DevOps-Team hat den ersten Production-Cluster aufgesetzt, die Microservices laufen, der CISO fragt nach dem Sicherheitskonzept. Die Antwort fällt meistens dünn aus. Denn die meisten Kubernetes-Breaches passieren nicht durch ausgefeilte Zero-Day-Exploits, sondern durch Fehlkonfigurationen, die sich in weniger als einer Stunde beheben lassen. Wer die acht häufigsten Fehler kennt, kann seinen Cluster in fünf Arbeitstagen spürbar härten.
Das Wichtigste in Kürze
- 90 Prozent aller Unternehmen mit Kubernetes-Umgebungen hatten im vergangenen Jahr mindestens einen Sicherheitsvorfall (Red Hat State of Kubernetes Security Report 2024).
- 45 Prozent dieser Vorfälle gehen auf Fehlkonfigurationen zurück, nicht auf Schwachstellen im Code oder gezielte Angriffe.
- Pod Security Standards ersetzen seit Kubernetes 1.25 die veralteten Pod Security Policies und definieren drei verbindliche Sicherheitsstufen.
- 87 Prozent aller Container-Images in Produktion enthalten kritische oder hohe Schwachstellen, weil veraltete Base-Images ohne Prüfung wiederverwendet werden (Sysdig 2025).
- Ein strukturiertes Härtungsprogramm lässt sich mit den acht hier beschriebenen Schritten in fünf Arbeitstagen umsetzen.
Warum Fehlkonfigurationen das größte Kubernetes-Risiko sind
Kubernetes ist komplex. Ein einzelner Cluster bringt mehrere hundert Konfigurationsparameter mit, verteilt über Pods, Services, Network Policies, RBAC-Rollen und Admission Controller. In dieser Komplexität liegt das Risiko: Nicht der Angreifer, der eine neue Schwachstelle ausnutzt, sondern der Administrator, der eine Standardeinstellung übersieht, öffnet das Tor.
Die Zahlen sind eindeutig. Laut dem Red Hat State of Kubernetes Security Report 2024 hatten 90 Prozent aller befragten Unternehmen mit Kubernetes-Umgebungen im vergangenen Jahr mindestens einen Sicherheitsvorfall. 46 Prozent davon berichteten von konkretem Umsatz- oder Kundenverlust als direkte Folge. Und 67 Prozent mussten Deployments verzögern, weil Sicherheitsbedenken den Release blockierten.
Der Treiber hinter diesen Zahlen ist die rasante Verbreitung von Containern in Produktionsumgebungen. Laut der CNCF Annual Survey 2025 setzen mittlerweile 56 Prozent aller Unternehmen Container in der Produktion ein. 2023 waren es noch 41 Prozent. Mit jedem neuen Cluster wächst die Angriffsfläche, wenn grundlegende Sicherheitskonfigurationen nicht von Anfang an gesetzt werden.
90 %
der Unternehmen mit Kubernetes-Umgebungen hatten im vergangenen Jahr mindestens einen Sicherheitsvorfall.
45 %
aller Kubernetes-Sicherheitsvorfälle werden durch Fehlkonfigurationen verursacht.
4,3 Mio. Euro
durchschnittliche Kosten eines Sicherheitsvorfalls durch Cloud-Fehlkonfigurationen, ein Anstieg von 17 Prozent gegenüber dem Vorjahr.
Quellen: Red Hat State of Kubernetes Security Report 2024, IBM Cost of a Data Breach Report 2025
Gartner prognostiziert, dass bis 2026 insgesamt 99 Prozent aller Cloud-Sicherheitsvorfälle auf Fehler der Kunden zurückgehen werden. Nicht die Cloud-Anbieter sind das Problem. Es sind die Teams, die Cluster aufsetzen, ohne die Standardkonfigurationen zu hinterfragen. Die gute Nachricht: Wer die häufigsten Fehlkonfigurationen kennt, kann sie systematisch beseitigen.
Die 8 häufigsten Fehlkonfigurationen und ihre Lösung
Die folgenden acht Fehlkonfigurationen decken den Großteil der realen Angriffsfläche ab. Jede lässt sich gezielt beheben, ohne den laufenden Betrieb zu unterbrechen. Die Reihenfolge orientiert sich am Risiko: Die gefährlichsten Fehlkonfigurationen stehen oben.
Privilegierte Container ohne Einschränkung
Container, die mit dem Flag privileged laufen, haben vollen Zugriff auf den Host-Kernel. Ein Angreifer, der einen solchen Container kompromittiert, kontrolliert den gesamten Node. Lösung: Pod Security Standards auf Baseline oder Restricted setzen. Privilegierte Container nur für System-Workloads wie CNI-Plugins oder Monitoring-Agents erlauben und in dedizierte Namespaces isolieren. Jeder Pod, der ohne Begründung privilegiert läuft, ist ein offenes Tor.
RBAC mit cluster-admin auf Default Service Accounts
Die gefährlichste RBAC-Fehlkonfiguration: Das ClusterRoleBinding cluster-admin wird an den Default Service Account eines Namespace gebunden. Jeder Pod in diesem Namespace erhält damit volle Cluster-Kontrolle. Lösung: Default Service Accounts niemals mit Rollen versehen. Eigene Service Accounts pro Workload erstellen und nach dem Least-Privilege-Prinzip nur die minimal nötigen Berechtigungen zuweisen. Bestehende Bindings regelmäßig auditieren.
Fehlende Network Policies
Ohne Network Policies kann jeder Pod mit jedem anderen Pod im Cluster kommunizieren. Ein kompromittierter Frontend-Pod erreicht direkt die Datenbank. In einem Cluster mit Dutzenden Services bedeutet das: Ein einziger kompromittierter Pod genügt, um lateral durch das gesamte Netzwerk zu navigieren. Lösung: Default-Deny-Policy pro Namespace einrichten. Dann gezielt nur die nötigen Verbindungen freigeben. Beginnen Sie mit den Namespaces, die sensible Daten verarbeiten.
Secrets als Umgebungsvariablen statt verschlüsselt
Kubernetes Secrets sind standardmäßig nur Base64-kodiert, nicht verschlüsselt. Wer Secrets als Umgebungsvariablen in Pods injiziert, riskiert, dass sie in Logs, Crash-Dumps oder Prozesslisten auftauchen. Lösung: Encryption at Rest für etcd aktivieren. Secrets über Volumes statt Umgebungsvariablen einbinden. Für produktionskritische Credentials einen externen Secrets Manager wie HashiCorp Vault, AWS Secrets Manager oder die External Secrets Operator-Integration verwenden.
Container laufen als Root
Viele Container-Images starten Prozesse standardmäßig als Root-User. Bei einem Container-Escape erhält der Angreifer damit Root-Rechte auf dem Host. Das Problem ist weitverbreitet: Viele offizielle Images auf Docker Hub laufen ohne explizite User-Konfiguration als Root. Lösung: Im SecurityContext runAsNonRoot aktivieren und eine explizite User-ID setzen. Base-Images verwenden, die ohne Root funktionieren, etwa die Distroless-Images von Google oder die gehärteten Images von Chainguard.
Kein Image Scanning in der CI/CD-Pipeline
Laut dem Sysdig Cloud-Native Security Report 2025 enthalten 87 Prozent aller Container-Images in Produktion kritische oder hohe Schwachstellen. Der Grund: Teams verwenden veraltete Base-Images, ohne zu prüfen, was sich seit dem letzten Build geändert hat. Lösung: Image-Scanner wie Trivy, Grype oder Snyk Container in die CI/CD-Pipeline integrieren. Builds mit kritischen CVEs automatisch blockieren. Base-Images regelmäßig aktualisieren und ein Allowlist-Verfahren für zugelassene Registries einführen.
Kubernetes API Server öffentlich erreichbar
Ein öffentlich erreichbarer API Server ist eine Einladung für Brute-Force-Angriffe auf Credentials und für die Ausnutzung bekannter API-Schwachstellen. Shodan-Scans zeigen regelmäßig Tausende öffentlich erreichbare Kubernetes-API-Endpunkte. Lösung: Den API Server hinter ein VPN oder einen Bastion Host stellen. Zugriff auf bekannte IP-Bereiche beschränken. API-Audit-Logging aktivieren, um ungewöhnliche Zugriffsmuster zu erkennen. Kurzlebige Tokens statt statische Credentials verwenden.
Fehlende Resource Limits und Requests
Ohne CPU- und Memory-Limits kann ein einzelner Pod die Ressourcen eines gesamten Nodes aufbrauchen. Das ist nicht nur ein Stabilitätsrisiko, sondern auch ein Einfallstor für Denial-of-Service-Angriffe innerhalb des Clusters. Ein Cryptomining-Container, der sich über eine kompromittierte Dependency einschleust, kann unbemerkt die gesamte Rechenleistung abziehen. Lösung: Resource Requests und Limits für jeden Container definieren. LimitRanges pro Namespace setzen und ResourceQuotas einrichten.
Pod Security Standards: Der neue Mindeststandard
Seit Kubernetes 1.25 sind die veralteten Pod Security Policies (PSP) entfernt. An ihre Stelle treten die Pod Security Standards (PSS) mit dem integrierten Pod Security Admission Controller. Dieser definiert drei Sicherheitsstufen, die auf Namespace-Ebene durchgesetzt werden.
Die Stufe Privileged erlaubt alles und ist ausschließlich für System-Workloads gedacht, etwa kube-system-Pods und CNI-Plugins. Baseline verhindert bekannte Privilege-Escalation-Pfade und sollte als absolutes Minimum für jeden Namespace gelten. Restricted erzwingt die aktuellen Best Practices zur Pod-Härtung und ist das Ziel für alle Workloads, die nicht explizit erhöhte Rechte benötigen.
Wichtig: PSP-Migration nicht aufschieben
Wer noch auf Kubernetes-Versionen vor 1.25 arbeitet oder PSP-Konfigurationen verwendet, muss zeitnah migrieren. Die offizielle Kubernetes-Dokumentation empfiehlt, zunächst den Audit- und Warn-Modus der Pod Security Admission für alle Namespaces zu aktivieren. So sehen Teams, welche Pods gegen die gewünschte Policy verstoßen, ohne den laufenden Betrieb zu unterbrechen. Erst wenn alle Workloads konform sind, wird der Enforce-Modus aktiviert.
Die Umsetzung erfolgt über Labels auf dem Namespace. Ein einziges Label reicht aus, um die gewünschte Sicherheitsstufe zu aktivieren. Teams, die bisher keine Pod-Security-Mechanismen einsetzen, sollten mit der Baseline-Stufe im Audit-Modus beginnen und innerhalb von vier bis sechs Wochen auf Enforce umstellen.
Ergänzend empfiehlt sich der Einsatz von Policy-Engines wie Kyverno oder Open Policy Agent (OPA) mit Gatekeeper. Diese ermöglichen feinere Kontrolle als die eingebauten Pod Security Standards und können zusätzliche Regeln durchsetzen, etwa Pflicht-Labels, Image-Allowlists oder maximale Replica-Counts. Falco, das inzwischen mehr als 22 Millionen Downloads verzeichnet und als CNCF-Graduated-Projekt gilt, bietet ergänzend Runtime-Security: Es erkennt verdächtiges Verhalten in laufenden Containern in Echtzeit.
Checkliste: Kubernetes-Cluster in fünf Tagen absichern
Tag 1: Bestandsaufnahme und RBAC-Audit
- Alle ClusterRoleBindings und RoleBindings auflisten und auf übermäßige Berechtigungen prüfen
- Default Service Accounts identifizieren, die Rollen zugewiesen bekommen haben
- API-Server-Erreichbarkeit prüfen und gegebenenfalls auf VPN oder Bastion Host beschränken
- Alle Namespaces inventarisieren und deren Sicherheitsanforderungen dokumentieren
Tag 2: Pod Security Standards aktivieren
- Baseline-Policy im Audit-Modus für alle Namespaces setzen
- Violations analysieren und Workloads anpassen
- Privilegierte Container in dedizierte Namespaces verschieben
- SecurityContext für alle Pods konfigurieren: runAsNonRoot, readOnlyRootFilesystem
Tag 3: Netzwerk und Secrets
- Default-Deny Network Policies für sensible Namespaces einrichten
- Erlaubte Verbindungen explizit freigeben und dokumentieren
- Encryption at Rest für etcd aktivieren
- Secrets von Umgebungsvariablen auf Volume Mounts umstellen
Tag 4: CI/CD-Integration und Image-Hygiene
- Image Scanner wie Trivy in die Build-Pipeline integrieren
- Base-Image-Allowlist definieren und durchsetzen
- Resource Limits und LimitRanges pro Namespace konfigurieren
- ResourceQuotas für Teams mit Shared-Cluster-Zugriff einrichten
Tag 5: Monitoring, Alerting und Dokumentation
- API-Audit-Logging aktivieren und an zentrales SIEM anbinden
- Alerting für fehlgeschlagene Authentifizierungsversuche und Policy-Violations einrichten
- Runtime-Security-Tool wie Falco evaluieren und in Testumgebung deployen
- Alle Änderungen dokumentieren und vierteljährlichen Review-Zyklus festlegen
Fazit: Starten Sie mit dem RBAC-Audit
Kubernetes-Sicherheit ist kein Projekt, das man einmal abschließt und dann vergisst. Es ist ein laufender Prozess, der mit einer ehrlichen Bestandsaufnahme beginnt. Die acht beschriebenen Fehlkonfigurationen decken den Großteil der realen Angriffsfläche ab. Keine davon erfordert ein neues Tool oder ein externes Beratungsprojekt.
Wer diese Woche mit dem RBAC-Audit beginnt und die Pod Security Standards im Audit-Modus aktiviert, hat innerhalb von fünf Tagen eine deutlich gehärtete Umgebung. Die Investition besteht aus fünf Arbeitstagen fokussierter Arbeit. Der Return besteht darin, nicht zu den 46 Prozent zu gehören, die nach einem Kubernetes-Sicherheitsvorfall Umsatz und Kunden verlieren. Und vergessen Sie nicht: Sicherheit in Kubernetes ist kein statischer Zustand. Jedes Cluster-Upgrade, jede neue Dependency und jeder zusätzliche Namespace verdient einen frischen Blick auf die Konfiguration.
Häufige Fragen
Was sind die häufigsten Kubernetes-Sicherheitsrisiken?
Die häufigsten Risiken sind Fehlkonfigurationen bei RBAC-Berechtigungen, privilegierte Container ohne Einschränkungen, fehlende Network Policies, unverschlüsselte Secrets und Container, die als Root laufen. Laut dem Red Hat State of Kubernetes Security Report 2024 gehen 45 Prozent aller Kubernetes-Sicherheitsvorfälle auf Fehlkonfigurationen zurück, nicht auf Zero-Day-Schwachstellen oder gezielte Angriffe.
Was sind Pod Security Standards in Kubernetes?
Pod Security Standards (PSS) sind ein seit Kubernetes 1.25 integrierter Sicherheitsmechanismus, der die veralteten Pod Security Policies ersetzt. Sie definieren drei Sicherheitsstufen: Privileged für System-Workloads, Baseline als Mindeststandard gegen bekannte Privilege-Escalation-Pfade und Restricted als Best-Practice-Härtung für alle regulären Workloads. Die Durchsetzung erfolgt über Labels auf Namespace-Ebene.
Wie sichere ich den Kubernetes API Server ab?
Der API Server sollte nicht öffentlich erreichbar sein. Stellen Sie ihn hinter ein VPN oder einen Bastion Host. Beschränken Sie den Zugriff auf bekannte IP-Bereiche und aktivieren Sie API-Audit-Logging. Ergänzend sollten Sie RBAC-Berechtigungen nach dem Least-Privilege-Prinzip vergeben und kurzlebige Tokens statt langfristiger Credentials verwenden.
Welche Tools helfen bei der Kubernetes-Sicherheit?
Für Image Scanning eignen sich Trivy, Grype oder Snyk Container. Für Runtime Security bieten Falco und Sysdig Echtzeit-Erkennung verdächtiger Aktivitäten in laufenden Containern. Für Policy-Enforcement sind Kyverno und Open Policy Agent mit Gatekeeper bewährte Lösungen. Diese Tools lassen sich in die CI/CD-Pipeline integrieren, sodass unsichere Konfigurationen bereits vor dem Deployment erkannt werden.
Wie lange dauert es, einen Kubernetes-Cluster abzusichern?
Die grundlegende Härtung eines Kubernetes-Clusters lässt sich in fünf Arbeitstagen umsetzen: RBAC-Audit, Pod Security Standards, Network Policies, Secrets Management und CI/CD-Integration. Die feinkörnige Abstimmung und das laufende Monitoring sind ein kontinuierlicher Prozess, der in den regulären Betrieb integriert werden sollte. Für Unternehmen mit mehreren Clustern empfiehlt sich ein zentrales Policy-Management über GitOps-Workflows.
Lesetipps der Redaktion
Mehr aus dem MBF Media Netzwerk
Quelle Titelbild: Pexels / Brett Sayles (px:5480781)
