Best Practices für Kubernetes-Sicherheit: Härtung von Build bis Runtime

Kubernetes wird mit permissiven Standardeinstellungen ausgeliefert, daher liegt die Clustersicherheit in Ihrer Verantwortung. Erfahren Sie mehr über Best Practices für Kubernetes-Sicherheit in den Phasen Build, Bereitstellung und Runtime.

Was ist Kubernetes-Sicherheit?

Kubernetes-Sicherheit ist die Gesamtheit der Kontrollen, die Sie über Build, Bereitstellung und Laufzeit hinweg anwenden, um einen Cluster, die darin ausgeführten Workloads und die Pipeline, die ihn versorgt, zu schützen. Ohne diese kann eine einzige nicht authentifizierte Anfrage Ihren gesamten Cluster übernehmen. Genau das war IngressNightmare, die Schwachstelle mit einem Schweregrad von 9,8, die im März 2025 in ingress-nginx offengelegt wurde, dem Controller, der in über 40 % der Kubernetes-Cluster läuft.

Sein Admission Webhook befand sich im Pod-Netzwerk ohne Authentifizierung, und ingress-nginx liest standardmäßig jedes Secret im Cluster. Erreichen Sie das Netzwerk, übernehmen Sie den Cluster. Es brauchte keine Exploit-Kette, kein gestohlenes Passwort: nur permissive Standardeinstellungen, die genau das taten, wofür sie konfiguriert waren.

Diese Lücke zwischen dem, was Kubernetes mitbringt, und dem, was ein Produktionscluster benötigt, wird durch Hardening geschlossen. Kubernetes-Sicherheits-Best-Practices sind die Methode, mit der Sie sie schließen, Phase für Phase, vom Image, das Sie erstellen, bis zur Workload, die Sie ausführen. Da Orchestrierung Ihre Workloads, Secrets und Ost-West-Datenverkehr in einer einzigen Control Plane zentralisiert, kann eine einzelne Fehlkonfiguration jeden von Ihnen betriebenen Service offenlegen, weshalb diese Aufgabe bei Ihnen und nicht bei der Plattform liegt.

Warum ist Kubernetes-Sicherheit wichtig?

Kubernetes härtet sich nicht selbst. Die CISA/NSA Kubernetes Hardening Guidance dokumentiert drei aufschlussreiche Standardeinstellungen in jedem neuen Cluster: anonyme Anmeldung am API-Server ist aktiviert, Secrets werden unverschlüsselt in etcd gespeichert, und Audit-Logging ist deaktiviert. Das Shared-Responsibility-Modell legt vier Kontrollen in Ihre Hände: rollenbasierte Zugriffskontrolle (RBAC), Netzwerkrichtlinien, Secrets-Verschlüsselung und Laufzeitkontrollen. Der Cloud-Anbieter wird sie nicht für Sie konfigurieren, und die Distribution ebenfalls nicht. Da diese Kontrollen in Ihrer Konfiguration leben und im Laufe der Zeit driften, verifizieren Teams sie zunehmend kontinuierlich mit Kubernetes Security Posture Management, anstatt sie manuell zu auditieren.

Ein Angreifer, der einen nicht authentifizierten API-Server erreicht, kann jedes Secret in etcd lesen, einen Pod auf jedem Node planen und sich zwischen Namespaces bewegen, während das Audit-Logging stumm bleibt, sodass das erste Signal, das Sie erhalten, der eigentliche Sicherheitsvorfall sein kann. Ein einzelner exponierter Endpunkt wird in Minuten zu clusterweitem Zugriff, genau dem Muster, dem IngressNightmare folgte.

Mit der Verbreitung steigen auch die Risiken. Die jährliche Cloud Native Survey der Cloud Native Computing Foundation (CNCF) berichtet, dass inzwischen 82 % der Container-Nutzer Kubernetes in Produktion einsetzen, gegenüber 66 % im Jahr 2023. Da Cluster im Pfad kundenorientierter Services, regulierter Daten und Audit-Verpflichtungen liegen, wird aus einer einzigen übersehenen Kontrolle ein Risiko für Sicherheitsverletzungen, fehlgeschlagene Audits und meldepflichtige Vorfälle, für die Ihr Team geradestehen muss. Zu wissen, was auf dem Spiel steht, ist erst dann relevant, wenn Sie wissen, welche Teile des Clusters dieses Risiko tragen.

Kernkomponenten eines Kubernetes-Clusters

Sie können nicht härten, was Sie nicht inventarisiert haben. Jede Komponente bringt ein spezifisches Sicherheitsrisiko mit sich, und das Verständnis dieses Risikos zeigt Ihnen, wo Ihre Kontrollen greifen müssen.

Komponenten der Control Plane:

