Kubernetes Escape: Breaking Container Limits in Cluster Hacking

Before understanding how an escape occurs, it is essential to understand what exactly an attacker is escaping from. A container is not a lightweight virtual machine; it is a standard Linux process that has been isolated from other processes using specific kernel features.

The two primary pillars of container isolation in Linux are:

• Namespaces: These limit what a process can see. Namespaces provide process-level isolation for resources like Process IDs (PIDs), networks, inter-process communication (IPC), mount points, and hostnames.
• Control Groups (cgroups): These limit what a process can use. Cgroups manage and enforce resource limits, such as CPU usage, memory allocation, and disk I/O, preventing a single container from starving the host system.

Kubernetes orchestrates these containers by grouping them into "Pods," which are scheduled onto "Worker Nodes." The Kubernetes Control Plane manages the entire cluster, communicating with the nodes via the Kubelet agent. The security of a Kubernetes cluster relies on the assumption that containers remain effectively sandboxed. A Kubernetes Escape shatters this assumption.

A Kubernetes Escape (or Container Breakout) occurs when a malicious actor, having gained initial access to a container (often via a vulnerable web application running inside it), successfully bypasses the namespace and cgroup isolation to interact directly with the underlying host operating system (the Worker Node).

Once an attacker breaks out onto the host node, the severity of the breach escalates exponentially. From the host node, the attacker can:

• Access sensitive configuration files, including Kubeconfig files that may contain cluster admin credentials.
• Steal Service Account tokens to interact with the Kubernetes API server.
• Pivot and move laterally to other pods running on the same node or across the cluster.
• Deploy malicious DaemonSets, cryptominers, or backdoors.
• Completely compromise the Kubernetes Control Plane.

While kernel zero-day vulnerabilities in container runtimes (like runC or containerd) do exist and can facilitate escapes, the vast majority of real-world Kubernetes breakouts are the result of severe misconfigurations. Attackers exploit overly permissive settings to tear down the walls of their containerized sandbox.

1. Privileged Containers

Running a pod with the privileged: true security context is the most direct path to a container escape. A privileged container is essentially stripped of most of its isolation. It retains all Linux capabilities and has almost the same access to the host's hardware and devices as processes running directly on the host.

If an attacker compromises a web app running inside a privileged container, they can easily mount the host's filesystem, interact with host kernel modules, and execute commands as the root user of the underlying worker node. Deploying privileged containers should be strictly avoided unless absolutely necessary for specific infrastructural tools, and even then, heavily monitored.

2. Dangerous HostPath Mounts

A hostPath volume allows a pod to mount a file or directory directly from the worker node's filesystem into the container. While useful for certain logging or monitoring agents, reckless use of hostPath is highly dangerous.

If a cluster administrator mounts the host's root directory (/) or critical directories like /etc, /var, or /boot into a container, an attacker who compromises that container can read or modify the host's files. For example, an attacker could write their SSH public key to the host's /root/.ssh/authorized_keys file or create a malicious cron job on the host filesystem, instantly achieving an escape and persistence on the node.

3. Exposed Docker Socket

In older Kubernetes environments that utilized Docker as the container runtime, exposing the Docker socket (/var/run/docker.sock) to a container was a common, yet fatal, misconfiguration.

The Docker socket is a Unix domain socket used to communicate with the Docker daemon. If this socket is mounted inside a container, any process running inside that container can send commands to the Docker daemon on the host. An attacker could use this access to spin up a new, highly privileged container that mounts the host's root filesystem, completely bypassing the isolation of their original, restricted container. While modern Kubernetes uses containerd or CRI-O, exposing equivalent runtime sockets yields the same catastrophic results.

4. Overly Permissive Capabilities

Linux Capabilities allow granular control over root privileges. Instead of granting full root access, an administrator can grant specific capabilities. However, granting the wrong capabilities can easily lead to an escape.

For instance, the CAP_SYS_ADMIN capability is extremely broad and essentially grants root-level power over the system, allowing an attacker to mount filesystems or manipulate namespaces. Similarly, CAP_SYS_PTRACE allows a process to inspect and manipulate other processes, which can be abused to inject malicious code into a process running on the host node outside the container's namespace.

5. Insecure RBAC Configurations

Role-Based Access Control (RBAC) in Kubernetes determines who can do what within the cluster. Every pod is associated with a Service Account, and the token for this account is automatically mounted inside the pod at /var/run/secrets/kubernetes.io/serviceaccount.

