Docker Architecture & Container Threat Landscape

Understand Docker's internal architecture, container isolation mechanisms, and explore the complete threat landscape that security professionals must defend against.


         $ docker ps

         CONTAINER ID   IMAGE     STATUS

         a3f8c1b2e4d9   nginx     Up 2 hours

         ⚠ Security boundary: Host kernel

Docker Architecture Overview

Containers vs Virtual Machines

Containers share the host OS kernel, creating a fundamentally different security model than traditional virtual machines:

Virtual Machines

Each VM has its own complete OS and kernel. Guest OS is isolated from hypervisor. Requires more resources.

Containers

All containers share the host kernel. Isolation via namespaces and cgroups. Lightweight and efficient.


         Shared Resource:

         ↓ Host Kernel ↓

         Security Critical

Host and Container Boundary

The host kernel is the critical security boundary. Compromise at this layer affects all running containers:

→ Kernel Namespaces: Isolate process, network, mount, PID, UTS, IPC spaces
→ Control Groups (cgroups): Limit CPU, memory, disk, network resources
→ User Namespaces: Map container root to non-privileged host user
→ Capabilities: Fine-grained kernel privileges for container processes


         $ unshare --user

         Container sees root, host sees

         unprivileged user

Container Isolation Mechanisms

🔒 Namespaces

Logical isolation of system resources (process, network, filesystem)

📊 cgroups

Limit and monitor resource consumption (CPU, memory, I/O)

⚙️ Capabilities

Fine-grained Linux kernel privileges per container

🔐 Seccomp

Restrict system calls available to container processes

Container Threat Landscape

Privilege Escalation Risks

Containers running with excessive privileges become gateways to host compromise:

⚠ Running as root: Default Docker behavior grants UID 0 inside container, enabling rapid privilege escalation
⚠ Privileged flag: --privileged removes all restrictions and mounts host devices, equivalent to host root access
⚠ Dangerous capabilities: CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_DAC_OVERRIDE allow privilege escalation
⚠ Docker socket access: Mounting /var/run/docker.sock grants container full Docker engine control


         $ docker run --privileged

         ⚠ Full host access enabled

         Risk: Host compromise possible

Container Breakout Awareness

Kernel vulnerabilities and misconfigurations enable container escape to host level:

⚠ Kernel CVEs: Unpatched kernel vulnerabilities (Dirty Cow, namespaces bugs) bypass isolation
⚠ cgroup escape: cgroup v1 vulnerabilities allow process to escape resource limits
⚠ Namespace bypass: User namespace mapping misconfigurations allow privilege mapping attacks
⚠ Storage driver exploits: Overlay2, AUFS vulnerabilities enable host filesystem access


         Breakout Vector: Kernel Exploit

         → Escape Container Namespace

         → Access Host Filesystem

Host Compromise Scenarios (Conceptual)

Once container isolation is bypassed, attackers gain access to the entire host system:

Lateral Movement

Access other containers, compromise adjacent services, pivot through network

Data Exfiltration

Read sensitive files, access volumes, steal credentials from environment

Persistence

Install rootkits, create backdoors, modify system configurations at host level

Enterprise Security Risks

Why Containers Increase Attack Surface

Modern containerized architectures introduce new security dimensions that weren't present in traditional deployments:

→ Scale: Hundreds/thousands of containers create management complexity and configuration errors
→ Shared Kernel: Single kernel vulnerability affects all running containers simultaneously
→ Rapid Deployments: Speed prioritized over security; security checks bypassed in CI/CD
→ Supply Chain: Dependencies in images; image registries become attack targets

Misconfiguration Challenges

Default Docker configurations prioritize ease of use over security, creating enterprise risk:

⚙ Insecure Defaults: Run as root, privileged flag accessible, capabilities not restricted
⚙ Configuration Drift: Different security postures across clusters and environments
⚙ Developer Convenience: Security configurations often disabled for debugging/development
⚙ Lack of Visibility: Runtime behavior monitoring not enabled in most deployments