Was ist Container- und Kubernetes-Sicherheit?
Container- und Kubernetes-Sicherheit umfasst die Absicherung containerisierter Anwendungen und der Kubernetes-Plattform über den gesamten Lebenszyklus – von Images und Lieferkette bis zu Cluster, Laufzeit und Host.
Die technische Arbeitsdefinition verbindet zwei Ebenen: Container-Sicherheit betrachtet insbesondere Image, Registry, Orchestrator, Container Runtime und Host-Betriebssystem. Bei Kubernetes kommen vor allem Control Plane, API-Zugriffe, Identitäten und Berechtigungen, Secrets, Workloads, Netzwerk sowie Admission Control hinzu. Kubernetes orchestriert containerisierte Workloads und ist nicht mit einem Container gleichzusetzen. Der Begriff selbst gibt keine einheitliche Kontrolltechnik vor.
Welche technische Grundlage bestimmt Container- und Kubernetes-Sicherheit?
Für die technische Einordnung beschreibt NIST SP 800-190 Risiken und Gegenmaßnahmen entlang der Container-Komponenten und ihres Lebenszyklus. Die offizielle Kubernetes-Dokumentation konkretisiert die Sicherheitsmechanismen und Konfigurationsfragen der Orchestrierungsplattform. Daraus ergibt sich eine technische Arbeitsdefinition, kein einheitlich normierter Rechtsbegriff und keine allein aus dem Begriff folgende allgemeine Rechtspflicht.
Die Quellen sind als unterschiedliche Aussagearten zu lesen: NIST strukturiert Risiken und technische Gegenmaßnahmen; die Kubernetes-Projektdokumentation beschreibt Funktionen, Voraussetzungen und empfohlene Konfigurationen. Welche Kontrollen im Einzelfall angemessen sind, hängt von Architektur, Schutzbedarf, Integrationen und Verantwortungsgrenzen ab.
Welche Bereiche müssen abgesichert werden?
Der sachliche Umfang reicht vom Erstellen und Beziehen eines Images über dessen Speicherung in einer Registry und die Bereitstellung durch einen Orchestrator bis zur Ausführung in der Container Runtime auf dem Host. Bei Kubernetes sind zusätzlich Control Plane und Knoten, API-Zugriffe, Authentisierung und Autorisierung, Secrets, Workload-Isolation, Netzwerkpfade und Admission Control gemeinsam zu betrachten.
Adressiert sind Entwicklungs-, Plattform-, Betriebs- und Sicherheitsteams, sobald sie für einen dieser Bestandteile verantwortlich sind oder Kubernetes betreiben. Kubernetes-spezifische Kontrollen setzen einen Kubernetes-Cluster voraus. Container-Sicherheit ist jedoch nicht auf Kubernetes beschränkt, und Kubernetes ersetzt keine Kontrollen für Images, Runtime oder Hosts.
Wann werden Sicherheitskontrollen relevant?
Kontrollen werden beim Erstellen, Beziehen, Speichern, Bereitstellen und Ausführen von Images oder Workloads relevant. Weitere Auslöser sind das Konfigurieren von API-Zugriffen, Rollen, Service Accounts, Secrets und Kommunikationswegen. Verantwortlich sind dabei insbesondere Clusteradministration und Workload-Teams.
Die konkrete Auswahl ist risiko- und funktionsbezogen: Least Privilege begrenzt Rollen und Service Accounts auf tatsächlich benötigte Rechte. NetworkPolicies entfalten nur dann Wirkung, wenn die eingesetzte Netzwerklösung ihre Durchsetzung unterstützt. Nicht jede Kontrolle ist bei jedem Deployment technisch einschlägig; zusätzliche Komponenten des Kubernetes-Ökosystems müssen gezielt ausgewählt, integriert und betrieben werden.
Welche Grenzen hat die Container-Isolation?
Container bieten Prozessisolation gegenüber dem Host, sind aber nicht automatisch eine VM-gleichwertige oder vollständige Sicherheitsgrenze. Privilegierte Einstellungen, zusätzliche Capabilities sowie Zugriffe auf Host-Namespaces, HostPath oder andere Host-Ressourcen können die Trennung erheblich schwächen. Die tatsächlich erreichte Isolation hängt von Runtime, Host-Konfiguration und Workload-Einstellungen ab.
Ein Image-Scanner oder ein sicheres Basis-Image bleibt als Einzelkontrolle sinnvoll, deckt jedoch fehlerhafte Laufzeit-, Identitäts-, Netzwerk-, Cluster- oder Host-Konfigurationen nicht ab. Erweiterungen des Kubernetes-Ökosystems können fehlende Kernfunktionen ergänzen; sie werden dadurch aber selbst zu Komponenten, die ausgewählt, konfiguriert und betrieben werden müssen.
Wie sind Kubernetes Secrets und Pod-Sicherheit einzuordnen?
Secrets sind nicht automatisch vertraulich gespeichert: Nach der offiziellen Kubernetes-Dokumentation liegen Secret-Daten im zugrunde liegenden Datenspeicher des API-Servers standardmäßig unverschlüsselt vor. Verschlüsselung ruhender Daten und eng begrenzte Zugriffe müssen daher konfiguriert werden. Auch Zugriffe auf Pods sind so einzuschränken, dass nur benötigte Container und Identitäten Secrets verwenden können.
Pod Security Standards definieren abgestufte Profile für sicherheitsrelevante Pod-Einstellungen, benötigen aber einen geeigneten Durchsetzungsmechanismus. Das Restricted-Profil zielt auf eine starke Härtung, kann jedoch legitime Workloads beeinträchtigen und Anpassungen erfordern. Es ersetzt keine Absicherung von Cluster, Netzwerk, Identitäten, Images oder Hosts.
Welche Fristen oder Schwellenwerte gelten?
Der allgemeine technische Begriff enthält keine einheitliche Frist, keinen einheitlichen Startpunkt und keinen numerischen Schwellenwert. Ziele für Patches, Scans, Rotation und Reaktion sind risiko- und organisationsbezogen festzulegen. Die Kubernetes Security Checklist empfiehlt aktuelle Komponenten, nennt dafür aber keine allgemeingültige Zahl oder Frist.
Verträge, interne Regeln, regulatorische Anforderungen oder produktspezifische Vorgaben können für einen konkreten Einsatz eigene Zeitziele oder Schwellenwerte setzen. Solche Vorgaben stammen nicht aus der technischen Definition der Container- und Kubernetes-Sicherheit und müssen für den jeweiligen Einsatz gesondert ermittelt werden.
Häufige Fehlannahmen
- „Kubernetes und Container sind dasselbe.“ Nein. Container paketieren und isolieren Anwendungen; Kubernetes orchestriert containerisierte Workloads und Dienste.
- „Ein Container ist automatisch eine vollständige Sicherheitsgrenze.“ Nein. Privilegien, Capabilities und Host-Zugriffe können die Isolation erheblich schwächen.
- „Ein Image-Scan deckt die Container-Sicherheit ab.“ Nein. Scans erfassen nicht sämtliche Risiken in Identitäten, Netzwerk, Cluster, Runtime und Host.
- „NetworkPolicies wirken in jedem Cluster automatisch.“ Nein. Ihre Durchsetzung setzt eine Netzwerklösung voraus, die NetworkPolicies unterstützt.
- „Kubernetes Secrets sind standardmäßig verschlüsselt gespeichert.“ Nein. Die Verschlüsselung ruhender Secret-Daten muss konfiguriert werden.
- „Das Restricted-Profil löst die gesamte Kubernetes-Sicherheit.“ Nein. Es betrifft Pod-Einstellungen, benötigt Durchsetzung und kann Anpassungen legitimer Workloads erfordern.
Was die Geschäftsleitung tun sollte
Die folgenden Schritte sind technische und organisatorische Empfehlungen. Ihre Ausgestaltung und Priorisierung richten sich nach Architektur, Schutzbedarf und Verantwortungsgrenzen; die Quellen schreiben weder ein bestimmtes Produkt noch eine universelle Kontrolltechnik vor.
- Verantwortung festlegen: Eigentümerschaft für Image-Lieferkette, Registry, Cluster, Workloads, Runtime und Hosts eindeutig Entwicklungs-, Plattform-, Betriebs- und Sicherheitsteams zuordnen.
- Lebenszyklus absichern: Kontrollen für Build, Bezug, Speicherung, Bereitstellung und Ausführung von Images veranlassen und Kubernetes-Komponenten aktuell halten.
- Zugriffe begrenzen: Least-Privilege-RBAC für Personen und Service Accounts vorgeben und Berechtigungen regelmäßig überprüfen lassen.
- Secrets schützen: Verschlüsselung ruhender Secret-Daten konfigurieren und Secret-Zugriffe auf die tatsächlich benötigten Identitäten, Pods und Container beschränken.
- Kommunikationswege kontrollieren: Erforderliche Netzwerkpfade bestimmen, unnötigen Verkehr begrenzen und prüfen, ob die eingesetzte Netzwerklösung Policies tatsächlich durchsetzt.
- Laufzeit beherrschen: Überwachung und Reaktion für Workloads, Cluster und Hosts etablieren und privilegierte Einstellungen sowie Host-Zugriffe besonders prüfen.
Für die Geschäftsleitung
Container- und Kubernetes-Sicherheit reicht von der Softwarelieferkette bis zum laufenden Host und verlangt abgestimmte Zuständigkeiten über Entwicklung, Betrieb und Sicherheit hinweg. Zu entscheiden sind Prioritäten und Risikotoleranz für Images, Zugriffe, Secrets, Netzwerk, Cluster, Runtime und Hosts. Als Nachweis eignen sich dokumentierte Eigentümerschaft, begründete Kontrollauswahl, überprüfte RBAC-Zuweisungen, konfigurierte Secret-Verschlüsselung, nachweislich durchgesetzte Netzwerkregeln sowie nachvollziehbare Aktualisierungs-, Überwachungs- und Reaktionsprozesse.
Quellen
- NIST SP 800-190: Application Container Security Guide, insbesondere Abstract sowie Abschnitte 2 bis 4.
- Kubernetes-Dokumentation: Overview / What is Kubernetes?
- Kubernetes-Dokumentation: Security
- Kubernetes-Dokumentation: Security Checklist
- Kubernetes-Dokumentation: Pod Security Standards
- Kubernetes-Dokumentation: Network Policies, insbesondere Voraussetzungen.
- Kubernetes-Dokumentation: Secrets
- Kubernetes-Dokumentation: RBAC Good Practices
