Container Security Fundamentals

Imagine a secure apartment building.

Physical barriers: Locks on doors, gates, security checkpoints. These prevent unauthorized entry.

Isolation: Each apartment is separate. A problem in one apartment (fire, flooding) doesn’t immediately affect others.

Monitoring: Security cameras, door sensors, alarm systems. You know what’s happening.

Access control: Only authorized people get keys. Different people have different access levels (resident, maintenance, security).

Security is layered. No single measure is perfect, but combined they create defense in depth.

Container security is the same. You need multiple layers:

• Image security (trusted base, no vulnerabilities)
• Isolation (namespaces, cgroups)
• Least privilege (non-root users, dropped capabilities)
• Network security (firewalls, network policies)
• Secrets management (no hardcoded passwords)
• Monitoring (audit logs, intrusion detection)

What are we protecting?

1. The host system — A compromised container shouldn’t compromise the host
2. Other containers — Containers should be isolated from each other
3. Sensitive data — Secrets, credentials, user data
4. The application — From attacks exploiting vulnerabilities
5. The supply chain — From malicious or vulnerable images

Attack vectors:

1. Malicious images

• Public images on Docker Hub might contain malware
• Typosquatting (nginx vs. ngnix)
• Compromised maintainer accounts

2. Vulnerable dependencies

• Base image has unpatched CVEs (Common Vulnerabilities and Exposures)
• Application dependencies have known vulnerabilities

3. Container escape

• Exploit in the container runtime allows breaking out to the host
• Container runs as root and can access host resources

4. Exposed secrets

• API keys in environment variables
• Passwords in Dockerfiles
• Credentials in logs

5. Unnecessary privileges

• Container runs as root when it doesn’t need to
• Has capabilities it doesn’t use
• Can access resources it doesn’t need

6. Network attacks

• Containers on the same network can attack each other
• Exposed ports allow external attacks
• Man-in-the-middle on unencrypted connections

Docker provides several security mechanisms:

1. Namespaces (Isolation)

Containers get their own:

• PID namespace (can’t see host processes)
• Network namespace (own network stack)
• Mount namespace (own filesystem view)
• User namespace (map root in container to non-root on host)
• IPC namespace (separate inter-process communication)
• UTS namespace (own hostname)

2. Control Groups (Resource Limits)

Prevent containers from:

• Using all CPU
• Consuming all memory
• Filling up disk space

3. Capabilities

Linux capabilities divide root privileges into smaller pieces:

• CAP_NET_ADMIN — network configuration
• CAP_SYS_ADMIN — system administration
• CAP_CHOWN — change file ownership
• etc.

Docker drops many capabilities by default. You can drop more or add specific ones.

4. Seccomp (Secure Computing Mode)

Filters which system calls a container can make. Default profile blocks ~44 dangerous syscalls.

5. AppArmor/SELinux

Mandatory Access Control (MAC) systems that restrict what containers can do.

6. Read-only root filesystem

Prevent containers from modifying their own filesystem, reducing attack surface.

1. Principle of Least Privilege

Give containers only the permissions they need, nothing more.

❌ Bad:

FROM ubuntu
# Runs as root by default

✅ Good:

FROM ubuntu
RUN useradd -m appuser
USER appuser

2. Defense in Depth

Multiple layers of security. If one fails, others protect you.

• Use trusted base images
• Scan for vulnerabilities
• Run as non-root
• Drop capabilities
• Use read-only filesystem
• Network isolation
• Secrets management
• Monitoring and alerting

3. Immutability

Containers should be immutable. Configuration changes require rebuilding the image, not modifying a running container.

This prevents configuration drift and makes security audits easier.

4. Minimal Attack Surface

The less you have, the less there is to attack.

• Use minimal base images (Alpine, distroless)
• Don’t install unnecessary packages
• Remove build tools in production images
• Use multi-stage builds

5. Security as Code

Security policies in version control:

• Dockerfiles define secure images
• Compose files define secure configurations
• Scanners in CI/CD catch vulnerabilities
• Policy engines enforce rules

VMs: Strong Isolation, Heavy Overhead

Each VM has:

• Full OS kernel (strong isolation)
• Hypervisor enforcement (hardware-level separation)
• Large attack surface (full OS)

Containers: Lighter Isolation, Shared Kernel

Containers have:

• Shared kernel (weaker isolation)
• Namespace/cgroup enforcement (software-level separation)
• Smaller attack surface (minimal base images possible)

Which is more secure?

Neither is inherently “more secure.” It depends on:

• Configuration (badly configured VMs are insecure too)
• Threat model (what are you protecting against?)
• Implementation (are security best practices followed?)

Best of both worlds:

Run containers inside VMs:

• VMs provide strong isolation between environments
• Containers provide efficiency and density within VMs

This is what most cloud providers do (AWS Fargate, Google Cloud Run, etc.).

---