KEY TAKEAWAY
Kubernetes RBAC failures are rarely about a role being obviously wrong. They are about verbs that look administrative rather than dangerous: the ability to create a pod, read a secret or exec into a container each amount to running code as something more privileged than you.
What this lab covers
You start from compromised credentials on an instance that can reach a Kubernetes environment, enumerate what your access permits inside the cluster, and use permissive role bindings to move laterally and escalate to root on the underlying node.
The route from cluster to host is the part worth understanding. A cluster is not a security boundary in the way many teams assume, and several ordinary Kubernetes permissions lead to code execution on the node that runs the workload.
It assumes foundational Kubernetes knowledge and basic Linux familiarity, and suits anyone running workloads on a cluster as much as anyone testing one.
How Kubernetes RBAC is abused
Kubernetes RBAC grants verbs on resources within a namespace or across the cluster. The model is clear, and the difficulty is that the security impact of a verb is not obvious from its name, so roles are written to make an application work and reviewed for whether it works rather than for what else it permits.
Several permissions are escalation primitives. Creating pods allows a workload to be scheduled with a chosen service account, chosen volumes and elevated security context. Reading secrets yields the credentials other workloads use. Executing into a running container provides a shell in something that may be more privileged than the attacker.
The node is frequently reachable from there. A pod scheduled with host mounts, host namespaces or a privileged security context can operate on the node's filesystem and processes, which turns a namespace-scoped permission into root on a machine, and from the node the cloud identity attached to it becomes available.
How to detect this in your own environment
Enable Kubernetes audit logging and ship it somewhere queryable. It is not on by default in every distribution, and without it the cluster's control plane activity is invisible in exactly the way an unconfigured CloudTrail would be.
Alert on pod creation with privileged security contexts, host namespace sharing or host path mounts. These are rare in normal application deployment and are the clearest signal that someone is building an escape.
Watch for secret reads and exec into containers by identities that do not normally perform them. Both are legitimate operations and both have narrow, predictable populations of legitimate users.
How to prevent it
Treat pod creation, secret read and exec as privileged verbs when writing roles, because each is a path to running code as something else. Scope them to namespaces and to the smallest set of identities that genuinely require them.
Enforce workload restrictions with admission control, using Pod Security Standards or a policy engine, so privileged contexts and host mounts are rejected rather than merely discouraged.
Scope the node's cloud identity narrowly and restrict pod access to the cloud metadata service, since that is what converts a cluster compromise into a cloud account compromise.
Real-world context
Kubernetes and container security incidents are widespread. Red Hat's research into Kubernetes adoption and security reports that nearly 60 percent of respondents experienced a misconfiguration incident in their environments in the preceding 12 months, making it the most commonly cited category.
Configuration rather than vulnerability is the recurring theme. Clusters are complex, defaults are permissive in places, and roles accumulate as teams onboard, which produces environments where the shortest path to node root is a role binding nobody remembers granting.
The pattern maps to MITRE ATT&CK T1610 Deploy Container, T1613 Container and Resource Discovery and T1611 Escape to Host.
Applying this at work
- Enumerate which identities in your clusters can create pods, read secrets or exec into containers, and reduce each list.
- Enable Kubernetes audit logging and confirm it reaches a system you can query during an incident.
- Enforce Pod Security Standards or an admission policy that rejects privileged contexts and host path mounts.
- Block pod access to the cloud metadata endpoint so a compromised workload cannot obtain node credentials.
- Review the cloud permissions attached to your node roles, since that is the blast radius of any cluster compromise.
Frequently asked questions
Why is the ability to create pods so dangerous?
Because a pod can be scheduled with a chosen service account, host mounts and an elevated security context. Creating one is therefore a way to run code as a more privileged identity, and potentially to reach the node itself.
Is a Kubernetes cluster a security boundary?
Not in the way many teams assume. Several ordinary permissions lead to code execution on the node running the workload, so a namespace boundary should not be relied on to contain a compromise on its own.
Is Kubernetes audit logging enabled by default?
Not in every distribution, and it frequently is not shipped anywhere queryable even when enabled. Without it, control plane activity in the cluster is effectively invisible during an investigation.
Do I need my own cluster to practice this?
No. The lab runs in a live environment that Pwned Labs provisions for you, so there is nothing to set up and no risk to your own infrastructure.
Which certification covers this in depth?
The Kubernetes Attack and Defense Bootcamp, Professional Edition (KRTP) covers Kubernetes attack paths end to end, including RBAC abuse, workload escape and the route from a cluster into the cloud account behind it.
aws.png)