Kubernetes penetration testing assesses a cluster and its workloads from an attacker's perspective — usually starting from a foothold like a compromised container or low-privileged account — to find the path to cluster or cloud compromise. The recurring issues are over-permissive RBAC, an exposed API server or dashboard, container escapes from privileged pods, missing network policies, insecurely stored secrets, and a vulnerable image supply chain. Almost all are misconfigurations, not Kubernetes bugs — so hardening (to the CIS Kubernetes Benchmark) and testing matter more than patching. It's a specialised extension of cloud penetration testing and pairs with a hardening review.
// 01 Why Kubernetes needs its own testing
Kubernetes isn't a single application; it's a distributed control plane orchestrating many workloads across many nodes, with its own identity system (RBAC), network model, secrets store and admission controls. That's a lot of moving parts, each with a secure and an insecure setting — and the insecure ones are easy to reach by accident when teams optimise for "get it running." The result is that the dangerous flaws are almost never CVEs in Kubernetes; they're configuration choices: a service account with too many rights, a pod running privileged, a dashboard left exposed. You can't patch your way out of those; you have to find and fix them, which is what a cluster test does.
// 02 The attack surface
RBAC misconfiguration
Service accounts or users with more rights than they need — the fastest route from a small foothold to cluster control.
Exposed control plane
An API server, kubelet or dashboard reachable or weakly authenticated — direct access to the cluster's brain.
Container escape
Privileged pods, dangerous capabilities, or host mounts that let an attacker break out to the node and beyond.
Flat networking
No network policies, so a compromised pod can talk freely to every other pod — unhindered lateral movement.
Exposed secrets
Secrets in plain environment variables or unencrypted stores, readable once a pod is compromised.
Image supply chain
Vulnerable, outdated or unverified container images pulling in risk before the workload even runs.
// 03 The container-escape chain
The scenario that turns a minor issue into a major incident is the escape-and-pivot chain. It usually runs: an attacker gets code execution in a container (a web app flaw, a poisoned image); the container is over-privileged — running as root, with dangerous capabilities, or mounting the host filesystem or Docker socket; that lets them escape to the node; on the node they reach other containers, kubelet credentials and, in the cloud, the instance metadata service and its IAM credentials; from there, over-permissive RBAC or cloud IAM carries them to cluster-wide or cloud-account compromise. Every link is a configuration choice, and breaking any one — non-root containers, dropped capabilities, no host mounts — stops the chain. Testing traces exactly this path in your cluster.
// 04 How testers assess a cluster, and how to harden it
A cluster test typically starts from an assumed foothold and works outward: enumerate RBAC to find privilege-escalation paths, probe the exposure and authentication of control-plane components, test whether pod configurations permit escape, check network segmentation between namespaces and pods, and inspect secrets handling and image provenance. On the defensive side, the hardening priorities map straight onto the surface above:
- Least-privilege RBAC and no cluster-admin sprawl.
- Lock down and authenticate the API server; remove exposed dashboards.
- Non-root containers, minimal capabilities, no unnecessary host mounts.
- Network policies to segment pod-to-pod traffic.
- Proper secrets management and admission control to enforce policy.
- Secure the image supply chain with scanning and signed, verified images.
Benchmark against the CIS Kubernetes Benchmark and validate with testing — the two together in our cloud testing and hardening review.
// 05 Frequently asked questions
What is Kubernetes penetration testing?
Assessing a container orchestration cluster and its workloads from an attacker's perspective, usually from an initial foothold, to find the path to cluster or cloud compromise. It covers RBAC, API-server exposure, container escapes and lateral movement, secrets, and the image supply chain.
What are the most common Kubernetes issues?
Over-permissive RBAC, an exposed or weakly authenticated API server or dashboard, containers running privileged with host mounts enabling escape, missing network policies, insecurely stored secrets, and vulnerable or unverified images. Most are misconfigurations, not software bugs.
What is a container escape?
Breaking out of a container's isolation to reach the host node — and potentially the whole cluster. It usually results from a container running with excessive privileges (privileged mode, dangerous capabilities, host mounts), not a runtime flaw. On the node an attacker can reach other containers, node credentials and cloud metadata.
How do you secure a Kubernetes cluster?
Least-privilege RBAC, locked-down authenticated API server, non-root containers with minimal capabilities, network policies, proper secrets management, admission control, and a secured image supply chain. Benchmark against the CIS Kubernetes Benchmark and validate with penetration testing.
// 06 References
- CIS — Kubernetes Benchmark; NSA/CISA Kubernetes Hardening Guidance; MITRE ATT&CK Containers matrix.
- Related: our cloud penetration testing, cloud RoE, and hardening review.