• API-Server: Jeder kubectl-Befehl, den Sie ausführen, jeder Admission Webhook und jede Anfrage nach einem Service-Account-Token läuft über den API-Server. Unbefugter Zugriff hier bedeutet vollständige Kontrolle über den Cluster.
• etcd: Speichert den gesamten Clusterzustand, die Konfiguration und die Secrets, von denen Sie abhängig sind. Lesezugriff auf etcd ist funktional gleichbedeutend mit Root auf Ihrem gesamten Cluster.
• Scheduler und Controller Manager: Ein kompromittierter Scheduler kann Workloads gezielt auf bestimmten Nodes platzieren, um lokale Ressourcen auszunutzen. Die Manipulation von Controllern kann Deployments, Replikazahlen und Ressourcenzuweisungen unbemerkt verändern.

Komponenten der Worker-Nodes:

• kubelet: Der Agent auf jedem Node, der Pod-Spezifikationen ausführt. Wenn Sie die kubelet-API exponiert lassen, kann ein Angreifer Container erstellen oder Befehle direkt auf dem Node ausführen.
• kube-proxy: Verwaltet Netzwerkregeln für das Service-Routing. Falsch konfigurierte Proxy-Regeln können Ihre internen Services für externen Datenverkehr offenlegen.
• Container Runtime: Führt Container auf dem Host aus. Eine verwundbare Runtime exponiert jeden von ihr unterstützten Container und den Host selbst, wie NIST SP 800-190 feststellt.

Pods, Container und Netzwerk:

• Pods teilen sich Netzwerk-Namespaces, sodass ein kompromittierter Container in einem Pod ohne Netzwerkkontrollen auf andere Container im selben Pod zugreifen kann. Ohne NetworkPolicy-Objekte kommunizieren Ihre Pods in verschiedenen Namespaces standardmäßig frei miteinander. 
• Container-Images und Infrastructure-as-Code (IaC)-Vorlagen gelangen aus externen Registries in Ihren Cluster, und ein kompromittiertes Image, das in die Produktion übernommen wird, verbreitet sich über jeden Node, der es plant. Wenn Sie jede Komponente ihrem Risiko zuordnen, sehen Sie genau, wo die Hardening-Kontrollen in diesem Leitfaden greifen.

Wie Kubernetes-Sicherheit über den Build-to-Runtime-Lebenszyklus hinweg funktioniert

Sie sichern Kubernetes durch einen kontinuierlichen Workflow, nicht durch eine punktuelle Prüfung. Jede Phase erzwingt eine andere Kategorie von Kontrollen, und die Ausgabe einer Phase wird zur Eingabe der nächsten. Folgendes geschieht in jedem Schritt.

1. Build-Zeit: Sie scannen Container-Images auf bekannte Schwachstellen, validieren IaC-Vorlagen gegen Richtlinien, signieren Images kryptografisch und erstellen eine Software Bill of Materials (SBOM). Diese präventiven Kontrollen stoppen Probleme an der Quelle, bevor irgendein Artefakt geplant werden kann.
2. Bereitstellen und konfigurieren: Wenn Sie eine Workload einreichen, bewerten Admission Controller sie vor der Planung gegen Richtlinien. RBAC bestimmt, wer Ressourcen erstellen, ändern oder lesen darf, und Netzwerkrichtlinien definieren, welche Pods kommunizieren dürfen. Das Image, das Sie beim Build signiert haben, ist hier nur dann geschützt, wenn die Admission Control die Signatur tatsächlich prüft.
3. Konfiguration von Control Plane und Nodes: Sie konfigurieren den API-Server, etcd, kubelet und das Node-Betriebssystem so, dass weniger exponiert ist. Authentifizierung, Autorisierung und Verschlüsselung setzen die Vertrauensgrenze, auf die sich jede andere Phase stützt, sodass eine schwache Control Plane alles nachgelagerte schwächt.
4. Laufzeit: Monitoring-Tools überwachen Ihre laufenden Workloads auf Verhaltensanomalien, Konfigurationsdrift und bekannte Angriffsmuster, während seccomp- und AppArmor-Profile einschränken, welche Systemaufrufe Ihre Container ausführen dürfen. In der Laufzeit entdecken Sie auch die Lücken, die Build und Bereitstellung übersehen haben.

Sie schließen den Kreislauf, wenn Laufzeitbefunde als aktualisierte Images, aktualisierte IaC und aktualisierte Admission-Richtlinien in Ihre Build-Phase zurückfließen. Der Lebenszyklus funktioniert nur, wenn jede Übergabe hält. Hier sehen Sie, was eine fehlgeschlagene Übergabe kostet.

Auswirkungen eines kompromittierten Kubernetes-Clusters

