Container härten: So bekommst du Docker und Podman sicher in den Griff

Auf einem klassischen Server weißt du, wo du ansetzt: Dienste abschalten, nftables konfigurieren, SELinux im Enforcing-Modus betreiben, Updates einspielen. Bei Containern verschiebt sich ein großer Teil dieser Verantwortung nach vorne in das Image und nach hinten in die Runtime. Ein Image, das vor acht Monaten gebaut wurde, enthält den Patch-Stand von vor acht Monaten, unabhängig davon, wie gut der Host gepflegt ist. Und ein Container, der mit --privileged oder mit gemountetem Docker-Socket startet, hebelt die Isolation weitgehend aus, egal wie sauber das Image war.

Typisch sind immer wieder dieselben Muster. Der Prozess im Container läuft als root, weil das Basis-Image keinen USER setzt und niemand es nachgeholt hat. Als Basis dient ein vollständiges Distributionsimage mit Paketmanager, Shell und Build-Werkzeugen, obwohl die Anwendung ein statisches Binary ist. Secrets landen als ARG oder als Umgebungsvariable im Layer und lassen sich später aus dem Image herauslesen. Container hängen alle im Default-Bridge-Netz und können sich gegenseitig erreichen. Das Rootfs ist beschreibbar, Capabilities werden nicht reduziert, und ob ein Prozess zur Laufzeit plötzlich eine Shell startet, merkt niemand.

Der Druck kommt inzwischen nicht mehr nur aus dem Betrieb. NIS2 und der Cyber Resilience Act stellen Anforderungen an Schwachstellenmanagement und an die Nachvollziehbarkeit der Software-Lieferkette. Damit wird die Frage, welche Komponenten in welcher Version in einem ausgelieferten Image stecken, von einer Fleißaufgabe zu einer Nachweispflicht. Eine SBOM pro Build und ein reproduzierbarer Scan-Bericht sind dann keine Kür mehr.