Als Tesla 2018 Angreifer entdeckte, die innerhalb seiner Kubernetes-Cluster Cryptomining-Operationen durchführten, war die Ursache überraschend einfach: ein ungeschütztes Dashboard ohne Passwort. Jahre später plagt dieselbe Art von Fehlkonfiguration weiterhin Unternehmen in großem Umfang. Neunzig Prozent der Unternehmen hatten in den letzten 12 Monaten mindestens einen Kubernetes-Sicherheitsvorfall zu verzeichnen (Red Hat 2024), und neue Cluster werden innerhalb von 18 Minuten nach ihrer Bereitstellung zum ersten Mal angegriffen (Wiz 2025). Angesichts des prognostizierten Wachstums des Marktes für Container- und Kubernetes-Sicherheit von 1,7 Milliarden US-Dollar im Jahr 2024 auf 8 bis 9 Milliarden US-Dollar im Zeitraum 2030 bis 2033 ist die Sicherung dieser Umgebungen dringender denn je. Dieser Leitfaden deckt das gesamte Spektrum der Kubernetes-Sicherheit ab, von grundlegenden Modellen und Best Practices für den Lebenszyklus bis hin zur Erkennung von Verhaltensbedrohungen und cloud , die den heute ausgefeiltesten Angriffen begegnen.
Kubernetes-Sicherheit umfasst eine Reihe von Verfahren, Tools und Richtlinien, die containerisierte Workloads und deren Orchestrierungsinfrastruktur während des gesamten Anwendungslebenszyklus schützen – vom Erstellen von Images über die Bereitstellung bis hin zum Laufzeitbetrieb. Dazu gehören die Absicherung der Konfiguration, Zugriffskontrolle (RBAC), Netzwerksegmentierung, Geheimnisverwaltung, Erkennung von Laufzeitbedrohungen und Compliance-Überwachung über die gesamte Steuerungsebene, Worker-Knoten, Container-Images, den Netzwerkverkehr und die Konfigurationsebenen hinweg.
Warum ist das wichtig? Kubernetes ist standardmäßig nicht sicher. Die Plattform priorisiert in ihrer Standardkonfiguration Flexibilität und Entwicklergeschwindigkeit gegenüber erhöhter Sicherheit. Unternehmen müssen aktiv rollenbasierte Zugriffskontrolle (RBAC), Netzwerkrichtlinien, Geheimnisverschlüsselung, Pod-Sicherheitsstandards und Audit-Protokollierung konfigurieren, bevor ein Cluster produktionsbereit ist. Laut der Dokumentation zu den Sicherheitskonzepten von Kubernetes liegt die Verantwortung für die Sicherheitskonfiguration im Rahmen des Modells der geteilten Verantwortung eindeutig beim Betreiber.
Die geschäftlichen Auswirkungen eines solchen Fehlers sind gravierend. 67 % der Unternehmen haben aufgrund von Sicherheitsbedenken in Bezug auf Kubernetes die Bereitstellung verzögert oder verlangsamt, 46 % mussten Umsatz- oder Kundenverluste hinnehmen und 30 % wurden mit Geldstrafen belegt (Red Hat 2024). Die wachsende Angriffsfläche eines Kubernetes-Clusters erstreckt sich über den API-Server, den etcd-Datenspeicher, Kubelet, die Container-Laufzeitumgebung, das Netzwerk-Overlay und alle darin ausgeführten Workloads.
Die Containersicherheit konzentriert sich auf einzelne Container-Images, Laufzeiten und Isolationsmechanismen. Die Kubernetes-Sicherheit fügt Aspekte der Orchestrierungsebene hinzu, die über einen einzelnen Container hinausgehen. Dazu gehören API-Server-Zugriffskontrollen, RBAC-Richtlinien, die regeln, wer was im Cluster tun darf, die durch Netzwerkrichtlinien geregelte Kommunikation zwischen Pods und Namespaces, die Verwaltung von Geheimnissen und die Verschlüsselung im Ruhezustand, Zulassungscontroller, die Workloads vor der Bereitstellung validieren, sowie clusterweite Konfigurationen wie Audit-Protokollierung und Pod-Sicherheitsstandards.
Ein gehärtetes Container-Image, das in einem falsch konfigurierten Cluster bereitgestellt wird, bleibt anfällig. Die Sicherheit von Kubernetes befasst sich mit der Infrastruktur, die diese Container umgibt, verbindet und orchestriert.
Fehlkonfigurationen sind die Ursache für die meisten Kubernetes-Sicherheitsverletzungen, aber gezielte Angriffe mit lateraler Bewegung und Privilegieneskalation nehmen stark zu. Über 50 % der Befragten im Red Hat 2024-Bericht nannten Fehlkonfigurationen als Hauptursache für Sicherheitsvorfälle in Kubernetes. Die Aufschlüsselung der wichtigsten Sicherheitsbedenken spricht eine klare Sprache: Schwachstellen (33 %), Fehlkonfigurationen und Offenlegungen (27 %), aktive Angriffe (24 %) und fehlgeschlagene Compliance-Audits (16 %).
Erschwerend kommt hinzu, dass 81 % der EKS-Cluster immer noch auf die veraltete CONFIG_MAP-Authentifizierung (Wiz 2025) setzen, was ein Legacy-Risiko darstellt, das Angreifer aktiv ausnutzen. Containerbasierte Lateral-Movement-Angriffe nahmen im Jahr 2025 um 34 % zu (Tigera), was eine Verlagerung von opportunistischen Ausnutzungen von Fehlkonfigurationen hin zu gezielten Operationen nach einer Kompromittierung widerspiegelt.
Diese datierten Fallstudien mit Quellenangaben zeigen die Folgen unzureichender Kubernetes-Sicherheit und die Lehren, die aus jedem Vorfall gezogen werden können.
Das MITRE ATT&CK bietet eine gemeinsame Sprache für die Zuordnung von Kubernetes-Bedrohungen zu Sicherheitskontrollen. Die folgende Tabelle ordnet wichtige Taktiken aus der MITRE ATT&CK bestimmten Kubernetes-Sicherheitskontrollen zu.
Tabelle 1: MITRE ATT&CK -Matrix, zugeordnet zu Kubernetes-Sicherheitskontrollen
Das 4-Cs-Modell bietet ein mehrschichtiges Verteidigungsframework, bei dem jede Sicherheitsschicht von der Integrität der darunterliegenden Schicht abhängt. Dieses in der Branche weit verbreitete Modell gliedert die Kubernetes-Sicherheit in vier verschachtelte Schichten.
Jede Schicht baut auf der darunter liegenden auf. Ein perfekt gehärtetes Container-Image bietet nur begrenzten Schutz, wenn der Cluster, in dem es ausgeführt wird, anonymen API-Zugriff zulässt. Ebenso verlieren strenge cloud ihren Wert, wenn der in Containern ausgeführte Code fest codierte Geheimnisse oder anfällige Abhängigkeiten enthält.
Eine effektive Kubernetes-Sicherheit erfordert Kontrollen in jeder Lebenszyklusphase, wobei die Laufzeiterkennung die Lücken füllt, die durch das Scannen während der Erstellungsphase nicht geschlossen werden können. Die folgenden Vorgehensweisen, die sich über die Phasen der Erstellung, Bereitstellung und Laufzeit erstrecken, bieten eine umfassende Kubernetes-Sicherheitscheckliste, die mit dem OWASP Kubernetes Security Cheat Sheet übereinstimmt.
Ein Kubernetes-Sicherheitskontext definiert Berechtigungs- und Zugriffskontrolleinstellungen für einen Pod oder Container. Zu diesen Einstellungen gehören die Ausführung als Nicht-Root-Benutzer, das Aufheben von Linux-Fähigkeiten, das Einrichten von schreibgeschützten Root-Dateisystemen und das Definieren von Seccomp-Profilen. Die konsistente Anwendung von Sicherheitskontexten für alle Workloads verhindert viele gängige Wege zur Ausweitung von Berechtigungen.
Laufzeitsicherheit in Kubernetes ist die Praxis der Überwachung und des Schutzes von Workloads nach ihrer Bereitstellung. Im Gegensatz zum Scannen während der Erstellungsphase, bei dem bekannte Schwachstellen vor der Bereitstellung erkannt werden, erkennt die Laufzeitsicherheit aktive Bedrohungen, anomales Verhalten und zero-day in Live-Clustern. Unternehmen mit fortschrittlichen DevSecOps-Initiativen (42 % der Befragten) ergänzen die Prävention während der Erstellungsphase durch die Erkennung während der Laufzeit (Red Hat 2024).
Der eBPF-basierte Sicherheitsstack (Falco, Tetragon, Cilium) entwickelt sich zum Standard für die Kubernetes-Laufzeiterkennung mit minimalen Auswirkungen auf die Leistung. Die folgenden Tools sind die führenden Open-Source-Optionen in den Kategorien Scannen, Durchsetzung von Richtlinien und Laufzeiterkennung.
Tabelle 2: Vergleich von Kubernetes-Sicherheitstools
Kubescape hat den CNCF-Inkubationsstatus erreicht und wird von über 25.000 Unternehmen in mehr als 100.000 cloud (CNCF 2025) eingesetzt. Damit ist es der erste Kubernetes-Sicherheitsscanner, der in die CNCF aufgenommen wurde.
Extended Berkeley Packet Filter (eBPF) ermöglicht Beobachtbarkeit und Durchsetzung auf Kernel-Ebene mit weniger als 1 % CPU-Overhead (Tetragon) und verändert damit die Herangehensweise von Unternehmen an die Laufzeitsicherheit von Kubernetes. Zu den wichtigsten eBPF-basierten Tools gehören:
Der empfohlene Open-Source-Stack aus Kubescape, Falco, Trivy und Cilium bietet umfassende Kubernetes-Sicherheitsscans und -Erkennung bei einem Gesamt-CPU-Overhead von 1 bis 2,5 %. Diese Effizienz macht eBPF-basierte Sicherheit für Produktions-Workloads mit begrenzten Leistungsbudgets rentabel. Für Unternehmen, die ihre vorhandenen Tools evaluieren möchten, ergänzen NDR-Tools und Intrusion Detection and Prevention-Systeme die eBPF-basierte Erkennung durch Transparenz auf Netzwerkebene.
Die Erkennung von Verhaltensbedrohungen und die Transparenz auf Netzwerkebene schließen die kritische Lücke zwischen reinen Präventions-Tools und aktiven Bedrohungen, die auf Kubernetes-Cluster abzielen. Konfigurationsscans und die Durchsetzung von Richtlinien sind notwendig, aber nicht ausreichend. Sie verhindern bekannte fehlerhafte Konfigurationen, können jedoch aktive Angreifer, die Präventionskontrollen umgangen haben, nicht erkennen.
Kubernetes verwendet standardmäßig ein flaches Netzwerk, in dem jeder Pod mit jedem anderen Pod kommunizieren kann. Dadurch wird die Erkennung lateraler Bewegungen besonders wichtig. Angreifer nutzen dies aus, indem sie sich innerhalb eines Namespace von Pod zu Pod bewegen, sich über den Cluster hinweg von Namespace zu Namespace ausbreiten und von kompromittierten Pods aus auf cloud zugreifen.
Der TeamPCP worm Februar 2026) demonstrierte dieses Muster in großem Maßstab. Ein einziger Pod-Fußhalt ermöglichte es der Gruppe, den gesamten Cluster zu enumerieren, Befehle über Workloads hinweg auszuführen und einen privilegierten DaemonSet zu implementieren, der den Cluster in ein verteiltes Botnetz verwandelte und mindestens 185 Server kompromittierte (eSecurity Planet). Angesichts eines Anstiegs der containerbasierten lateralen Bewegungsangriffe um 34 % im Jahr 2025 ist die Fähigkeit, anomale Ost-West-Verkehrsmuster zu erkennen, nicht mehr optional.
Die Erkennung von Verhaltensbedrohungen konzentriert sich auf die Identifizierung anomaler Muster und nicht auf den Abgleich bekannter Signaturen. In Kubernetes-Umgebungen umfassen diese Muster ungewöhnliche API-Aufrufe, unerwartete Pod-zu-Pod-Kommunikation, Anomalien beim Zugriff auf Anmeldedaten und Indikatoren für Ressourcenentführungen.
Die im Januar 2026 bekannt gewordene Telemetrie-Sicherheitslücke in Kubernetes verdeutlicht, warum dieser Ansatz so wichtig ist. Forscher haben entdeckt, dass die Nodes/Proxy-GET-RBAC-Berechtigung, die üblicherweise für Überwachungstools gewährt wird, missbraucht werden kann, um über die Kubelet-API beliebige Befehle innerhalb von Pods auszuführen. Kubernetes stufte dies als „vorgesehenes Verhalten” ein und wird keinen Patch herausgeben. Die einzige Abwehrmöglichkeit besteht darin, anomale Ausführungsvorgänge von Überwachungsdienstkonten zu erkennen (The New Stack) – ein klassischer Anwendungsfall für Verhaltensanalysen und threat hunting.
Zu den Erkennungsmethoden für Kubernetes-Bedrohungen gehören:
Kein führender Kubernetes-Sicherheitsleitfaden behandelt die Integration von Netzwerküberwachung und -reaktion (NDR) in die Kubernetes-Sicherheit – ein erheblicher blinder Fleck, da die Transparenz auf Netzwerkebene Bedrohungen erkennt, die konfigurationsbasierte Tools vollständig übersehen.
NDR bietet Transparenz für den Ost-West-Verkehr innerhalb von Kubernetes-Clustern und identifiziert anomale Kommunikationsmuster wie Pods, die unerwartete Dienste erreichen, ungewöhnliche Datenvolumina zwischen Namespaces und Versuche der Datenexfiltration über laterale Kanäle. Dies ergänzt das Scannen von Konfigurationen und die Durchsetzung von Richtlinien durch aktive Bedrohungserkennung auf Netzwerkebene und schließt die Erkennungslücke, die dazu führt, dass 90 % der Unternehmen trotz der Anwendung von Best Practices für die Kubernetes-Sicherheit immer noch Vorfälle erleben.
KSPM bietet kontinuierliche Transparenz hinsichtlich der Compliance, und die Zuordnung von Kubernetes-Kontrollen zu regulatorischen Rahmenwerken ist mittlerweile für die Einführung in Unternehmen unerlässlich. Kubernetes Security Posture Management (KSPM) bewertet kontinuierlich Cluster-Konfigurationen anhand von Sicherheits-Baselines und identifiziert Fehlkonfigurationen, Richtlinienverstöße und Compliance-Lücken in Echtzeit.
KSPM-Tools wie Kubescape, Wiz, Prisma Cloud und Sysdig bieten eine kontinuierliche Bewertung von Kubernetes-Cluster-Konfigurationen anhand von Sicherheits-Baselines, darunter CIS-Benchmarks, Pod Security Standards und benutzerdefinierte Unternehmensrichtlinien. Der CIS Kubernetes Benchmark, der von kube-bench bewertet wird, ist nach wie vor die am weitesten verbreitete Baseline für die Cluster-Absicherung. Die OWASP Kubernetes Top 10 bieten ein priorisiertes Risikorahmenwerk, das unsichere Workload-Konfigurationen (K01), Schwachstellen in der Lieferkette (K02), zu freizügige RBAC (K03), Lücken bei der Durchsetzung von Richtlinien (K04) und unzureichende Protokollierung (K05) durch anfällige Komponenten (K10) abdeckt. Eine aktualisierte Version für 2025 ist derzeit in Arbeit.
Der NSA/CISA Kubernetes Hardening Guide v1.2 (August 2022) bleibt die maßgebliche Referenz der Regierung für die Sicherheit von Kubernetes und behandelt Risiken in der Lieferkette, böswillige Akteure und Insider-Bedrohungen. Die Automatisierung der Compliance wird im Jahr 2026 weiter vorangetrieben, da Unternehmen nun verpflichtet sind, die kontinuierliche Einhaltung der Vorschriften durch automatisierte Beweissammlung statt durch regelmäßige manuelle Bewertungen nachzuweisen (Veeam).
Tabelle 3: Kubernetes-Sicherheitskontrollen, die den wichtigsten regulatorischen Rahmenwerken zugeordnet sind
Die SBOM-Anforderungen entwickeln sich weiter, da OMB M-26-05 im Januar 2026 auf einen risikobasierten Ansatz umgestellt wurde. Cloud müssen nun auf Anfrage SBOMs von Laufzeit-Produktionsumgebungen bereitstellen, was die Integration der SBOM-Generierung in Kubernetes CI/CD-Pipelines vorantreibt.
Die Sicherheit von Kubernetes entwickelt sich dank eBPF-basierter Tools, Plattform-Hardening und der Umstellung von rein präventiven auf detektionsgesteuerte Verteidigungsstrategien rasant weiter. Mehrere Entwicklungen in den Jahren 2025–2026 verändern die Herangehensweise von Unternehmen an die Sicherheitsarchitektur von Kubernetes.
Die Plattformhärtung schreitet immer schneller voran. Sechs wichtige Sicherheitsfunktionen erreichten im Jahr 2025 in Kubernetes v1.32-v1.35 den Status „stabil“, darunter Verbesserungen bei Bound ServiceAccount-Tokens, Sidecar-Container, rekursive schreibgeschützte Mounts, selektorenbasierte Autorisierung, Einschränkungen für anonyme Anfragen und geordnete Namespace-Löschung. Acht weitere Funktionen werden voraussichtlich 2026 fertiggestellt, darunter Benutzernamensräume, Pod-Zertifikate für mTLS und die Autorisierung zum Abrufen von Images (CNCF 2025).
Kritische Infrastrukturübergänge erfordern Aufmerksamkeit. Ingress-NGINX erreicht im März 2026 das Ende seiner Lebensdauer. Nach diesem Datum werden keine weiteren Releases, Bugfixes oder Sicherheitspatches mehr bereitgestellt. Das Kubernetes Security Response Committee empfiehlt die Migration zur Gateway-API (Kubernetes-Blog). Unternehmen, die ältere Ingress-NGINX-Controller verwenden, sind ungeschützten Sicherheitslücken ausgesetzt.
Die Marktvalidierung befindet sich auf einem Allzeithoch. Die Übernahme von Wiz durch Google für 32 Milliarden US-Dollar, die größte Akquisition im Bereich Cybersicherheit aller Zeiten, bestätigt den Markt cloud Sicherheit und signalisiert, dass Kubernetes-Sicherheitstools und -Plattformen für die größten Akteure der Branche eine strategische Priorität darstellen (The Register).
Die Einführung von DevSecOps schreitet immer schneller voran. 42 % der Unternehmen geben an, dass sie bereits fortgeschrittene DevSecOps-Initiativen umgesetzt haben, während sich 48 % noch in der Anfangsphase befinden (Red Hat 2024). Dieser Wandel von nachträglich hinzugefügten Sicherheitsmaßnahmen hin zu integrierten Sicherheitspraktiken verringert die Kluft zwischen Entwicklungsgeschwindigkeit und Sicherheitsabdeckung.
Der Ansatz Vectra AI für die Sicherheit von Kubernetes konzentriert sich auf die Erkennung von Verhaltensbedrohungen und Attack Signal Intelligence. Anstatt sich ausschließlich auf Konfigurationsscans und die Durchsetzung von Richtlinien zu verlassen, Vectra AI die Netzwerkverkehrsmuster in hybriden cloud , einschließlich des Ost-West-Verkehrs innerhalb von Kubernetes-Clustern, um Verhaltensindikatoren für aktive Angriffe zu erkennen. Dieser Ansatz basiert auf der „Assume-Compromise“-Philosophie: Intelligente Angreifer werden Präventionsmaßnahmen letztendlich umgehen, sodass die Erkennung ihres Verhaltens nach der Kompromittierung – einschließlich lateraler Bewegungen, Privilegienerweiterung und Datenexfiltration – das tatsächliche Risiko verringert. Durch die Bereitstellung von Netzwerkerkennung und -reaktion, die konfigurationsbasierte Tools ergänzen, erhalten Unternehmen die erforderliche Transparenz, um Bedrohungen zu identifizieren, die durch Prävention allein nicht gestoppt werden können.
Kubernetes-Sicherheit umfasst eine Reihe von Verfahren, Tools und Richtlinien, die containerisierte Workloads und deren Orchestrierungsinfrastruktur während des gesamten Anwendungslebenszyklus schützen, von der Image-Erstellung über die Bereitstellung bis hin zum Laufzeitbetrieb. Dazu gehören die Absicherung der Konfiguration, Zugriffskontrolle durch RBAC, Netzwerksegmentierung über Netzwerkrichtlinien, Geheimnisverwaltung, Erkennung von Laufzeitbedrohungen und Compliance-Überwachung. Im Gegensatz zur Containersicherheit, die sich auf einzelne Images und Laufzeiten konzentriert, befasst sich die Kubernetes-Sicherheit mit der Orchestrierungsebene, einschließlich des API-Servers, des etcd-Datenspeichers, der Zulassungscontroller und der clusterweiten Konfigurationen. Da 90 % der Unternehmen im vergangenen Jahr mindestens einen Vorfall erlebt haben (Red Hat 2024), ist eine umfassende Kubernetes-Sicherheit eine geschäftliche Notwendigkeit und keine optionale Verbesserung.
Nein. Kubernetes priorisiert in seiner Standardkonfiguration Flexibilität und Entwicklergeschwindigkeit gegenüber Sicherheit. Standardmäßig erlauben Cluster uneingeschränkte Pod-zu-Pod-Kommunikation, verschlüsseln keine Secrets in etcd, erlauben in einigen Konfigurationen anonymen API-Zugriff und setzen keine Pod-Sicherheitsstandards durch. Unternehmen müssen RBAC mit minimalen Berechtigungen aktiv konfigurieren, Standard-Denial-Netzwerkrichtlinien implementieren, etcd-Verschlüsselung aktivieren, Zulassungscontroller bereitstellen und Audit-Protokollierung einrichten, bevor ein Cluster produktionsbereit ist. Die Dringlichkeit ist real: AKS-Cluster werden innerhalb von 18 Minuten nach ihrer Erstellung zum ersten Mal angegriffen, EKS-Cluster innerhalb von 28 Minuten (Wiz 2025). Diese Lücke zwischen Standardkonfiguration und sicherem Betrieb ist der Grund, warum Best Practices für die Sicherheit von Kubernetes vom ersten Tag an von entscheidender Bedeutung sind.
Die 4 Cs stehen für Cloud, Cluster, Container und Code. Jede Schicht baut auf der darunter liegenden auf. Cloud bildet die Grundlage durch IAM-Richtlinien, Netzwerk-Firewalls und Verschlüsselung während der Übertragung. Kontrollen auf Cluster-Ebene sichern die Orchestrierungsschicht mit RBAC, Zulassungskontrollern, etcd-Verschlüsselung und Audit-Protokollierung. Die Containersicherheit stärkt einzelne Workloads durch Image-Scans, Base-Image-Hardening, Rootless-Ausführung und Sicherheitskontexte. Die Codesicherheit befasst sich mit Schwachstellen auf Anwendungsebene durch Abhängigkeits-Scans, Geheimniserkennung und Lieferkettenüberprüfung. Eine Schwachstelle in einer äußeren Schicht untergräbt die Sicherheit aller inneren Schichten, wodurch die 4 Cs zu einem praktischen Rahmenwerk für die Identifizierung und Schließung von Lücken in der gesamten Kubernetes-Sicherheitsarchitektur werden.
Zu den wichtigsten Open-Source-Tools gehören Falco (CNCF Graduated) für die Erkennung von Laufzeitbedrohungen über eBPF-basierte Systemaufrufüberwachung, Trivy für umfassende Schwachstellenscans von Container-Images und Kubernetes-Konfigurationen, Kubescape (CNCF Incubating) für das Sicherheitsmanagement in über 25.000 Unternehmen, OPA/Gatekeeper und Kyverno für die Zulassungskontrolle und Durchsetzung von Richtlinien, kube-bench für die CIS Kubernetes Benchmark-Konformitätsbewertung und Tetragon/Cilium für eBPF-basierte Sicherheitsüberwachung mit weniger als 1 % CPU-Overhead. Unternehmensplattformen von Anbietern wie Wiz, Sysdig und Prisma Cloud kommerziellen Support und einen größeren Funktionsumfang. Der empfohlene Open-Source-Stack aus Kubescape, Falco, Trivy und Cilium bietet umfassende Abdeckung vom Build bis zur Laufzeit bei einem CPU-Overhead von insgesamt 1–2,5 %.
Kubernetes Security Posture Management (KSPM) bietet eine kontinuierliche Bewertung von Cluster-Konfigurationen anhand von Sicherheitsrichtlinien wie CIS Kubernetes Benchmarks, Pod Security Standards und benutzerdefinierten Unternehmensrichtlinien. KSPM-Tools identifizieren automatisch Fehlkonfigurationen, Richtlinienverstöße und Compliance-Lücken in Clustern in Echtzeit und ersetzen damit regelmäßige manuelle Bewertungen. Zu den führenden KSPM-Tools gehören Kubescape, Wiz, Prisma Cloud und Sysdig. Im Gegensatz zu punktuellen Scans bietet KSPM einen kontinuierlichen Überblick über Konfigurationsabweichungen und die Einhaltung von Richtlinien, was zunehmend von regulatorischen Rahmenwerken wie HIPAA, PCI DSS, SOC 2 und NIST 800-53 gefordert wird. Da die Automatisierung der Compliance im Jahr 2026 zunimmt, ist KSPM zu einer unverzichtbaren Infrastruktur für Kubernetes-Bereitstellungen in Unternehmen geworden.
Kubernetes bietet Netzwerkrichtlinien, die den Datenverkehr zwischen Pods auf den Schichten 3 und 4 (IP-Adressen und Ports) steuern. Standardmäßig ist die gesamte Kommunikation zwischen Pods ohne Einschränkungen zulässig, wodurch ein flaches Netzwerk entsteht, das Angreifern seitliche Bewegungen erleichtert. Unternehmen müssen Standard-Denial-Netzwerkrichtlinien für den eingehenden und ausgehenden Datenverkehr implementieren und ausdrücklich nur erforderliche Kommunikationspfade zulassen. Für eine detailliertere Kontrolle bietet Cilium eine eBPF-basierte Durchsetzung von Netzwerkrichtlinien auf Layer 7 (Anwendungsprotokollebene), während Service-Mesh-Lösungen wie Istio oder Linkerd Mutual TLS (mTLS) für verschlüsselte Pod-zu-Pod-Kommunikation hinzufügen. Über die Durchsetzung von Richtlinien hinaus bietet NDR Einblick in East-West-Verkehrsmuster, um anomale Kommunikation zu erkennen, die durch Richtlinienverstöße allein nicht erfasst werden kann.
Die OWASP Kubernetes Top 10 ist eine nach Priorität geordnete Liste der kritischsten Sicherheitsrisiken in Kubernetes-Umgebungen und bietet einen gemeinsamen Rahmen für die Risikobewertung und die Zuordnung von Kontrollmaßnahmen. Zu den aktuellen Risiken zählen unsichere Workload-Konfigurationen (K01), Schwachstellen in der Lieferkette (K02), zu freizügige RBAC (K03), fehlende zentralisierte Durchsetzung von Richtlinien (K04), unzureichende Protokollierung und Überwachung (K05), fehlerhafte Authentifizierung (K06), fehlende Netzwerksegmentierung (K07), Fehler bei der Verwaltung geheimer Daten (K08), falsch konfigurierte Cluster-Komponenten (K09) und veraltete und anfällige Kubernetes-Komponenten (K10). Jedes Risiko ist bestimmten Kontrollen zugeordnet, die Unternehmen implementieren können. Eine Aktualisierung für 2025 wird derzeit im Rahmen einer Community-Umfrage durchgeführt. In Kombination mit dem CIS Kubernetes Benchmark und dem NSA/CISA Kubernetes Hardening Guide bietet die OWASP Top 10 ein umfassendes Risikorahmenwerk für die Einhaltung der Kubernetes-Sicherheitsstandards.