Wenn Ihr Cluster kompromittiert wird, reichen die Folgen weit über eine einzelne Workload hinaus.

• Laterale Bewegung und Blast Radius: Ihre Cluster führen Dutzende bis Tausende Pods mit gemeinsamer Netzwerkkonnektivität aus. Ein Angreifer, der Zugriff auf einen Ihrer Pods erhält, kann sich lateral über Namespaces und Nodes bewegen, wenn RBAC überprivilegiert ist und Netzwerkrichtlinien fehlen.
• Offenlegung von Secrets: etcd enthält Ihre API-Schlüssel, Datenbankzugangsdaten, TLS-Zertifikate und Service-Tokens. Da Secrets standardmäßig unverschlüsselt sind, kann ein Angreifer mit Lesezugriff auf etcd jede Zugangsinformation in Ihrem Cluster extrahieren.
• Ausbreitung über die Supply Chain: Ein kompromittiertes Container-Image, das über Ihre Continuous-Integration- und Continuous-Delivery-(CI/CD)-Pipeline bereitgestellt wird, erreicht jeden Node, der es plant. In Clustern mit Hunderten Replikaten kann ein einzelnes kompromittiertes Image innerhalb von Minuten schädlichen Code in Ihrer gesamten Infrastruktur ausführen.
• Kompromittierung von Workloads und Daten: Ihre Produktionsdatenbanken, kundenorientierten Anwendungen und internen Services laufen nebeneinander. Eine Sicherheitsverletzung in einer Workload kann sensible Daten offenlegen, die Serviceverfügbarkeit stören oder Persistenz für zukünftige Angriffe schaffen.
• Compliance- und regulatorisches Risiko: Wenn Ihre Cluster Zahlungsdaten, Gesundheitsakten oder behördliche Workloads verarbeiten, unterliegen sie PCI DSS, HIPAA, FedRAMP und SOC 2-Anforderungen. Ein fehlkonfigurierter Cluster, der ein Audit nicht besteht, kann zu Betriebseinstellungen und finanziellen Strafen führen.

Hardening reduziert den Blast Radius jeder einzelnen Kompromittierung, verkürzt Incident-Response-Zeiträume und liefert die Audit-Nachweise, die Ihr Compliance-Programm erfordert. Das in der Praxis zu erreichen, ist schwieriger, als es klingt, aus Gründen, die spezifisch dafür sind, wie Kubernetes läuft.

Herausforderungen bei der Absicherung von Kubernetes

Kubernetes-Sicherheit ist operativ schwierig, selbst für Ihre erfahrensten Teammitglieder. Die Flüchtigkeit der Plattform, ihr deklaratives Konfigurationsmodell und ihre verteilte Architektur erzeugen Reibung, für die statische Sicherheitstools nicht ausgelegt wurden.

• Ephemere, sich ständig ändernde Workloads: Pods werden kontinuierlich erstellt, zerstört und neu geplant. Eine Posture-Aufnahme Ihres Clusters um 9:00 Uhr spiegelt seinen Zustand um 9:05 Uhr möglicherweise nicht mehr wider.
• Sichtbarkeitslücken in laufende Container: Container teilen sich den Host-Kernel, isolieren aber ihre Prozesse, Dateisysteme und Netzwerk-Stacks. Standardmäßige hostbasierte Monitoring-Tools verfügen oft nicht über den Kontext, um normales Containerverhalten von bösartiger Aktivität zu unterscheiden.
• Komplexität der Konfiguration und Drift: Ein Produktionscluster umfasst Hunderte YAML-Manifeste, RBAC-Bindings und Admission-Regeln. Drift zwischen dem, was Sie in Git deklarieren, und dem, was in Ihrem Cluster läuft, führt zu nicht nachverfolgter Exponierung.
• Multi-Cluster- und Multi-Cloud-Sprawl: Wenn Sie Cluster über Amazon Web Services (AWS), Azure, Google Cloud Platform (GCP) und On-Premises-Umgebungen hinweg betreiben, müssen Sie konsistente Richtlinien über verschiedene Managed Services hinweg durchsetzen, jeweils mit eigener Shared-Responsibility-Grenze.
• Fragmentierte Tooling-Landschaft: Image-Scanning, RBAC-Management, Durchsetzung von Netzwerkrichtlinien, Laufzeit-Monitoring und Compliance-Reporting erfordern oft separate Tools ohne gemeinsames Datenmodell. Die Alarmkorrelation liegt bei Ihnen.
• Fachkräftemangel und organisatorische Reibung: Die spezialisierten Fähigkeiten sind knapp, und die CNCF-Umfrage 2025 ergab, dass erstmals die führende Hürde für die Cloud-Native-Einführung organisatorischer statt technischer Natur ist: interne Kommunikation, Teamdynamik und Abstimmung mit der Führungsebene. Kontrollen werden nicht angewendet, weil sich niemand dafür verantwortlich fühlt.

