Comprehensive container security guide covering Docker and Kubernetes security from a security engineer’s perspective. Explains container isolation fundamentals, Linux namespaces and cgroups, capabilities, seccomp, SELinux/AppArmor, runtime security, container escape risks, RBAC and ServiceAccount security, Kubernetes control-plane threats, supp…

container_security.md

History of Containers (Through a Security Engineer’s Lens)

“Those who forget history are doomed to repeat it — usually in production.”
This document traces the evolution of containers, focusing not on hype, but on what actually broke, why it broke, and what attackers really abused.

---

---

1. Early Unix Systems (Pre-containers)

What existed

• Multi-user, time-sharing systems
• Single shared kernel
• Processes trusted each other far more than they should have

Why isolation was needed

Unix assumed cooperation, not hostility. As soon as multi-user systems appeared, it became clear that:

• One bad process could snoop, starve, or interfere with others
• Process separation ≠ security boundary

Security misconfigurations (classic mistakes)

• Treating process separation as isolation
  → If you can run code, you can usually hurt neighbors.
• Running untrusted workloads on shared hosts without MAC/LSM
• World-writable directories enabling persistence and tampering

CVE perspective

There are no famous CVEs here — because the threat model itself was flawed.
Security failure was architectural, not patch-level.

Takeaway:
If your security model assumes “well-behaved users,” attackers will politely disagree.

---

2. chroot (1979): The First Illusion of Isolation

What it did

• Changed the apparent root directory for a process
• Provided filesystem isolation only

What it did not do

• No process isolation
• No network isolation
• No privilege reduction

Security reality

chroot was never meant to be a sandbox — it was a convenience feature.

Common misconfigurations

• Using chroot as the only sandbox
• Leaving /proc, /dev, or sensitive mounts accessible
• Running privileged processes inside chroot

Root inside a poorly configured chroot often equals root outside it.

CVE perspective

Breakouts are almost always misconfiguration-driven, not chroot bugs.

Takeaway:
chroot answers “where am I?”, not “what am I allowed to do?”

---

3. Virtual Machines Era

Why VMs mattered

• Separate kernels
• Strong hardware-backed isolation
• Clear security boundary

Trade-offs

• Heavy
• Slow to boot
• Resource-hungry

Common security misconfigurations

• Unpatched hypervisors or guest tools
• Over-permissive device passthrough
• Exposed management planes (vCenter, ESXi APIs)

Notable CVEs

• CVE-2015-3456 (VENOM) – QEMU floppy controller escape class
• CVE-2017-4902 – VMware SVGA escape-related vulnerability

Security lesson

VMs fail rarely, but when they do, the blast radius is massive.

Takeaway:
VMs trade speed for isolation — containers do the opposite.

---

4. Linux Kernel Evolution: What Made Containers Possible

Containers are not magic. They are carefully composed kernel features.

---

4.1 Namespaces — “What You Can See”

Namespaces isolate views of system resources.

• PID Namespace

  • Each container sees its own PID tree
  • PID 1 semantics matter (signal handling, zombie reaping)

• Mount Namespace

  • Independent mount tables
  • HostPath mounts can silently destroy isolation

• Network Namespace

  • Separate interfaces, routes, firewall rules
  • Misconfigurations enable lateral movement

• IPC Namespace

  • Isolates shared memory and message queues

• UTS Namespace

  • Hostname isolation (mostly cosmetic)

• User Namespace

  • Maps container root to unprivileged host UID
  • One of the strongest hardening features
  • Also one of the most underused

• Cgroup Namespace

  • Mostly reduces information leakage

Security truth:
Namespaces reduce visibility — they do not enforce trust boundaries.

---

4.2 cgroups — “How Much You Can Use”

Controls resource consumption:

• CPU
• Memory
• PIDs
• I/O

Why security cares

• Prevents denial-of-service
• Limits blast radius

v1 vs v2

• v1: fragmented, confusing
• v2: unified, predictable

Security role:
Availability protection, not confidentiality or integrity.

---

4.3 Capabilities — Breaking the “Root Is God” Myth

