Container Breakout to Host Takeover: Exploiting Linux Namespaces, Cgroups v2, and Kernel Credential Overwrites

The Illusion of Container Isolation

A widespread misconception among software engineering teams is that containers provide security boundaries equivalent to Virtual Machines (VMs).

They do not. While a virtual machine runs its own dedicated guest operating system kernel on top of a hypervisor (e.g. KVM, ESXi), containers are merely isolated processes sharing the host operating system kernel.

Container isolation relies on three core Linux kernel primitives:

1. Namespaces: Partitioning system resources (process IDs, network interfaces, mount points).


2. Control Groups (cgroups): Limiting and measuring resource usage (CPU, memory, disk I/O).


3. Capabilities & Seccomp: Restricting permitted system calls and administrative privileges.

When an attacker compromises a containerized microservice and discovers a vulnerability in the underlying host kernel, the container boundary collapses immediately.

---

Anatomy of a Kernel-Level Container Breakout

Every process running on a Linux system is represented in kernel memory by a struct task_struct. Inside this structure resides a pointer to struct cred, which dictates the process's effective UID, GID, capabilities, and namespace bindings.

Host Operating System Kernel Memory
┌────────────────────────────────────────────────────────┐
│ struct task_struct (Container Worker Process)          │
│   ├── pid: 4891                                        │
│   ├── nsproxy ───────► Isolated Container Namespaces   │
│   └── cred ──────────► struct cred                     │
│                          ├── uid: 10001 (Non-root)     │
│                          ├── gid: 10001                │
│                          └── cap_effective: 0          │
└────────────────────────────────────────────────────────┘

If an attacker identifies an arbitrary memory write vulnerability in the shared Linux kernel (such as a Use-After-Free or heap overflow in netfilter, io_uring, or overlayfs), they do not need to break through namespace barriers.

They simply locate their process's cred structure in kernel memory and overwrite its fields with zeroes (uid=0, gid=0, capabilities=0xFFFFFFFFFFFFFFFF).

Within the same CPU clock cycle, the container process is elevated to full root privileges.

---

Weaponizing Unprivileged User Namespaces

A primary mechanism enabling container breakouts is unprivileged user namespaces (CLONE_NEWUSER).

Designed to allow unprivileged users to act as root inside an isolated container sandbox, user namespaces grant processes the ability to configure new mount points and activate kernel subsystems previously restricted to root:

// Spawning a new user namespace to access restricted kernel attack surfaces
#define _GNU_SOURCE
#include <sched.h>
#include <unistd.h>
#include <stdlib.h>
int main() {
    // Unshare user and mount namespaces
    if (unshare(CLONE_NEWUSER | CLONE_NEWNS) == -1) {
        exit(1);
    }
    // The process now possesses full capabilities (CAP_SYS_ADMIN) inside this namespace,
    // exposing previously unreached kernel filesystem drivers to local fuzzing.
    system("/bin/bash");
    return 0;
}

Once inside the newly mapped user namespace, the attacker exposes legacy kernel code paths—such as overlayfs mount logic or outdated socket options—that were never intended to be accessible to untrusted users.

---

Moving from Host Root to Cluster Takeover

Once an attacker breaks out of a container and lands on the underlying Kubernetes worker node as host root:

1. Kubelet Credential Scraping: The attacker reads /var/lib/kubelet/pki/kubelet-client.crt and the corresponding private key.


2. Accessing Stored Secrets: The attacker queries the local containerd runtime (crictl) to extract environment variables and tokens from every adjacent tenant container running on the same node.


3. Cloud Node Identity Theft: The attacker queries the Cloud Instance Metadata Service (IMDSv2) to extract the IAM instance profile assigned to the Kubernetes worker node, pivoting into the surrounding cloud infrastructure.

---

Hardening Kubernetes Nodes Against Container Breakouts

Defending production clusters against kernel-level container escapes requires defense-in-depth:

1. Disable Unprivileged User Namespaces

On worker node hosts, disable unprivileged user namespace creation unless strictly required:

echo "user.max_user_namespaces=0" >> /etc/sysctl.d/99-disable-userns.conf
sysctl --system

2. Enforce Hypervisor-Based Container Isolation

For multi-tenant workloads or untrusted code execution, migrate from runc to hardware-isolated container runtimes:

• gVisor (runsc): Implements an application kernel in user space to intercept and handle system calls before reaching the host kernel.
• Kata Containers: Wraps each pod in an ultra-lightweight microVM with its own dedicated kernel.

3. Deploy Strict Seccomp Default Profiles

Ensure all pods apply the runtime default seccomp profile (RuntimeDefault) to block unnecessary system calls such as unshare, clone3, and bpf from ever reaching the host kernel.