Diese Einschränkungen prägen sowohl Ihre Tooling-Entscheidungen als auch Ihre Einstellungsprioritäten, und sie erklären, warum dieselben Fehler clusterübergreifend immer wieder auftreten.

Häufige Kubernetes-Sicherheitsfehler

Bestimmte Anti-Patterns von Betreibern schaffen die Exponierungen, die Angreifer ausnutzen. Identifizieren und beseitigen Sie jede dieser Praktiken in Ihren Clustern:

• Ausführen privilegierter Container oder Root-Container. Privilegierte Container umgehen jede Linux-Kernel-Isolation. Ein Container, der als Root mit allowPrivilegeEscalation: true läuft, kann auf den Host ausbrechen.
• Vergabe von cluster-admin oder Wildcard-RBAC. Wildcard-Berechtigungen (resources: ["*"], verbs: ["*"]) erstrecken sich automatisch auf API-Ressourcen, die noch gar nicht existieren. Die Kubernetes-Dokumentation kennzeichnet dieses Muster mit „DO NOT USE.“
• Beibehalten von Default-Allow-Netzwerken. Ohne NetworkPolicy-Objekte kommunizieren Ihre Pods in verschiedenen Namespaces frei miteinander.
• Speichern von Secrets in Klartext-Manifests. Das Committen von Zugangsdaten in Git oder deren Übergabe als Umgebungsvariablen exponiert sie in Crash-Dumps, Logs und der Shell-Historie.
• Überspringen von Image- und IaC-Scanning. Die Bereitstellung ungescannter Images lässt Schwachstellen unkontrolliert in die Produktion gelangen.
• Hardening als einmaliges Gate behandeln. Ein beim Bootstrap gehärteter Cluster driftet, wenn Ihre Teams Workloads hinzufügen und Konfigurationen ändern. Ohne kontinuierliche Durchsetzung verschlechtert sich die Sicherheitslage.
• Node- und Control-Plane-Konfiguration ignorieren. Anonyme Anmeldung am API-Server aktiviert zu lassen, etcd-Verschlüsselung auszulassen und Audit-Logging wegzulassen sind Standardzustände, die Ihre ausdrückliche Behebung erfordern.

Jeder dieser Punkte lässt sich mit den untenstehenden Praktiken beheben. Behandeln Sie sie als Checkliste von Exponierungen, die Sie beseitigen sollten, bevor Sie zusätzliche Workloads auf den Cluster skalieren.

Kubernetes-Sicherheits-Best-Practices

Diese Kubernetes-Sicherheits-Best-Practices bilden den operativen Kern der Härtung von Kubernetes-Clustern, organisiert nach denselben vier Lebenszyklusphasen, die oben eingeführt wurden. Arbeiten Sie sie der Reihe nach durch, denn jede Phase setzt voraus, dass die vorherige trägt.

Absicherung der Build-Phase

1. Scannen Sie Images auf Schwachstellen, bevor sie eine Registry erreichen. Integrieren Sie Container-Image-Scanning in Ihre CI-Pipelines, damit verwundbare Images niemals zu bereitstellbaren Artefakten werden.
2. Verwenden Sie minimale oder distroless Base Images. Distroless-Images enthalten nur Ihre Anwendung und deren Laufzeitabhängigkeiten, ohne Shell, Paketmanager oder unnötige Binärdateien. Pinnen Sie Images auf explizite Versionssuffixe (e.g., gcr.io/distroless/static-debian13) und verwenden Sie niemals das latest tag.
3. Signieren und verifizieren Sie Images. Verwenden Sie Cosign oder Notary, um Images in CI zu signieren. Konfigurieren Sie Admission Controller so, dass sie unsignierte oder nicht verifizierte Images zur Bereitstellungszeit ablehnen.
4. Scannen Sie IaC und Kubernetes-Manifeste. Validieren Sie Terraform, Helm-Charts und rohe YAML-Dateien gegen Sicherheitsrichtlinien, bevor sie Ihren Cluster erreichen.
5. Erstellen Sie eine SBOM für jedes Image, um die Herkunft festzustellen und das Nachverfolgen von Schwachstellen nach der Bereitstellung zu unterstützen.
6. Halten Sie Secrets aus Images heraus. Backen Sie niemals Zugangsdaten, API-Schlüssel oder Zertifikate in Container-Images oder Dockerfiles ein.

Diese Kontrollen der Build-Phase halten verwundbare und unsignierte Artefakte aus der Pipeline fern, bevor irgendetwas ausgeführt werden kann. Ein Image, das sie besteht, ist dennoch nur dann sicher, wenn der Cluster es korrekt zulässt, und hier übernimmt die Konfiguration zur Bereitstellungszeit.

