Ihr habt containerisiert. Aber läuft euer Container als root?
Containerisierung und Container-Sicherheit sind nicht dasselbe. Das Deployment-Problem ist gelöst. Das Security-Modell wurde nicht mitgenommen.
Das Base-Image stammt aus Docker Hub, zuletzt aktualisiert vor 18 Monaten, 47 bekannte CVEs. Kein Seccomp-Profil. Kein SBOM. Capabilities nicht reduziert. Das ist die neue Legacy, nur schneller gewachsen als die alte. Secure Container Platform Automation adressiert was Container-Laufzeiten nicht automatisch liefern.
Die Container-Härtungs-Lücke
Containerisierung löst ein Deployment-Problem. Sie löst kein Sicherheitsproblem. Beides wird zu oft gleichgesetzt, und das ist der Punkt, an dem die Angriffsfläche unbemerkt wächst.
- Reproduzierbare Deployments über Umgebungen hinweg
- Isolierung von Laufzeitabhängigkeiten
- Skalierbarkeit und schnellere Rollouts
- Einheitliches Packaging-Format nach OCI-Standard
- Portabilität zwischen Docker, Podman und Kubernetes
- Rootless-Konfiguration: Container läuft standardmäßig als root
- Seccomp-Profil: alle Kernel-Syscalls erlaubt, nicht nur die nötigen
- Linux Capability Drops: CAP_SYS_ADMIN und CAP_NET_ADMIN bleiben aktiv
- SBOM: kein Überblick welche Pakete mit welchen Versionen im Image sind
- Image-Policy: Docker Hub ohne CVE-Tracking und ohne Lifecycle
Was eine sichere Container-Baseline enthält
Fünf technische Ebenen, die zusammen ein belastbares Sicherheitsmodell für Container-Umgebungen ergeben. Jede Ebene adressiert eine spezifische Angriffsfläche.
Container laufen ohne root-Rechte auf dem Host-System. Docker und Podman unterstützen rootless Betrieb. Ein kompromittierter Container hat damit keinen privilegierten Host-Zugriff.
Kernel-Syscall-Filterung: Nur die Systemaufrufe werden erlaubt, die der Container tatsächlich benötigt. Alle anderen Calls sind blockiert. Das reduziert die Angriffsfläche auf Kernel-Ebene erheblich.
CAP_NET_ADMIN, CAP_SYS_ADMIN und CAP_SYS_PTRACE werden entfernt. Der Container erhält ausschließlich die Berechtigungen, die seine Funktion tatsächlich erfordert.
Software Bill of Materials für jedes Image: vollständige Paketliste, Versionen und CVE-Zuordnung. Bei einem Incident weiß das Team sofort, welche Pakete im Image waren und welche betroffen sind.
Nur intern geprüfte Images kommen in Produktion. Keine ungeprüften Basis-Images aus öffentlichen Registries. Base-Image-Lifecycle mit definiertem Update-Rhythmus und CVE-Tracking.
Wo Container-Sicherheitsprojekte heute starten
VM zu Container: Security-Modell nicht mitgenommen
Die Migration ist abgeschlossen, die Anwendung läuft im Container. Das Security-Modell der VM-Welt wurde auf das neue Deployment-Format übertragen, aber Container-spezifische Härtung fehlt vollständig. Rootless war "zu komplex". Seccomp ist unbekannt.
Docker Hub als primäre Image-Quelle
Basis-Images kommen direkt aus Docker Hub, teils zuletzt vor vielen Monaten aktualisiert. Keine eigene Registry, kein CVE-Tracking, keine Policy die festlegt welche Images produktionsreif sind. Die CVE-Last ist unbekannt.
CI/CD pusht direkt aus öffentlichem Base-Image
Die Build-Pipeline zieht das Basis-Image aus einer öffentlichen Registry und deployed es ohne Gate in Produktion. Kein Scan, kein SBOM. Was tatsächlich in Produktion landet, ist nicht vollständig bekannt.
OCI-Images aus dem Policy-Modell
GIaaS (Golden Image as a Service) kann Container-Images als Lieferformat produzieren. Die Härtungs-Policy wird einmal definiert, der Build-Prozess ist automatisiert, das Ergebnis ist ein OCI-konformes Image, das versioniert und mit Metadata ausgestattet in die interne Registry gepusht wird.
Härtungsanforderungen, Capability-Drops, Seccomp-Profil und zugelassene Pakete werden als Code formuliert und versioniert.
Das Image wird automatisiert gebaut und gegen die Policy geprüft. CVE-Treffer stoppen den Build. Das Ergebnis ist nachvollziehbar und reproduzierbar.
Das gehärtete Image wird versioniert mit SBOM und Metadata in die interne Registry gepusht oder direkt als Download bereitgestellt.
Container-Härtung heute. Kubernetes-ready morgen.
Container ist die Vorstufe im SPAS-Modulpfad. Was als rootless Container, Seccomp-Profil und OCI-Image aufgebaut wird, ist die direkte Grundlage für sichere Kubernetes-Deployments. Kein Neueinstieg, kein Bruch in der Sicherheitsarchitektur.
Secure Kubernetes Platform AutomationKonzept, nicht Warteschleife
Das Modul befindet sich in der Konzeptphase. Logik und Zielarchitektur sind klar. Die technische Umsetzung wird entlang konkreter Kundenanforderungen ausgearbeitet.
Was heute möglich ist: Beratung zur Container-Sicherheitsarchitektur über EaaS, Bewertung der eigenen Container-Landschaft und Planung des Härtungspfades.
- EaaS für Container-Sicherheitsprojekte
- Architekturberatung zur Container-Härtung
- Bewertung der bestehenden Image-Policy und Registry-Situation
- Planung des Migrationspfades von VM zu gehärtetem Container
- NIS2, CIS Docker Benchmark und ISO 27001 als Orientierungsrahmen
Dieses Modul ist in Konzeptentwicklung
Die Zielarchitektur ist definiert. Die Umsetzung erfolgt entlang realer Anforderungen. Wenn Container-Sicherheit auf Ihrer Roadmap steht, sprechen Sie uns an. Wir priorisieren nach konkretem Bedarf.
→ GIaaS: Golden Image as a ServiceContainer-Sicherheit auf der Roadmap? Wir ordnen ein, was heute möglich ist.
Unverbindlich · Keine Verkaufspräsentation · Vertraulich
