Container Security

1What a Container Does and Doesn't Isolate

A container is a normal Linux process with namespaces (its own view of PIDs, mounts, network, hostname, users) and cgroups (resource limits) — 01-docker_fundamentals/. All containers share the host kernel. A kernel exploit, a misconfiguration that hands the container host resources, or a runtime bug can let a process escape to the host. So container security is layers of defense:

supply chain (what's in the image) → build (how it's made) → configuration (how it runs)
→ runtime (what it's allowed to do) → host & orchestrator (what's around it)

2The Image: Smaller, Pinned, Scanned

• Minimal bases: -slim, Alpine, distroless, or scratch (multi-stage builds, 06-multi_stage_builds/). Fewer packages = fewer CVEs and no shell for an attacker.
• Pin versions — and ideally digests: FROM node:22.11.0-bookworm-slim@sha256:…, so a tag can't silently change underneath you.
• Scan images in CI (Trivy, Grype, Docker Scout) and fail on fixable critical/high CVEs; rescan regularly — new CVEs appear for old images.
• Rebuild often to pick up base-image patches.
• No secrets in images — not in ENV, ARG, files or layers. Inject at runtime (orchestrator secrets, mounted files, a secrets manager).
• SBOM and signing: generate a software bill of materials (Syft), sign images (cosign/Sigstore) and verify signatures at deploy time.

3Run as Non-Root

By default a container process is root (uid 0). Without user namespaces, that's the same uid 0 as on the host — if it escapes (or a host path is mounted), it's root on the host.

RUN groupadd -r app && useradd -r -g app -u 10001 app
USER 10001

In Kubernetes: securityContext: { runAsNonRoot: true, runAsUser: 10001 }.

4Drop Privileges at Runtime

docker run \
  --user 10001:10001 \
  --read-only --tmpfs /tmp \              # immutable root filesystem
  --cap-drop ALL --cap-add NET_BIND_SERVICE \   # only the capabilities you need
  --security-opt no-new-privileges \      # setuid binaries can't escalate
  --pids-limit 200 --memory 512m --cpus 1 \     # resource limits (DoS containment)
  --network app-net \
  myapp:1.4.2

5Never Do These

• --privileged — disables nearly all isolation; effectively root on the host.
• Mount the Docker socket (-v /var/run/docker.sock:/var/run/docker.sock) — anyone in the container controls the Docker daemon, i.e. the host.
• Mount sensitive host paths (/, /etc, /proc, /var/run).
• --network host / --pid host without a very good reason.
• Expose the Docker daemon over TCP without TLS.

6Orchestrator Layer (Kubernetes)

• Pod Security Standards (restricted profile) enforce non-root, no privilege escalation, dropped capabilities, seccomp RuntimeDefault.
• NetworkPolicies: default-deny, then allow only the flows each service needs.
• RBAC for service accounts; don't automount tokens that aren't needed.
• Admission control (Kyverno, OPA Gatekeeper) to reject unsigned or unscanned images and insecure specs.
• Runtime detection (Falco): alert on shells spawned in containers, unexpected outbound connections, writes to sensitive paths.

Under the HoodCapabilities, Seccomp and User Namespaces▾

Linux split root's powers into ~40 capabilities (CAP_NET_ADMIN, CAP_SYS_ADMIN, CAP_CHOWN, …). Docker starts containers with a reduced default set (14 or so); --cap-drop ALL removes the rest, so even uid 0 inside can't, say, change network config or load kernel modules. CAP_SYS_ADMIN is the famous "new root": it allows mounts and many escape techniques — granting it nearly equals --privileged.

Seccomp filters system calls with a BPF program evaluated by the kernel on every syscall; Docker's default profile denies calls like keyctl, add_key, unshare (in many cases), mount, kexec_load and ptrace on older kernels — shrinking the kernel attack surface a container can reach.

User namespaces (userns-remap, rootless Docker/Podman) map uid 0 inside the container to an unprivileged uid range on the host (e.g. 100000–165535). Then even a process that is "root" in the container and escapes is just an ordinary user on the host. Rootless mode goes further and runs the whole daemon without root privileges.

⚠️ Common Pitfalls

1. Running as root because it's the default.
2. latest tags and unpinned bases — unreproducible, unreviewed changes.
3. Secrets baked into images (ENV API_KEY=...).
4. --privileged or the Docker socket mounted "to make it work".
5. Scanning once at build time and never again.
6. No resource limits — one container can starve the node.

📋 Quick Reference

image:   slim/distroless · pinned (digest) · scanned in CI · SBOM + signed · no secrets
build:   multi-stage · USER non-root · .dockerignore
run:     --read-only --cap-drop ALL --security-opt no-new-privileges · limits · seccomp default
never:   --privileged · docker.sock mount · host namespaces
k8s:     restricted PSS · NetworkPolicy default-deny · RBAC · admission policies · runtime detection

🎤 Interview Q&A

🛠️ Practice exercises

Each exercise is a file in this topic folder. Code exercises are self-checking: run them and make the checks pass.

✅ Check yourself

Source: docker_container_security_theory.md · generated by tools/build_lessons.py