Härtung von Cluster-Konfiguration und Bereitstellung

Diese Kubernetes-RBAC-Best-Practices und Netzwerkkontrollen verwandeln Richtlinien zur Bereitstellungszeit in durchgesetzte Leitplanken.

1. Wenden Sie Least-Privilege-RBAC an. Erstellen Sie namespacebezogene Roles mit expliziten Verben und Ressourcennamen. Eliminieren Sie Wildcard-Berechtigungen. Beschränken Sie cluster-admin auf Break-Glass-Nutzung. Setzen Sie automountServiceAccountToken: false für Service Accounts, die keinen API-Zugriff benötigen.

2. Erzwingen Sie Default-Deny-Netzwerkrichtlinien. Wenden Sie eine default-deny-all Netwerzwingen Modus mit dem restrictedorkPolicy, sowohl für Ingress als auch Egress, beim Bootstrap auf jeden Namespace an. Fügen Sie explizite Allow-Regeln pro Workload hinzu, einschließlich einer DNS-Egress-Ausnahme auf UDP-Port 53.

3. Erzwingen Sie den Restricted Pod Security Standard. Verwenden Sie Pod Security Admission im enforce-Modus mit dem restricted level für Produktions-Namespaces. Dies blockiert privilegierte Container, erfordert runAsNonRoot, schreibt seccomp-Profile vor und beschränkt Volume-Typen.

4. Fügen Sie Admission Control mit OPA Gatekeeper oder Kyverno hinzu. Erzwingen Sie readOnlyRootFilesystem: true, allowPrivilegeEscalation: false, Allowlists für Image-Registries und Richtlinien zum Entfernen aller Capabilities. Verwenden Sie zunächst den Dry-Run-Modus, um bestehende Workloads zu auditieren, bevor Sie auf deny umschalten.

5. Verwalten Sie Secrets in einem externen Store mit etcd-Verschlüsselung im Ruhezustand. Verwenden Sie den Key Management Service (KMS) v2-Provider für Envelope-Verschlüsselung und mounten Sie Secrets als Volumes über den Secrets Store CSI Driver, der tmpfs verwendet, sodass Secret-Daten niemals die Node-Festplatte erreichen. Vermeiden Sie die Übergabe von Secrets als Umgebungsvariablen.

6. Setzen Sie Ressourcenlimits. Definieren Sie CPU- und Speicheranforderungen sowie -limits für jeden Container, um Ressourcenerschöpfung zu verhindern.

Wenn Richtlinien zur Bereitstellungszeit durchgesetzt werden, laufen Ihre Workloads mit minimalen Rechten und Default-Deny-Netzwerk. Das Vertrauen, auf dem diese Leitplanken beruhen, sitzt jedoch weiterhin in der Control Plane und den darunterliegenden Nodes, daher härten Sie diese als Nächstes.

Schutz der Control Plane und Worker-Nodes

Die Control Plane ist der eine Ort, an dem eine einzige schwache Einstellung alles andere betrifft. Konfigurieren Sie jeden dieser Punkte und verifizieren Sie sie dann regelmäßig statt nur einmal beim Bootstrap.

Hardening-Schritt	Was zu konfigurieren ist	Quelle
API-Server-Zugriff	Erfordern Sie starke Authentifizierung und gegenseitiges TLS; halten Sie den API-Server vom öffentlichen Internet fern.	CIS Benchmark
Anonyme Authentifizierung	Setzen Sie --anonymous-auth=false	CISA/NSA guidance
Audit-Logging	Aktivieren Sie API-Audit-, Metrik-, Anwendungs- und seccomp-Logs; aggregieren Sie sie außerhalb des Clusters und alarmieren Sie darauf	CISA/NSA guidance
etcd	Verschlüsseln Sie im Ruhezustand, verlangen Sie gegenseitiges TLS und isolieren Sie es hinter einer Firewall, die nur API-Server erreichen können	CIS Benchmark
kubelet	Beschränken Sie den API-Zugriff, deaktivieren Sie schreibgeschützte Ports und wenden Sie Konfigurationen auf Node-Ebene an	CIS Benchmark
Node-Baseline	Richten Sie Control Plane, etcd und Nodes am CIS Kubernetes Benchmark für Ihr Release aus; scannen Sie in kontinuierlicher Kadenz	CIS Benchmark
Versionen	Patchen Sie Kubernetes, das Node-Betriebssystem und die Container Runtime in regelmäßiger Kadenz	—

Mit abgesicherter Control Plane und gepatchten Nodes hält das Fundament. Eine laufende Workload kann dennoch von ihrem deklarierten Zustand abweichen oder von innen angegriffen werden, und Laufzeitkontrollen erkennen genau das.

