Hunting Container Escape Surface

Hunting container escape surface: when the container boundary is the security boundary

A container is only an isolation boundary while its security context keeps it one. Treat the container as a box a process might try to climb out of, and the question is which settings hand it a ladder. A privileged pod, an added capability that grants kernel-level power, a host namespace shared in, a writable host path, or a mounted device each turns a container-local compromise into node access, and node access is every other pod on that node. The hunt is not about a bug in the application; it is about the runtime configuration that decides whether a foothold stays contained. You hunt this by inventorying the security context of each workload and finding where a setting lets the process reach the node.

When to use

• Workloads run with elevated security contexts: privileged mode, added capabilities, or host access.
• Pods share host namespaces (host PID, host network, host IPC) or mount host paths and devices.
• A compromise inside a container would be far worse if it could reach the node or neighboring pods.

Scope check

Test escape surface only on clusters and nodes you own or are authorized to assess, on non-production workloads. Demonstrating an escape reaches the real node and can affect other pods, so use a non-production node and stop at proof rather than pivoting. If you can't name the authorization, stop.

The loop

1. Establish the intended isolation first. Name what each workload is supposed to be able to touch: its own filesystem and network, nothing on the node. This is the false-positive killer: a pod that runs unprivileged, drops capabilities, shares no host namespace, and mounts no host path is contained by design, and an elevated setting it genuinely needs and constrains is not automatically a finding. Name the intended boundary, then find where the security context exceeds it.

2. Inventory privileged mode and capabilities. For each workload, read whether it runs privileged and which Linux capabilities it adds. Privileged mode removes most isolation at once; individual capabilities like the ones granting raw device, module, or admin access are nearly as powerful. A privileged or capability-broad container is a candidate escape regardless of the application.

3. Find shared host namespaces. Check whether the pod shares the host PID, network, or IPC namespace. Host PID exposes and can signal every process on the node; host network removes network isolation and exposes node-local services; host IPC shares memory segments. Each shared namespace is a direct bridge from the container to the node.

4. Trace host mounts and devices. Follow every host-path volume and mounted device into the container. A writable mount of a sensitive host directory, the container runtime socket, or a raw device lets the process read or write node state, and a mount of the host root or a runtime socket is a direct escape. Note which mounts are writable and what they expose.

5. Check the defenses that keep a process inside. Confirm whether the workload keeps the isolation defenses on: a non-root user, a read-only root filesystem where feasible, seccomp and mandatory-access- control profiles enforced rather than unconfined, and no-new-privileges set. A security context that disables these widens whatever the other settings expose.

6. Confirm and record. Confirm by showing a process in the container reaches a node resource it should not, reads host state through a mount, or acts through a shared namespace, on a non-production node and without pivoting further. Kill the lead if the workload is unprivileged, drops capabilities, shares no host namespace, mounts no sensitive host path, and keeps its isolation profiles enforced. Record the container source, the node resource sink, and the security-context setting that permitted the escape.

Where escape surface leaks

• Privileged mode removes isolation wholesale. A privileged container has near-node power; the escape is the setting, not a separate bug.
• A single capability can be enough. Capabilities granting raw device, module load, or admin operations give kernel-level reach without full privileged mode.
• A shared host namespace is a bridge. Host PID, network, or IPC each removes one wall between the container and every process or service on the node.
• A host mount exposes node state. A writable host path, the runtime socket, or a device mount lets the process read or alter the node directly.
• Disabled profiles widen everything. Running as root, unconfined seccomp or mandatory-access-control, or a writable root filesystem amplifies whatever the other settings already expose.

Worked example (a confirm and a kill)

Confirm. A batch workload runs with a host-path volume mounting the node root filesystem read-write, and its security context runs as root with an unconfined seccomp profile. A process in the container writes to a node-level path outside its own filesystem and reads another pod's mounted secret from the host. Confirmed container escape to node via writable host mount, critical, remediation = remove the host-root mount, run the workload as a non-root user with a read-only root filesystem, enforce a restrictive seccomp profile, and drop all unneeded capabilities.

Kill. The workload runs unprivileged as a non-root user, drops all capabilities and adds none, shares no host namespace, mounts only its own ephemeral volumes with no host path or device, and enforces seccomp and a mandatory-access-control profile with no-new-privileges set. A process inside cannot reach the node or another pod. Killed, kill_reason = "unprivileged non-root workload with capabilities dropped, no host namespace or host mount, and isolation profiles enforced; the container boundary holds and no node resource is reachable."

Rationalizations to reject

• "It needs privileged mode to work." → Confirm exactly which capability or device it needs and grant only that; blanket privileged mode is an escape, not a requirement.
• "It only mounts one host directory." → A single writable host mount can expose node state or another pod's data; check what it grants, not how many there are.
• "Host network is just for performance." → Host network removes network isolation and exposes node-local services; treat it as an escape surface, not a tuning knob.
• "The image is trusted." → Escape surface is about the runtime configuration, not the image; a trusted image compromised at runtime still uses whatever the security context grants.
• "There is nothing else on the node." → Nodes are shared and rescheduled; a node-level foothold reaches whatever lands there next.

Executing this in practice

You need each workload's security context: privileged flag, added and dropped capabilities, shared host namespaces, host-path and device mounts with their read-write mode, the run-as user, and the seccomp and mandatory-access-control profiles. For each workload, compare that to the intended isolation and find the setting that lets a process reach the node. Reading the pod spec shows the granted surface; demonstrating a node-resource reach on a non-production node shows whether the boundary holds.

Related

• auditing-kubernetes-workload-and-rbac-hardening - the broader workload-hardening audit; this skill focuses specifically on the settings that permit a node escape.
• auditing-host-mount-and-device-exposure - the deep dive on the host-path and device half of the escape surface this skill inventories.
• auditing-container-runtime-and-socket-exposure - the specific and severe case of the container runtime socket mounted into a pod.
• mapping-pod-to-cloud-credential-reach - what a foothold on the node then reaches in the cloud; escape and credential reach compound.
• FINDING-SCHEMA.md - source = the container process, sink = the node or host resource, evidence = the security-context setting that permitted the escape.