Lion Cipher Lab
Escape a Kubernetes pod to the node: break out with a privileged pod and a hostPath mount — then lock it down with Pod Security Admission
- Cloud Security
- Advanced
- ~90 min
- Free · no account required
Why it matters
A Kubernetes cluster is a shared machine: many pods, often from many teams, run on the same physical nodes, kept apart only by Linux namespaces and a handful of securityContext settings. The whole security model rests on the assumption that a pod cannot reach the node it runs on. But that isolation is OPT-IN, and the defaults are generous — a pod that is allowed to run `privileged: true`, or to mount a `hostPath`, or to share the host PID namespace, is not really contained at all. Any one of those, granted to a workload an attacker can reach, turns a single compromised container into control…
What you'll learn
- standing up a disposable single-node Kubernetes cluster with kind
- escaping a privileged pod into the node's namespaces with nsenter
- reading the host filesystem from a pod via a hostPath volume mount
- mapping the breakout to MITRE ATT&CK T1611 (Escape to Host)
- blocking it with Pod Security Admission (restricted) and a hardened securityContext
Steps in this lab
- Why a pod can become the node — the three dangerous grants
- Build a disposable cluster with kind
- Attack 1 — privileged pod, then nsenter into the node
- Attack 2 — read the node's filesystem through a hostPath mount
- Defense — Pod Security Admission at 'restricted' rejects them at the door
- Harden the workload that DOES need to run
- When to reach for this thinking — the judgment that matters