Laufzeitsicherheit und Bedrohungserkennung

Starke Kubernetes-Laufzeitsicherheit erkennt, was statische Kontrollen nicht erkennen können.

1. Überwachen Sie das Laufzeitverhalten. Stellen Sie ein containernatives Laufzeitsicherheitstool bereit, das auf anomale Syscalls, unerwartete Prozessausführung, Netzwerkverbindungen und Dateimodifikationen achtet. NIST SP 800-190 stellt fest, dass herkömmliche Intrusion Prevention System (IPS)- und Web Application Firewall (WAF)-Tools keinen geeigneten Schutz für Container bieten.
2. Erkennen Sie Konfigurationsdrift. Vergleichen Sie laufende Workloads mit ihrem deklarierten Zustand in Git. Kennzeichnen Sie Container, die von ihrem ursprünglichen Image oder ihrer ursprünglichen Konfiguration abweichen.
3. Wenden Sie seccomp- sowie AppArmor- oder SELinux-Profile an. Verwenden Sie mindestens RuntimeDefault-seccomp-Profile. Rollen Sie benutzerdefinierte Profile zunächst auf einer Teilmenge von Nodes aus und erweitern Sie sie nach der Validierung clusterweit.
4. Verwenden Sie schreibgeschützte Root-Dateisysteme und entfernen Sie unnötige Capabilities. Setzen Sie readOnlyRootFilesystem: true und capabilities: drop: [ALL] für jeden Produktionscontainer.
5. Erzwingen Sie runAsNonRoot. Verlangen Sie runAsNonRoot: true in Pod-Sicherheitskontexten. Erstellen Sie Images so, dass sie bereits zur Build-Zeit als Nicht-Root-Benutzer ausgeführt werden, statt sich ausschließlich auf Überschreibungen zur Bereitstellungszeit zu verlassen.
6. Aktivieren Sie autonome Reaktion und kontinuierliches Audit-Logging. Korrelieren Sie Laufzeitalarme mit Audit-Logs, um Angriffstimeline zu rekonstruieren. Führen Sie Erkenntnisse in Build-Time-Richtlinien zurück, um den Kreislauf zu schließen.

Zusammen erzeugen diese vier Phasen einen kontinuierlich gehärteten Cluster. Branchen-Benchmarks beschreiben, wie „korrekt konfiguriert“ in jeder Phase aussieht, und Sie sollten Ihren Cluster daran messen.

Kubernetes-Sicherheitsstandards und Compliance

Branchenweit anerkannte Benchmarks operationalisieren die oben beschriebenen Praktiken und liefern die Audit-Nachweise, die Ihr Kubernetes-Compliance-Programm erfordert.

Standard	Umfang	Relevanz
CIS Kubernetes Benchmark	Control Plane, etcd, Worker-Nodes, Richtlinien	Anerkannt von PCI DSS, FedRAMP, SOC 2, FISMA und dem NIST National Checklist Program
CISA/NSA Kubernetes Hardening Guidance	Build, Bereitstellung, Netzwerk, RBAC, Logging, Laufzeit	Maßgebliche staatliche Baseline für Cluster in Behörden und kritischer Infrastruktur
Pod Security Standards	Einschränkungen von Privilegien auf Pod-Ebene über drei Stufen	In Kubernetes integrierter Durchsetzungsmechanismus; bildet Tabelle I der CISA/NSA guidance direkt ab
NIST SP 800-190	Sicherheit des Container-Lebenszyklus	Ordnet Container-Kontrollen NIST SP 800-53 Rev 5 zu (AU-2, CM-2, SC-7, IR-4 und weitere)

Da Kubernetes inzwischen die Standardplattform für die Produktion ist, behandeln Compliance-Frameworks Kubernetes-spezifische Kontrollen zunehmend als eigenständigen Audit-Bereich statt als Teilmenge allgemeiner Infrastruktursicherheit. 

Plattformspezifische Benchmarks wie der CIS GKE Benchmark und der CIS OpenShift Benchmark erweitern den allgemeinen Benchmark um Managed-Service-spezifische Kontrollen. Die Standards zu kennen, ist die Baseline. Die schwierigere Frage ist, wohin sich Kubernetes-Sicherheit als Nächstes entwickelt.

Zukünftige Trends in der Kubernetes-Sicherheit

Die Kontrollen, die Sie heute bereitstellen, stehen auf sich veränderndem Boden, und drei Trends verändern, wie Teams Kubernetes-Sicherheits-Best-Practices angehen.