If an attacker compromises a pod, they can steal this token. If the Kubernetes administrator has granted overly permissive RBAC roles to that Service Account—such as the ability to create new pods, read secrets across all namespaces, or access the cluster-admin role—the attacker doesn't even need to escape to the host node. They can use the stolen token to command the Kubernetes API server directly, achieving full cluster compromise from within the container.

Understanding theoretical misconfigurations is important, but looking at real-world vulnerabilities highlights the gravity of container escapes.

CVE-2019-5736: The runC Vulnerability

One of the most famous container escape vulnerabilities was CVE-2019-5736, a flaw in runC, the underlying container runtime used by Docker and containerd. This vulnerability allowed a malicious container to overwrite the host runC binary. If a cluster administrator executed a command inside the malicious container (e.g., using kubectl exec), the attacker could achieve root code execution on the host node. This highlighted that escapes can occur not just from misconfigurations, but from fundamental flaws in the container runtime engine itself.

Exploiting the Kubelet API

The Kubelet runs on every worker node and is responsible for managing pods. By default, the Kubelet API listens on port 10250. Historically, this API allowed unauthenticated access. If an attacker compromised a container and could reach the host's IP on port 10250, they could send requests directly to the Kubelet API to execute commands on other pods running on the same node, effectively escaping their own pod and compromising the node's operations.

Securing a Kubernetes cluster requires a defense-in-depth strategy that addresses both the container workload and the cluster infrastructure. Preventing a Kubernetes Escape requires strict adherence to the principle of least privilege.

Implement Pod Security Standards

Kubernetes provides Pod Security Standards (PSS) which define three distinct profiles: Privileged, Baseline, and Restricted.

• You should strictly enforce the Restricted profile for all application workloads using Pod Security Admission controllers.
• This automatically prevents the creation of privileged containers, blocks dangerous host mounts, drops all default Linux capabilities, and requires containers to run as non-root users.

Enforce the Principle of Least Privilege

Never run applications as the root user inside a container. Use the securityContext.runAsUser and runAsNonRoot directives in your pod specifications. If an attacker compromises a web application running as a restricted user, it becomes significantly harder for them to manipulate the container environment or attempt an escape to the host.

Secure Service Accounts and RBAC

Audit your RBAC roles and bindings regularly.

• Ensure that pods are only granted the specific API permissions they need to function.
• If a pod does not need to communicate with the Kubernetes API, disable the automatic mounting of the Service Account token by setting automountServiceAccountToken: false in the pod spec.

Utilize Network Policies

By default, all pods in a Kubernetes cluster can communicate with each other. This flat network is a dream for attackers attempting lateral movement after an initial breach. Implement robust Kubernetes Network Policies to isolate namespaces and restrict traffic flow. Ensure that a compromised frontend pod cannot arbitrarily communicate with the backend database or the cloud provider's metadata service.

Seccomp and AppArmor

For highly secure environments, utilize Seccomp (Secure Computing Mode) and AppArmor or SELinux.

• Seccomp: Restricts the system calls a container can make to the host kernel.
• AppArmor/SELinux: Applies Mandatory Access Control (MAC) profiles to limit file access and network capabilities. Using default or custom profiles significantly reduces the attack surface available for an escape.

Continuous Auditing and Runtime Security

Prevention must be paired with detection. Deploy runtime security tools (like Falco or Tetragon) that monitor the cluster for anomalous behaviors indicative of an escape attempt. These tools can alert defenders to activities such as unexpected file modifications on the host, unauthorized namespace manipulation, or the sudden spawning of a shell inside a container.

From an offensive perspective (Red Teaming), Kubernetes escapes require chaining together multiple low-level primitives. A modern Red Team Operator won't just look for privileged: true. They will probe for deep misconfigurations:

• Interrogating cloud provider metadata endpoints (e.g., 169.254.169.254 on AWS/GCP) from within the pod to steal node-level IAM credentials.
• Exploiting kernel vulnerabilities like "Dirty Pipe" (CVE-2022-0847) from within a container if the host kernel is outdated, breaking out via file overwrites.
• Hunting for dangling or overly permissive RBAC roles that allow pod/exec, enabling them to jump into more privileged pods within the cluster.

Understanding these advanced techniques is crucial for Blue Teams to proactively hunt for threats and validate their defensive postures.