Container haben die Auslieferung von Software grundlegend verändert: Anwendungen wandern samt Abhängigkeiten als standardisierte Images durch die Pipeline und starten in Sekunden. Dieselben Eigenschaften, die Container so effizient machen, verlangen jedoch ein eigenes Sicherheitsmodell. Ein verwundbares Basis-Image vervielfältigt sich mit jedem Build, und sämtliche Container eines Hosts teilen sich denselben Betriebssystem-Kernel.
Was ist Container-Sicherheit?
Container-Sicherheit umfasst alle Maßnahmen, die containerisierte Anwendungen über ihren Lebenszyklus schützen: beim Bau des Images, bei der Ablage in der Registry und im laufenden Betrieb. Der entscheidende Unterschied zu klassischen Servern liegt im Modell der Unveränderlichkeit. Ein Container wird zur Laufzeit idealerweise nie verändert; Korrekturen entstehen als neues Image und durchlaufen erneut alle Prüfungen der Pipeline. Sicherheit verlagert sich damit nach vorn in den Build-Prozess, wo sich Fehler am günstigsten beheben lassen. Zugleich bleibt die Laufzeit relevant: Erst dort zeigt sich, ob ein Container tut, was sein Image verspricht, oder ob ihn jemand zweckentfremdet. Technische Grundlage ist der offene OCI-Standard, der Aufbau und Austauschformat von Images definiert; Prüfwerkzeuge und Registries setzen darauf auf und bleiben dadurch untereinander kombinierbar.
So funktioniert es
Der Schutz folgt dem Weg eines Images durch die Umgebung:
- Schlanke Basis-Images: Minimale, gepflegte Images reduzieren die Angriffsfläche spürbar. Jede zusätzliche Bibliothek bringt potenzielle Schwachstellen mit, die später gescannt, bewertet und behoben werden müssen.
- Scanning in der Pipeline: Automatisierte Prüfungen untersuchen jedes Image auf bekannte Schwachstellen und blockieren kritische Funde vor dem Deployment. Eine Software-Stückliste (SBOM) dokumentiert, was genau im Image steckt.
- Registry-Schutz: In Produktion gelangen ausschließlich signierte Images aus der eigenen, zugriffsgeschützten Registry. Signaturen stellen sicher, dass zwischen Build und Deployment niemand manipuliert hat.
- Minimale Rechte zur Laufzeit: Container laufen ohne Root-Rechte, mit schreibgeschütztem Dateisystem und ohne Durchgriff auf den Host. Was eine Anwendung nicht braucht, wird ihr gar nicht erst eingeräumt.
- Laufzeitüberwachung: Verhaltensregeln erkennen Abweichungen vom erwarteten Muster, etwa einen unerwarteten Prozessstart in einem produktiven Container. Solche Signale deuten auf Ausnutzung einer Schwachstelle hin.
- Isolation nach Bedarf: Namespaces und Cgroups trennen Container voneinander. Wo höhere Anforderungen gelten, ergänzen Sandbox-Laufzeiten oder dedizierte Hosts die Trennung, etwa bei strikten Mandantengrenzen.
Warum es wichtig ist
- Multiplikation von Schwachstellen: Ein Fehler im Basis-Image landet in jedem daraus gebauten Dienst. Umgekehrt wirkt ein zentraler Scan entsprechend weit.
- Geteilter Kernel: Ein Kernel-Exploit aus einem Container heraus gefährdet alle Nachbarn auf demselben Host. Minimale Rechte und saubere Isolation begrenzen dieses Risiko.
- Tempo der Pipeline: Deployments im Stunden- oder Minutentakt lassen keine manuellen Freigaben zu. Prüfungen müssen automatisiert mitlaufen, um Schritt zu halten.
- Öffentliche Lieferkette: Basis-Images und Pakete stammen häufig aus öffentlichen Registries, deren Pflegezustand stark schwankt. Herkunftsnachweise werden damit zur Pflicht.
- Flüchtige Spuren: Beendete Container hinterlassen wenig forensisches Material. Protokolle und Ereignisdaten müssen den Container überleben, sonst fehlt nach Vorfällen jede Grundlage.
Typische Szenarien
Häufig beginnt das Thema mit der ersten containerisierten Kernanwendung: Der etablierte Prozess für Server-Patching passt plötzlich nicht mehr, und die Verantwortung wandert in Richtung Build-Pipeline. Ein zweites Szenario ist die Absicherung von CI/CD selbst, denn wer die Pipeline kompromittiert, verteilt Schadcode automatisiert in die Produktion. Auch die Konsolidierung mehrerer Anwendungen auf einer gemeinsamen Plattform gehört dazu; hier entscheiden Isolation und Rechtekonzept darüber, ob sich Mandanten gegenseitig gefährden. Und wenn eine kritische Schwachstelle in einer weit verbreiteten Bibliothek bekannt wird, zeigt sich der Wert einer SBOM: Betroffene Images sind in Minuten identifiziert statt in Tagen. In regulierten Branchen kommt die Nachweispflicht hinzu: Herkunft und Prüfstand jedes Images müssen sich belegen lassen, inklusive dokumentierter Freigaben.
Container und virtuelle Maschinen: zwei Sicherheitsmodelle
Eine virtuelle Maschine bringt ihr eigenes Betriebssystem mit, und der Hypervisor zieht eine harte Grenze zwischen den Gästen. Container teilen sich dagegen den Kernel des Hosts; die Trennung übernehmen Mechanismen des Betriebssystems. Das macht Container leichtgewichtig und schnell, die Isolationsgrenze ist jedoch dünner als bei einer VM. Dafür punktet das Container-Modell an anderer Stelle: Unveränderliche Images ersetzen das Patchen laufender Systeme, jede Änderung durchläuft die Pipeline samt aller Prüfungen. Virtuelle Maschinen altern im Betrieb, Container werden neu gebaut. In der Praxis kombinieren viele Umgebungen beide Modelle und trennen besonders kritische Workloads zusätzlich über VM-Grenzen. Für die Risikobewertung zählt deshalb weniger, welches Modell pauschal sicherer ist, als die Frage, welche Isolationsgrenze ein konkreter Workload tatsächlich braucht.
Umsetzung mit KAEMI
KAEMI verankert Container-Sicherheit an zwei Hebeln: Über Application Security werden Anwendungen und ihre Auslieferungswege abgesichert, von der Prüfung der Images bis zum Schutz der laufenden Dienste. Mit Zero-Trust-Mikrosegmentierung kontrolliert KAEMI zusätzlich die Kommunikation zwischen Containern, virtuellen Maschinen und klassischen Servern, damit ein kompromittierter Dienst isoliert bleibt. Für eine Einschätzung Ihrer Umgebung erreichen Sie uns über Kontakt .