1. KI-Workloads verschieben die Angriffsfläche. Da Cluster zum Standardstandort für KI- und Machine-Learning-Workloads werden, werden GPU-Planung, Modellartefakte und große Trainingsdatensätze zu neuen Zielen. Die Absicherung der Daten- und Modell-Supply-Chain wird Teil des Cluster-Hardening und kein separates Thema mehr.
2. Integrität der Software-Supply-Chain wird verpflichtend. SBOM-Erstellung, signierte Artefakte und Herkunftsnachweise entwickeln sich von optionalen Reifegradmerkmalen zu Baseline-Erwartungen in regulierten Branchen und bei staatlicher Beschaffung.
3. Autonome Laufzeitabwehr ersetzt manuelle Triage. Umfang und Geschwindigkeit der Clusteraktivität übersteigen die menschliche Prüfung. Verhaltensbasierte KI, die normale von anomaler Workload-Aktivität unterscheidet und reagiert, ohne auf einen Analysten zu warten, entwickelt sich vom Differenzierungsmerkmal zum Standard.

Jeder Trend weist in dieselbe Richtung: mehr Automatisierung früher im Lebenszyklus und mehr Autonomie in der Laufzeit, und genau dort beweist Plattform-Tooling seinen Wert.

Stärken Sie Kubernetes-Sicherheit mit SentinelOne

Die nativen Kubernetes-Kontrollen, die dieser Leitfaden behandelt, RBAC, NetworkPolicy, Pod Security Standards, etcd-Verschlüsselung und Audit-Logging, bilden die Grundlage des Cluster-Hardening. SentinelOne ergänzt darauf aufbauend Posture Management, Supply-Chain-Scanning, K8s Admission Control und Laufzeit-Bedrohungserkennung, jeweils einer Schwäche zugeordnet, die dieser Leitfaden benennt.

Singularity Cloud Security scannt Kubernetes-Cluster, bevor sie überhaupt laufen. Build-Time-Scanning integriert sich direkt in CI/CD-Pipelines, Versionskontrollsysteme und Container-Registries. Es prüft auf bekannte Schwachstellen und mehr als 750 Arten exponierter Secrets. Derselbe Scan deckt auch Infrastructure-ascode-Vorlagen ab, einschließlich Terraform, Helm, CloudFormation und Kubernetes YAML, um Richtlinienverstöße frühzeitig zu erkennen. Ein Kubernetes Admission Controller fungiert als letzter Gatekeeper am API-Server und blockiert nicht autorisierte oder bekanntermaßen bösartige Images, bevor sie bereitgestellt werden.

Kubernetes Security Posture Management (KSPM) schließt Sichtbarkeitslücken im gesamten Cluster. Es erstellt ein einheitliches Inventar über Cluster, Nodes, Namespaces und Deployments hinweg und macht dann übermäßig permissiven Zugriff und riskante Konfigurationen sichtbar. Die Offensive Security Engine™ simuliert anschließend reale Angriffe und bestätigt über Verified Exploit Paths™, welche Fehlkonfigurationen Angreifer tatsächlich erreichen können. Sicherheitsteams priorisieren das Ausnutzbare, statt jeden einzelnen Befund zu triagieren. Dieselbe Rules Engine betreibt auch den Admission Controller, sodass Richtlinien von der Sicherheitslage bis zur Bereitstellung konsistent bleiben.

Zur Laufzeit erkennt Singularity Cloud Workload Security, basierend auf extended Berkeley Packet Filter (eBPF), anomales Verhalten mit Maschinengeschwindigkeit. Automatisierte Reaktionen beenden bösartige Prozesse und stellen infizierte Dateien unter Quarantäne, ohne auf einen Analysten zu warten. Graph Explorer visualisiert Beziehungen über die Kubernetes-Angriffsfläche hinweg, sodass Teams genau sehen, was exponiert ist. Wenn die Laufzeiterkennung ein bösartiges Image kennzeichnet, wird dieser Befund automatisch an den Admission Controller zurückgeführt. Das Image wird dann für jede zukünftige Bereitstellung blockiert, wodurch aus einer einzelnen Erkennung eine dauerhafte Richtlinie wird. Purple AI bringt natürlichsprachige Threat Hunting-Abfragen und Ereigniszusammenfassungen in Ihre Cloud-Workload-Telemetrie auf einem einzigen Data Lake, sodass Analysten in natürlicher Sprache abfragen, statt zwischen Tools zu wechseln.

Sehen Sie, wo Ihre Cluster in der Produktion exponiert sind. Fordern Sie eine SentinelOne-Demo an, um Kubernetes Posture Management und Laufzeit-Bedrohungserkennung in Ihrer eigenen Umgebung durchzugehen.

Tour starten

KI-gestützter Cloud Workload-Schutz (CWPP) für Server, VMs und Container, der Laufzeitbedrohungen in Echtzeit erkennt und stoppt.

Wichtige Erkenntnisse

