Kubernetes runs production workloads across all three major clouds, and it is often the platform that red teamers and penetration testers understand least. That gap is the point. The API server sits in front of a datastore, RBAC decides who can do what, and service account tokens and node identity quietly bridge the cluster to the cloud account behind it. Those mechanics create attack paths that go unnoticed by testers who treat a cluster like a normal network. This guide explains how Kubernetes clusters are actually attacked, the methodology and tools a professional uses, and how to learn the discipline to a level an employer can verify.
What is Kubernetes penetration testing?
Kubernetes penetration testing is a controlled, authorized security assessment that simulates how an attacker would compromise a Kubernetes cluster and the infrastructure around it. It goes beyond scanning container images for known vulnerabilities. A real test looks at how identity, access control, workload isolation, and cloud integration combine into exploitable attack paths. Most engagements are grey box: the tester is given access to a container or a low privilege account, which mirrors the most common real world starting point, a single compromised workload. From there the goal is to prove how far that foothold can be taken.
The Kubernetes attack surface
A cluster introduces a set of components that each carry their own risk. Understanding them is the foundation of any assessment.
- The API server. The control plane front door. Every action is an authenticated, authorized API call, so an exposed or weakly protected API server is a direct route to the cluster.
- RBAC. Role-based access control decides which identities can perform which verbs on which resources. Overly permissive roles are the single most common path to cluster compromise.
- Service account tokens. Pods are issued tokens that authenticate to the API server. A mounted token combined with permissive RBAC is a ready-made privilege escalation primitive.
- Pods, containers, and nodes. Workloads share the kernel of the node they run on. Privileged containers, host path mounts, and host namespaces let an attacker break out of a container and take the node.
- etcd and secrets. The cluster datastore holds every secret. Reaching it, directly or through the API server, exposes credentials for the whole environment.
- Admission controllers and webhooks. These intercept API requests and can enforce or, if abused, subvert policy. They are also a persistence and tampering target. See what a Kubernetes admission controller is for detail.
- The cloud identity bridge. On EKS, GKE, and AKS, a pod can reach the cloud metadata service and assume a cloud role through IRSA, EKS Pod Identity, GKE Workload Identity, or AKS workload identity. This is how a cluster foothold becomes a cloud account compromise.
How Kubernetes clusters are actually compromised
Rather than a list of features, it helps to follow the chain that a real attack takes. A Kubernetes penetration test is judged on how completely a tester can walk this path in a live cluster.
- Enumerate the cluster from an unauthenticated external position and from a low privilege pod foothold, mapping the API server, namespaces, workloads, and what the current identity is allowed to do.
- Analyze the service account token and RBAC to find verbs that are equivalent to cluster-admin, for example the ability to create pods, exec into pods, read secrets, or impersonate other accounts.
- Escalate through RBAC misconfigurations to cluster-admin, turning a single workload compromise into full control of the cluster.
- Escape the container to the node by abusing a privileged pod, a host path mount, or host namespace access, then dump every secret the cluster holds.
- Pivot into the cloud account by reaching the instance metadata service from a pod and abusing node IMDS credentials, IRSA, or EKS Pod Identity on EKS, and workload identity on GKE and AKS.
- Establish persistence in the cluster and in the cloud, weaponizing admission webhooks, and reading Kubernetes audit logs to understand exactly what a defender would see.
You can practice several links in this chain directly, including exploiting overly permissive RBAC, escalating from a server side template injection into EKS, and going from prototype pollution to an EKS takeover.
Common Kubernetes misconfigurations and vulnerabilities
Most findings in a Kubernetes penetration test are misconfigurations rather than software bugs, though both matter.
- Overly permissive RBAC. Roles that grant dangerous verbs such as create on pods, pods/exec, get on secrets, or impersonate are effectively cluster-admin. Since Kubernetes v1.22, the tokens projected into pods are bound and short lived by default, and since v1.24 the control plane no longer auto-generates the legacy long lived Secret tokens, but a workload that can create pods or read secrets can still escalate.
- Privileged and over-permissioned pods. Containers run with the privileged flag, extra Linux capabilities, host path volumes, or host network and PID namespaces provide a straightforward container escape to the node.
- Exposed control plane and kubelet. An API server, kubelet, or dashboard reachable without strong authentication is a direct entry point.
- Over-mounted service account tokens. Default automounting of tokens into workloads that do not need API access widens the blast radius of any single container compromise.
- Vulnerable cluster components. Ingress controllers, admission webhooks, and add-ons expand the attack surface. The 2025 IngressNightmare vulnerabilities in the Ingress NGINX controller, chained through the admission controller, allowed unauthenticated remote code execution and cluster secret access on exposed clusters, a reminder that a single add-on can compromise the whole environment.
Kubernetes penetration testing methodology
A repeatable methodology keeps an assessment thorough and defensible. A typical Kubernetes engagement moves through these phases.
- Scoping and reconnaissance. Agree the authorized scope, then map exposed endpoints, the API server, and cluster metadata.
- Enumeration and access review. From the given foothold, enumerate namespaces, workloads, and the effective permissions of the current identity.
- Privilege escalation. Turn permissive RBAC and mounted tokens into higher privilege, up to cluster-admin.
- Lateral movement and container escape. Move between workloads and break out to the node where isolation is weak.
- Cloud pivot. Use node or workload identity to reach the cloud account and assess the blast radius beyond the cluster.
- Persistence and detection review. Understand what an attacker could leave behind, and what the cluster's audit logging and detections would catch.
- Reporting. Document the attack chain, the impact, and prioritized, practical remediation.
Tools for Kubernetes penetration testing
Tooling supports the methodology, it does not replace it. The core toolkit includes:
- kubectl and curl for interacting with the API server and inspecting permissions, including kubectl auth can-i for effective access review.
- kdigger and peirates for in-cluster context discovery and escalation workflows during authorized testing.
- kube-bench for configuration and CIS benchmark posture, and k8scout for attack path analysis from a pod foothold. It maps RBAC, tokens, workloads and cloud identity bindings into escalation chains to cluster-admin, the node and the cloud account, each mapped to MITRE ATT&CK. kube-hunter still shows up in older guidance, but it hasn't had a release since 2024 and is no longer maintained.
- Cloud provider tooling to enumerate the account once you pivot, since a Kubernetes test that stops at the cluster edge misses the real impact.
On the defensive side, the same testing informs guardrails such as least privilege RBAC, Pod Security Standards, and policy engines. You can see the defensive counterpart in the securing Kubernetes with OPA Gatekeeper lab.
How to learn Kubernetes penetration testing
Kubernetes penetration testing is learned by doing it against real clusters, not by reading about features. This is the path we recommend, and the one the KRTP bootcamp follows.
- Get comfortable on Linux and with containers. You need the command line, and an understanding of how containers share a kernel. You do not need to be an expert.
- Learn Kubernetes fundamentals in a local cluster. Stand up minikube, read YAML and JSON fluently, and understand pods, services, namespaces, and RBAC.
- Study identity and access. Service account tokens, RBAC verbs, and how the API server authorizes requests are where most escalation happens.
- Attack a live cluster. Practice the full chain, enumeration to cluster-admin to node escape, in a cluster that is logging your activity, so you build blue team awareness as you go.
- Extend to managed Kubernetes. Learn how EKS, GKE, and AKS turn a service account token into a cloud credential, because that is where cluster compromise becomes cloud compromise.
- Validate with a hands-on certification. Prove the skill in a live assessment an employer can trust, rather than a multiple choice exam.
Only ever test clusters you own or are explicitly authorized to assess. The techniques on this page are for professional, authorized security work.
Best Kubernetes security training and certification
The strongest Kubernetes security training is hands-on, offense-aware, and takes you all the way from a low privilege pod to the cloud account behind the cluster. The Pwned Labs Kubernetes Attack and Defense bootcamp is built to do exactly that. It starts from fundamentals in minikube and progresses into RBAC escalation, container escape, and cloud identity abuse across EKS, GKE, and AKS, then certifies you hands-on with the Kubernetes Red Team Professional (KRTP). Because the labs run in production-like clusters with real telemetry, you also learn what defenders see, which is what separates a Kubernetes red teamer from someone who only ran a script. You do not need prior Kubernetes experience to start. For the wider curriculum, see our Kubernetes and container security training overview.
KRTP compared to CKS
The two credentials solve different problems and complement each other.
| Aspect | KRTP | CKS |
|---|---|---|
| Orientation | Offense-led, with a strong blue-team detection focus | Defensive, hardening and operations |
| Format | Attack a live cluster, capture the flag | Configure and secure a cluster |
| Covers cloud pivot | Yes, EKS, GKE, and AKS identity abuse | No |
| Best for | Pentesters, red teamers, and the defenders and security engineers who want the attacker mindset to build detections | Platform and security engineers |
Ready to attack a live cluster? Explore the Kubernetes Attack and Defense bootcamp (KRTP).
Frequently asked questions
Do I need Kubernetes experience to start Kubernetes penetration testing?
No. You need comfort on the Linux command line, the ability to read YAML and JSON, and a general security foundation. The KRTP bootcamp opens with fundamentals in minikube before moving into RBAC escalation, container escape, and cloud identity abuse, so the ramp is built into the path.
How is KRTP different from the Certified Kubernetes Security Specialist (CKS)?
CKS is a defensive, configuration-focused exam that proves you can harden and operate a secure cluster. KRTP is offensive and fully hands-on, assessed by attacking a live cluster and pivoting into the cloud account behind it. They are complementary.
What tools are used for Kubernetes penetration testing?
Core tools include kubectl and curl for API interaction and access review, kube-bench for CIS benchmark posture, and kdigger and peirates for in-cluster discovery and escalation during authorized testing. k8scout runs from a pod foothold and maps RBAC, tokens, workloads and cloud identity bindings into escalation paths to cluster-admin, the node and the cloud account. kube-hunter and kubeaudit appear in older guidance but are no longer maintained. Cloud provider tooling is used once you pivot from the cluster into the account.
Is Kubernetes penetration testing legal?
Only when it is authorized. Test clusters you own or have explicit written permission to assess. Use dedicated practice environments, such as Pwned Labs labs and the KRTP bootcamp, to build skills safely and legally.
How long does it take to learn Kubernetes penetration testing?
With a general security foundation, a focused learner can reach practical competence in a few weeks of hands-on work. The KRTP bootcamp is on-demand with lifetime access, so you can move at your own pace and repeat the live environments as often as you need.