Root is split into fine-grained powers:

• CAP_SYS_ADMIN – the “god capability”
• CAP_NET_ADMIN
• CAP_SYS_PTRACE
• CAP_DAC_OVERRIDE

A “privileged container” is basically root with better marketing.

---

4.4 Seccomp — Reducing Kernel Attack Surface

• Filters syscalls per workload
• Dramatically reduces exploitability
• Requires application awareness

Security trade-off:
Tighter profiles = safer, but risk of breaking apps.

---

4.5 LSMs (SELinux / AppArmor)

• Mandatory access control
• Enforced even for root
• Only as good as the policy

---

4.6 Filesystem Stack

• OverlayFS enables image layering
• Bind mounts enable config/secrets injection

Danger zone:

• Mounting /var/run/docker.sock
• Mounting /proc, /sys, or host root paths

---

4.7 Kernel-era Security Misconfigurations (High Signal)

• No user namespaces
• HostPID / HostNetwork / HostIPC
• Privileged containers
• No seccomp / no LSM
• Excessive capabilities

Notable CVEs

• CVE-2016-5195 (Dirty COW)
• CVE-2022-0847 (Dirty Pipe)

Takeaway:
Containers share a kernel. Kernel bugs matter a lot.

---

5. LXC (Linux Containers)

What LXC introduced

• First “real” containers
• System-container model (OS-like)
• Low-level, complex

Common security mistakes

• Treating LXC as VM-equivalent
• Weak UID/GID mappings
• Broad privileges

Reality:
Most serious issues come from the kernel or runtime, not LXC itself.

---

6. Docker (2013): Containers for Humans

Why Docker won

• Simple CLI
• Image distribution
• Immutable artifacts

Security pitfalls

• Privileged containers
• Mounting docker.sock
• Running as root
• Mutable tags (latest)
• Untrusted registries

Notable CVEs

• CVE-2019-14271 – docker cp breakout class
• CVE-2019-5736 – runc overwrite escape

Takeaway:
Docker made containers easy — and made insecure defaults popular.

---

7. Standardization & Runtimes

OCI (Open Container Initiative)

• Image spec
• Runtime spec
• Behavior standardization, not security guarantees

Runtimes

• runc – executes containers (high-risk)
• containerd – lifecycle & images
• CRI-O – Kubernetes-focused

Security misconfigurations

• Exposed runtime sockets
• Outdated runc/containerd
• No image signing or provenance

Notable CVEs

• CVE-2020-15257 – containerd-shim escape class
• CVE-2024-21626 – runc FD leak breakout

---

8. Kubernetes Era: Containers at Scale

Why Kubernetes exists

• Scheduling
• Self-healing
• Declarative control

Security shift

Security moves from host-level to API-driven cluster control.

Key risk areas

• RBAC
• ServiceAccount tokens
• Kubelet exposure
• etcd protection
• East-west traffic

Common real-world misconfigurations

• Cluster-admin everywhere
• Auto-mounted tokens
• No NetworkPolicy
• Privileged pods + hostPath
• Insecure etcd

Notable CVEs

• CVE-2018-1002105 – API server privilege escalation
• CVE-2021-25741 – kubelet subPath host access

Truth:
Most Kubernetes breaches are API abuse, not container escapes.

---

9. Modern Container Security View

Core reality

• Containers are processes
• Isolation is conditional
• Defaults are unsafe

Threat model evolution

• Perimeter → workload
• Static → ephemeral
• Single exploit → chained abuse

Defense in depth

• Build-time: minimal images, signing, SBOMs
• Deploy-time: non-root, seccomp, admission policies
• Runtime: syscall, file, network, process monitoring
• Platform: node + control plane hardening

Detection philosophy

Prevention fails silently. Detection fails loudly — and that’s good.

What interviewers expect you to say fast

• Containers aren’t strong isolation
• RBAC misconfig is worse than kernel CVEs
• Runtime visibility is mandatory
• Security is configuration, not tooling

---

Final Takeaway

Containers trade isolation strength for speed and scale.
Good security is not about trusting that trade —
it’s about monitoring it continuously.