Container Security: So sichern Sie Kubernetes im Produktivbetrieb ab
1. Oktober 2026
Ein Datenleck bleibt weltweit im Schnitt 247 Tage bestehen, 183 davon unentdeckt. Das zeigt der Cost of a Data Breach Report 2026 von IBM. Deutsche Unternehmen reagieren schneller: Sie entdecken ein Leck nach durchschnittlich 121 Tagen und schließen es nach weiteren 39. Ein Vorfall kostet sie im Schnitt 4,25 Millionen Euro. Der häufigste Angriffsvektor in Deutschland ist die kompromittierte Lieferkette mit 17 Prozent der Fälle.
Container-Plattformen wie Kubernetes stehen im Zentrum vieler dieser Lieferketten. Sie bündeln Anwendungen, fremde Softwarekomponenten und Zugangsdaten auf einer gemeinsamen Infrastruktur. In der Grundeinstellung ist Kubernetes auf schnelle Bereitstellung ausgelegt: Anwendungen dürfen frei miteinander kommunizieren, Zugangsdaten sind nur einfach kodiert, Berechtigungen fallen oft großzügig aus. Container Security in Produktion heißt, diesen Ausgangszustand gezielt einzuschränken. Welcher Weg dorthin passt, hängt von Betriebsmodell, internen Ressourcen und regulatorischen Anforderungen ab.
Wo Container-Umgebungen angreifbar sind
Software-Lieferkette: Container enthalten neben dem eigenen Code fremde Komponenten wie Basis-Images und Open-Source-Bibliotheken. Eine Schwachstelle in einer dieser Komponenten wird zur Schwachstelle der eigenen Anwendung.
Plattform-Konfiguration: Die Einstellungen des Clusters legen fest, was erlaubt ist. Laut IBM gingen 27 Prozent der Datenlecks mit Bezug zu KI-Anwendungen auf Fehlkonfigurationen in der Cloud zurück.
Laufender Betrieb: Auch ein geprüfter Container bleibt über Schwachstellen in der Anwendung angreifbar. Ohne Überwachung bleibt unsichtbar, was nach einem Einstieg passiert.
Identitäten und Berechtigungen: Menschen, Pipelines und Anwendungen greifen auf die Plattform zu. Zu weit gefasste Rechte vergrößern den Schaden eines einzelnen kompromittierten Zugangs.
Sechs Prinzipien für eine sichere Kubernetes-Umgebung
01 / Lieferkette kontrollieren: Jedes Container-Image wird vor dem Einsatz automatisch auf bekannte Schwachstellen geprüft. Eine Software-Stückliste (SBOM) dokumentiert, welche Komponenten in welcher Anwendung stecken. Wird eine kritische Lücke bekannt, ist in kurzer Zeit klar, welche Systeme betroffen sind. Im Cluster läuft nur, was die eigene Build-Pipeline freigegeben hat.
02 / Sicherheitsstandards verbindlich machen: Kubernetes bringt mit den Pod Security Standards abgestufte Sicherheitsprofile mit. Für produktive Umgebungen gilt das strengste Profil als Vorgabe, Ausnahmen werden dokumentiert. Richtlinien prüfen jede Änderung vor der Bereitstellung automatisch. Abweichungen fallen damit vor dem Go-live auf. Sicherheit wird damit Teil des Bereitstellungsprozesses.
03 / Zugriffe minimieren: Jede Person und jede Anwendung erhält nur die Rechte, die sie für ihre Aufgabe braucht. Menschliche Zugriffe laufen über das zentrale Identity und Access Management des Unternehmens. So greifen bestehende Prozesse wie Rollenvergabe und Offboarding auch für die Container-Plattform.
04 / Kommunikation begrenzen: Anwendungen im Cluster kommunizieren nur mit den Diensten, die sie tatsächlich benötigen. Diese Segmentierung verhindert, dass sich ein Angreifer nach dem Einstieg ungehindert ausbreitet.
05 / Zugangsdaten schützen: Passwörter, Zertifikate und Schlüssel liegen verschlüsselt in einem separaten System zur Schlüsselverwaltung. Für die Souveränität zählt, wer diese Schlüssel verwaltet. Liegen sie beim selben Anbieter wie die Plattform, kontrolliert dieser Anbieter beides.
06 / Angriffe im Betrieb erkennen: Eine Laufzeitüberwachung meldet ungewöhnliches Verhalten in Containern, etwa unerwartete Netzwerkverbindungen oder manuelle Eingriffe in Produktionssysteme. Wie groß die Erkennungslücke in Unternehmen ist, zeigt die Studie Wirtschaftsschutz 2026 von Bitkom: 29 Prozent der 1.003 befragten Unternehmen gelten als vermutlich betroffen, ohne einen Angriff sicher nachweisen zu können. Im Schnitt der Jahre 2021 bis 2025 lag dieser Anteil bei 10 Prozent. Wirksam wird Überwachung erst mit klaren Zuständigkeiten und Reaktionswegen.
Drei Betriebsmodelle im Vergleich
Die Prinzipien gelten in jedem Betriebsmodell. Unterschiedlich ist, wer sie umsetzt und verantwortet. Die Absicherung der eigenen Anwendungen bleibt grundsätzlich beim Unternehmen, sofern der Vertrag nichts anderes regelt.
| Kriterium | Self-Managed Kubernetes | Managed Kubernetes (europäischer Anbieter) | Kubernetes-Dienst eines US-Hyperscalers |
| Kontrolle über die Plattform | Vollständig | Hoch, vertraglich geregelt | Auf Konfigurationsoptionen begrenzt |
| Eigener Personalbedarf | Hoch, inklusive Betrieb rund um die Uhr | Gering bis mittel | Mittel |
| Härtung und Updates der Plattform | Eigenes Team | Anbieter | Anbieter |
| Absicherung der Anwendungen | Eigenes Team | Je nach Vertrag geteilt | Eigenes Team |
| Schlüsselverwaltung | Frei wählbar | Je nach Anbieter extern möglich | Primär beim Anbieter |
| Rechtsraum | Eigener | EU-Recht | Zusätzlich US-Recht (CLOUD Act) |
Self-Managed Kubernetes passt, wenn ein erfahrenes Plattformteam vorhanden ist und maximale Kontrolle gefordert ist. Managed Kubernetes entlastet interne Teams beim Plattformbetrieb. Entscheidend für die Auswahl sind Rechtsraum, Schlüsselverwaltung und der vertraglich vereinbarte Sicherheitsumfang. Hyperscaler-Dienste bieten ein breites Service-Ökosystem und binden die Plattform an einen Anbieter, der zusätzlich US-Recht unterliegt. Die Modelle lassen sich kombinieren: Regulatorisch sensible Workloads laufen auf einer souveränen Plattform, standardisierte Anwendungen in der Public Cloud. Voraussetzung sind einheitliche Sicherheitsstandards über alle Umgebungen hinweg.
Dieselbe Abwägung gilt bei den Sicherheitswerkzeugen. Einzelwerkzeuge halten Betriebsdaten in der eigenen Umgebung und erfordern Integrationsaufwand. Integrierte Sicherheitsplattformen reduzieren diesen Aufwand und verlagern die Daten zum Plattformanbieter. Einen Überblick über Betriebsmodelle gibt die Seite Managed Kubernetes Services.
Regulatorik als Entscheidungsrahmen
Die NIS2-Richtlinie verlangt in Artikel 21 Maßnahmen zur Sicherheit der Lieferkette und zum Umgang mit Schwachstellen. Für Container-Umgebungen bedeutet das: Software-Stücklisten, automatisierte Prüfungen und dokumentierte Update-Prozesse. Die Nachweispflicht bleibt beim Unternehmen, auch wenn ein Anbieter den Betrieb übernimmt. Nachweise und Zugriff auf Protokolle gehören deshalb in den Vertrag.
Der Cyber Resilience Act verpflichtet Hersteller zur Dokumentation ihrer Softwarebestandteile. Als Prüfmaßstab im deutschsprachigen Raum dienen die BSI-Grundschutz-Bausteine SYS.1.6 Containerisierung und APP.4.4 Kubernetes.
Fazit: Absicherung schrittweise einführen
Die sechs Prinzipien lassen sich nicht gleichzeitig umsetzen. Am Anfang steht eine Bestandsaufnahme gegen einen anerkannten Standard wie BSI-Grundschutz. Danach folgen verbindliche Sicherheitsstandards, minimale Zugriffsrechte und Segmentierung, weil sie die Ausbreitung eines Angriffs direkt begrenzen. Im dritten Schritt wird die Lieferkette abgesichert, zuletzt die Erkennung im Betrieb, sobald Zuständigkeiten für die Reaktion stehen. Parallel fällt die Entscheidung über das Betriebsmodell. Sie bestimmt, welche Aufgaben das eigene Team trägt, wo Schlüssel und Betriebsdaten liegen und unter welchem Recht die Plattform läuft.
