Container Security.

Container security covers the full lifecycle of OCI-compatible containers (Docker, containerd, CRI-O). At build time, teams scan images for CVEs and embedded secrets, sign them with Sigstore/Cosign, and enforce minimal base images. At distribution, registries are protected with authenticated access and signature verification. At runtime, host hardening, namespace/cgroup isolation, seccomp, AppArmor, and read-only file systems reduce attack surface, while admission controllers and eBPF-based sensors enforce policy and detect anomalies.

Containers share the host kernel, so a single kernel or runtime flaw can break isolation. CVE-2019-5736 let a malicious image overwrite the host runc binary via /proc/self/exe, yielding root code execution on the node; it was fixed in runc 1.0-rc7 and Docker 18.09.2. The 2024 "Leaky Vessels" CVE-2024-21626 leaked an internal file descriptor (fd/7) pointing at the host working directory before pivot_root, so setting a container's cwd to /proc/self/fd/7 escaped the rootfs (patched in runc 1.1.12). Because a pod escape usually equals node compromise, defence-in-depth matters: drop capabilities, run non-root, avoid privileged and hostPath mounts, keep runc patched, and consider stronger sandboxes such as gVisor or Kata Containers.

flowchart LR
  A[Build: scan + sign image] --> B[Registry: authn + verify signature]
  B --> C[Admission control: reject privileged/hostPath]
  C --> D[Runtime: seccomp, AppArmor, non-root, caps dropped]
  D --> E[Detect: eBPF/Falco anomaly alerts]
  D -. kernel/runc flaw .-> X[Container escape to host]
  X -. mitigated by .-> F[gVisor / Kata sandbox]