Container-Sicherheit.

Container-Sicherheit deckt den gesamten Lebenszyklus OCI-kompatibler Container (Docker, containerd, CRI-O) ab. Beim Build scannen Teams Images auf CVEs und eingebettete Secrets, signieren sie mit Sigstore/Cosign und erzwingen minimale Base-Images. Bei der Verteilung werden Registries durch authentifizierten Zugriff und Signaturprüfung geschützt. Zur Laufzeit reduzieren Host-Hardening, Namespace-/cgroup-Isolation, seccomp, AppArmor und read-only Dateisysteme die Angriffsfläche; Admission Controller und eBPF-Sensoren erzwingen Richtlinien und erkennen Anomalien.

Da Container den Host-Kernel teilen, kann ein einziger Kernel- oder Runtime-Fehler die Isolation durchbrechen. CVE-2019-5736 erlaubte einem bösartigen Image, das Host-runc-Binary über /proc/self/exe zu überschreiben und so Root-Codeausführung auf dem Node zu erlangen; behoben in runc 1.0-rc7 und Docker 18.09.2. Die 2024er „Leaky Vessels" CVE-2024-21626 leakte einen internen Dateideskriptor (fd/7), der vor pivot_root auf das Host-Arbeitsverzeichnis zeigte, sodass das Setzen des Container-cwd auf /proc/self/fd/7 aus dem Rootfs ausbrach (behoben in runc 1.1.12). Da ein Pod-Escape meist einer Node-Kompromittierung gleichkommt, zählt Defense-in-Depth: Capabilities entziehen, non-root laufen lassen, privilegierte und hostPath-Mounts vermeiden, runc gepatcht halten und stärkere Sandboxes wie gVisor oder Kata Containers erwägen.

flowchart LR
  A[Build: Image scannen + signieren] --> B[Registry: Authn + Signatur pruefen]
  B --> C[Admission: privilegiert/hostPath ablehnen]
  C --> D[Runtime: seccomp, AppArmor, non-root, Caps entzogen]
  D --> E[Erkennung: eBPF/Falco-Alarme]
  D -. Kernel-/runc-Fehler .-> X[Container-Escape zum Host]
  X -. gemindert durch .-> F[gVisor / Kata Sandbox]