Your Container Security Audit Is Not a Penetration Test
The Kubernetes security audit came back clean. Pod Security Admission is configured. RBAC roles appear properly scoped. No wildcard cluster-admin bindings visible in the automated scan results.
Three hours into the actual penetration test, the tester has escalated from a compromised application container to full cluster-admin access. The configuration scan did not lie. It accurately described the settings as they existed in the policy files. What it could not do was follow the chain from a realistic initial foothold to the specific combination of misconfigurations that, applied in sequence, hands the cluster to someone with patience and a working methodology.
Container escape testing is a specific discipline. The organizations that buy Kubernetes security reviews and assume they have done the penetration testing equivalent are making a significant assumption about what each exercise actually measures.
What "Container Escape" Actually Means
A container escape is the path from inside a container to the underlying host or to a privilege level beyond what the workload was intended to have. The goal in a container penetration test is not just to break out of one container: it is to establish what is accessible from a realistic initial position that the deployment assumes is not reachable.
In most enterprise Kubernetes environments, the most valuable targets are not the hosts themselves. They are the service account tokens with cluster-wide permissions, the secrets mounted into other pods, the internal APIs accessible from the pod network that assume container traffic is trusted, and the paths from a compromised application container to an orchestrator with elevated access.
Configuration scans look at policy files and report what they say. Penetration tests start from a container and demonstrate what you can actually reach from there.
The Privileged Container Problem
Privileged containers are the most direct escape path. A container running with privileged: true has full access to the host's devices and kernel capabilities. From inside a privileged container, you can mount the host filesystem, read any file on the node, and write to locations that modify host configuration. The escape is straightforward.
Privileged containers appear in production environments for reasons that made operational sense to someone at the time: a monitoring agent that needs raw access to host metrics, a network plugin that requires kernel-level visibility, a legacy application containerized by wrapping it in a container image and never properly reviewed. Each of those is a container that provides a path from "compromised application" to "control of the underlying node."
This finding appears with higher frequency than it should, partly because Pod Security Admission enforcement is not always applied uniformly across all namespaces, and partly because the teams deploying these containers often do not have detailed visibility into what privileged: true actually enables in practice.
The Docker Socket Mount
The Docker socket - /var/run/docker.sock - is the control channel for the container runtime. A container with this socket mounted can issue commands to create new containers, including privileged ones, and can use those containers to mount the host filesystem and establish a foothold outside the original container's context.
This attack path is documented in every container security reference, and it still appears in production deployments. It appears because developers who need container inspection or CI pipeline functionality find that mounting the socket is the fastest path to getting things working. Security review catches it when someone is specifically looking for it. When the scope of a security engagement does not include container escape methodology, no one is looking for it.
A penetration test that includes container escape methodology looks for mounted sockets explicitly. A configuration scan catches it when the mount is visible in the pod spec. Dynamic analysis during an active assessment catches it when the spec is not an accurate reflection of what is actually running.
Service Account Tokens and the Cluster API
Every pod in Kubernetes gets a service account token mounted by default unless the configuration explicitly disables automounting. That token is a credential for the Kubernetes API.
The value of the token depends entirely on what the service account can do. From inside a compromised container, the tester calls the Kubernetes API using the mounted token and enumerates: can this token list pods across namespaces? List secrets? Create deployments? Each permission is a step in a privilege escalation chain.
The finding is not "a service account token was mounted." The finding is "this service account token could list secrets across all namespaces and we extracted the credentials stored in those secrets, including database passwords and API keys for production services." The RBAC review a configuration scan performs against role definitions does not catch the effective permissions that accumulate through role binding combinations that each looked reasonable in isolation.
Tools that graph service account permissions visually, similar to what BloodHound does for Active Directory, surface these chains in a way that makes the risk concrete. The first time a security team sees the graph of which service accounts can reach which privileges through which binding chains, the reaction is usually a pause followed by some pointed questions about how those bindings accumulated over time.
Why Configuration Scanning Is Not Sufficient
A configuration scan measures whether your policies say the right things. A penetration test measures whether an attacker can achieve a defined objective starting from a realistic initial foothold.
The two are not alternatives. Both provide value. A configuration scan gives useful baseline visibility into policy coverage. But the organizations that run a configuration scan on their cluster and treat container security as addressed have measured only one dimension of a problem with several.
An application vulnerability, a misconfigured admission webhook, a workload deployed outside the hardened namespace policies because it was a quick temporary fix that became permanent: any of those provides an initial foothold. What happens after the foothold is what the penetration test answers.
The configuration scan reports what you told the cluster to do. The penetration test shows what the cluster actually does with a tester inside it. Those two things are not always the same, and the gap between them is the finding.