Container Escape Detection

What is a container escape?

A container escape occurs when a process inside a container successfully exits its namespace boundaries and gains access to the host OS, other containers, or the Kubernetes node filesystem. This breaks the core isolation guarantee of container runtimes.

Common escape vectors include:

• Namespace breakout via unshare() — the attacker calls unshare(CLONE_NEWPID) or similar to detach from container namespaces
• Privileged container abuse — container running with --privileged flag, allowing direct mount access to host filesystem
• Volume mount escape — misconfigured hostPath volumes that expose sensitive directories like /proc or /sys
• runc CVE exploitation — abusing known vulnerabilities in the container runtime itself

How Kubesentry detects container escapes

Kubesentry's eBPF probes monitor syscall patterns that characterize namespace breakout attempts — at the kernel level, before any application-layer detection can be bypassed.

• unshare() syscall monitoring — alerts on calls with CLONE_NEWPID, CLONE_NEWNS, CLONE_NEWNET flags from containerized processes
• chroot() anomaly detection — detects chroot calls that target paths outside the container rootfs boundary
• /proc filesystem access tracking — monitors access to /proc/1/root and /proc/*/ns paths that indicate namespace introspection
• mount() call analysis — flags mount operations with MS_BIND that target host paths, common in privileged container escapes
• Process tree context — every alert includes the full process lineage from container PID 1 to the escaping process

Response playbook

1. Acknowledge the PagerDuty/Slack alert. Check container ID, namespace, and node name. Note the timestamp for forensic chain of custody.
2. Isolate the pod. Use Kubesentry's auto-isolate action or manually: kubectl cordon <node> and kubectl delete pod <pod> --grace-period=0
3. Preserve forensic state. Export the event log from Kubesentry before the pod is fully terminated. Review the process tree to identify parent PID and entry vector.
4. Assess host integrity. If escape was successful, run kubectl exec into a diagnostic pod on the same node to check for unexpected processes, modified files, or new cron jobs.
5. Remediate the root cause. Identify the misconfiguration (privileged flag, hostPath volume, image vulnerability) and apply the fix. Block the image digest from re-deploying via admission controller.
6. Post-incident review. Document escape vector, dwell time from first anomalous syscall to alert, and remediation steps. Update policy rules to tighten detection.

Related detections