Week 13 - The Default Threat Model¶

13.1 Conceptual Core¶

The container default threat model is not "isolation comparable to a VM." It is "isolation comparable to a chroot with namespaces, seccomp, and capability dropping." That is good for most use cases but breaks down for:
Untrusted code execution.
Multi-tenant SaaS where tenants can submit code.
Workloads that hold secrets cross-cutting tenants.
For those, use a sandboxed runtime (Month 3 week 12).
The default-rootful, capability-rich, weak-seccomp configuration in legacy Docker installs is the worst-case starting point. Modern runtimes (rootless podman, distroless images, Kata) flip the defaults.

Container escape via kernel exploit. Mitigation: keep kernel patched; gVisor/Kata for high-value targets.
Container escape via misconfiguration. Most common: - -privileged`, mounted Docker socket, host PID/NET, writeable host paths.
Image supply-chain attack. Mitigation: SBOM, signing, allowlisted base images. Month 5.
Lateral movement via shared resources. Mitigation: PodSecurity policies, network policies, secret scoping.
Resource exhaustion (DoS). Mitigation: cgroups v2 limits.

Pick a popular base image (nginx, redis). Run with docker scout cves and trivy image. Record findings.
Run as default; identify how many capabilities it has via capsh --print.
Re-run with - -cap-drop=ALL, - -security-opt=no-new-privileges, read-only rootfs. Identify what breaks. Fix what's needed.
Document the minimum config to run safely.

Establish a baseline docker run (or podman run) policy: read-only rootfs, cap-drop=ALL, no-new-privileges, default seccomp, non-root user, tmpfs for /tmp, memory and CPU limits.

Author a policy.json for skopeo/podman that requires signed images for any registry path containing prod. Verification will be wired in week 19.