Kubernetes wird mit permissiven Standardeinstellungen ausgeliefert, die die Clustersicherheit in Ihre Hände legen. Die Kubernetes-Sicherheits-Best-Practices in diesem Leitfaden umfassen vier Phasen: Image-Scanning und -Signierung beim Build, RBAC und NetworkPolicy bei der Bereitstellung, etcd-Verschlüsselung und Audit-Logging in der Control Plane sowie verhaltensbasiertes Monitoring zur Laufzeit. 

Richten Sie Ihre Konfiguration am CIS Benchmark und an der CISA/NSA guidance aus, beseitigen Sie die oben identifizierten häufigen Fehler und schließen Sie den Kreislauf, indem Sie Laufzeitbefunde in Build-Time-Richtlinien zurückführen. Wenn Sie das erreichen, hören Sie auf zu raten. Sie können dann an jedem beliebigen Tag auf jeden Namespace zeigen und nachweisen, was durchgesetzt wurde, was abgewichen ist und was Sie dagegen unternommen haben.

FAQs

Welche Kubernetes-Einstellungen sind standardmäßig unsicher?

Drei Einstellungen werden auf jedem neuen Kubernetes-Cluster unsicher ausgeliefert. Die CISA/NSA Kubernetes Hardening Guidance v1.2 dokumentiert sie: anonyme API-Server-Anmeldung ist aktiviert, Secrets werden unverschlüsselt in etcd gespeichert und Audit-Logging ist deaktiviert. 

Die Pod-zu-Pod-Kommunikation ist ohne NetworkPolicy-Objekte uneingeschränkt. Sie müssen diese selbst härten. Weder der Cloud-Anbieter noch die Kubernetes-Distribution wenden diese Kontrollen im Rahmen des Shared-Responsibility-Modells für Sie an.

Was ist der Unterschied zwischen Kubernetes-Sicherheit und Containersicherheit?

Containersicherheit und Kubernetes-Sicherheit arbeiten auf unterschiedlichen Ebenen desselben Stacks. Containersicherheit konzentriert sich auf das Image und die Container-Instanz: Schwachstellenscans, Laufzeitisolierung, das Entfernen von Capabilities und den Schutz des Host-Kernels. 

Kubernetes-Sicherheit umfasst sowohl einzelne Container als auch den Cluster um sie herum und ergänzt RBAC, Admission Control, Netzwerkrichtlinien, etcd und Audit-Logging der Orchestrierung. Containersicherheit ist Teil der umfassenderen Kubernetes-Sicherheitsdisziplin.

Wie verhalten sich Pod Security Standards zu den veralteten Pod Security Policies?

Pod Security Policies (PSPs) wurden in Kubernetes v1.21 als veraltet eingestuft und in v1.25 entfernt. Pod Security Standards (PSS) definieren drei Richtlinienebenen (Privileged, Baseline, Restricted) und werden durch Pod Security Admission (PSA) durchgesetzt, einen integrierten Admission Controller, der Richtlinien auf Namespace-Ebene über Labels anwendet. 

PSA erreichte in v1.25 den stabilen Status. Wenn Ihr Cluster v1.25 oder höher ausführt und Sie PSA nicht konfiguriert haben, arbeiten Sie ohne die Durchsetzungsebene auf Pod-Ebene.

Welche Compliance-Benchmarks gelten für Kubernetes-Cluster?

Vier primäre Compliance-Frameworks gelten für Kubernetes-Cluster. Der CIS Kubernetes Benchmark wird von PCI DSS, FedRAMP, SOC 2 und FISMA anerkannt. Die CISA/NSA Kubernetes Hardening Guidance dient als staatliche Baseline. 

NIST SP 800-190 ordnet Container-Kontrollen den Kontrollfamilien von NIST SP 800-53 Rev 5 zu. Pod Security Standards stellen den integrierten Durchsetzungsmechanismus bereit, der direkt der CISA/NSA-Richtlinie zugeordnet ist.

Übernehmen verwaltete Dienste wie EKS, AKS und GKE die Clustersicherheit für Sie?

Verwaltete Kubernetes-Services übernehmen die Verfügbarkeit der Control Plane, das Patchen und einen Teil der Infrastruktursicherheit. Sie sind weiterhin für RBAC-Richtlinien, NetworkPolicy-Objekte, Pod Security Admission, Secrets-Verschlüsselung und Runtime-Monitoring verantwortlich. 

Das Modell der geteilten Verantwortung gilt: Der Anbieter sichert die Infrastruktur der Control Plane, und Sie sichern die Workloads, die Konfiguration und die Zugriffskontrollen. Plattformspezifische CIS Benchmarks dokumentieren die zusätzlichen Kontrollen, die Sie bei jedem verwalteten Service anwenden müssen.