Container Security: Images härten und Runtime schützen

Die Container-Sicherheitskette

Container-Security beginnt beim Base Image und endet bei der Runtime-Überwachung. Jede Stufe bietet Angriffsfläche — und jede Stufe kann abgesichert werden.

Build-Phase: Images härten

• Minimale Base Images: Distroless oder Alpine statt Ubuntu — weniger Packages, weniger Angriffsfläche.
• Non-Root User: Container sollten nie als Root laufen. Definieren Sie einen unprivilegierten User im Dockerfile.
• Read-Only Filesystem: Setzen Sie das Root-Filesystem auf Read-Only und mounten Sie beschreibbare Verzeichnisse explizit.
• No Latest Tag: Pinnen Sie Base Image Versionen auf spezifische Digests für reproduzierbare Builds.

Registry-Phase: Images scannen

• Admission Controller: Kubernetes Admission Webhooks können unsignierte oder ungescannte Images blockieren.
• Image Signing: Cosign oder Notary stellen sicher, dass nur verifizierte Images deployed werden.

Runtime-Phase: Überwachen und einschränken

• Security Contexts: Kubernetes Security Contexts erzwingen Non-Root, Read-Only Filesystems und Capability Drops.
• Pod Security Standards: Die drei Levels Privileged, Baseline und Restricted als Namespace-weite Richtlinien.
• Runtime Security: Falco oder Sysdig erkennen verdächtiges Verhalten in laufenden Containern.

Fazit

Container-Security ist kein Produkt, sondern ein Prozess. Bei devRocks implementieren wir Security auf jeder Stufe — von der Dockerfile-Review bis zum Runtime-Monitoring.