The Container Illusion

Containers Are Just Processes

Whether you’re running docker on your desktop or a production-grade Kubernetes cluster: containers are just Linux processes with some extra flags.

When you run docker run or deploy a Kubernetes pod, you’re not creating a separate, isolated environment. You’re starting a process on the host operating system that looks isolated through clever use of Linux kernel features:

• Namespaces: Give processes the illusion that they have their own PID space, network device, filesystem, etc.
• Cgroups: Limit what resources (CPU, memory, I/O) a process can consume
• Capabilities: Restrict what privileged operations a process can perform on a shared kernel

This is brilliant engineering with some significant security trade-offs. It’s lightweight, fast, and revolutionized how we deploy software. But it’s all an illusion maintained by the kernel.

The Shared Kernel Reality

Every container in your environment is running on the same Linux kernel. Once a kernel is compromised there are no further security mitigations. Let that sink in.

┌─────────────────────────────────────────────┐
│           Your Application Containers       │
│   [Web App] [Database] [API] [ML Model]     │
├─────────────────────────────────────────────┤
│                                             │
│         Shared Linux Kernel (Single)        │
│                                             │
├─────────────────────────────────────────────┤
│                   Hardware                  │
└─────────────────────────────────────────────┘

This means:

1. All containers share the same syscall interface - Any vulnerability in the kernel can be exploited by any container
2. Kernel bugs affect everyone - A kernel panic takes down all containers
3. The blast radius is huge - Compromising the kernel means compromising everything. Every container, certificate, token, and customer data is breached.

The Linux Kernel Attack Surface

How big is this problem? Let’s talk numbers:

• The Linux kernel contains over 27 million lines of code
• Since becoming a CVE Numbering Authority (CNA), the Linux kernel has received more CVEs than any other project
• It exposes hundreds of syscalls to userspace
• New vulnerabilities are discovered constantly. The first 16 days of 2025 saw 134 new Linux kernel CVEs
• It handles everything from networking to filesystems to device drivers

Every single container on your host interacts with a massive attack surface. And because containers are designed to be lightweight, their default configuration doesn’t restrict access to the shared kernel.

Why This Matters in Practice

Consider a scenario:

1. You’re running a multi-tenant SaaS platform
2. Customer A and Customer B are running workloads on the same node
3. Customer A’s container has a zero-day (or nday) kernel exploit (kernels rarely get patched)
4. That exploit can:
   • Escape the container
   • Access the host filesystem
   • Read Customer B’s data
   • Pivot to other customer data in your environment

This isn’t theoretical. Let’s look at some real examples in the next section.

The Namespace Boundary

Namespaces are powerful, but they’re not security boundaries. The Linux kernel maintainers have been clear about this:

“Namespaces are NOT a security feature. They are a mechanism for resource isolation.”

Think of namespaces like cubicle walls in an office. They give you privacy and separation, but they don’t stop someone from entering your cubicle without your permission. For real security, you need actual walls—ideally made of concrete and guarded by armed guards.

In our case, those “concrete walls” are hypervisor-enforced isolation. But we’re getting ahead of ourselves. First, let’s look at what happens when these namespace boundaries break down.

Next: Real-World Security Challenges →