Containers · Term

What is Kubernetes RBAC?

RBAC decides what every user and workload is allowed to do in a Kubernetes cluster. Get it too broad and a single compromised pod can take over everything. Here is how RBAC works and where it goes wrong.

Containers · TermCloud Penetration Testing
TL;DR

Kubernetes RBAC (Role-Based Access Control) is the system that decides what actions each user, group, and service account may perform on the cluster’s API. It binds roles (sets of permissions) to subjects through role bindings. Misconfigured RBAC, wildcard permissions, cluster-admin granted to workloads, or rights like creating pods, reading secrets, or impersonating, lets an attacker who compromises one identity escalate to full cluster control. Least-privilege RBAC is the core Kubernetes defense.

By John Dill, Red Team Lead, SecureLayer7Updated

What RBAC is

Everything in Kubernetes is done through the API server, and RBAC is the gate that decides whether a given identity is allowed to perform a given action (get, list, create, delete) on a given resource (pods, secrets, nodes).

It works by binding Roles or ClusterRoles (which list permissions) to subjects (users, groups, service accounts) via RoleBindings or ClusterRoleBindings. Whatever a subject is bound to is exactly what it can do.

How weak RBAC is abused

When a pod or user is compromised, the attacker inherits its RBAC rights and hunts for ways to escalate:

  • Wildcards (verbs: ["*"], resources: ["*"]) or cluster-admin bound to a workload, instant full control.
  • `secrets` read access, dump every secret in a namespace or cluster.
  • `create pods`, schedule a privileged pod or one that mounts the node, then escape.
  • `impersonate`, `escalate`, or `bind`, grant themselves more rights.
  • Token creation for other service accounts.

Documented techniques shown for defenders.

How to defend

  • Apply least privilege: no wildcard verbs/resources, no cluster-admin for workloads.
  • Audit dangerous rights: pod creation, secret read, impersonate, escalate, bind, and token creation.
  • Use namespaced Roles over ClusterRoles wherever possible.
  • Review RBAC regularly and use tooling to surface escalation paths.
  • Disable unused service-account token automount so a compromised pod has no key.
  • Test the cluster for RBAC escalation paths.

References

  1. [1]Kubernetes docs: RBAC authorization(Kubernetes)
  2. [2]MITRE ATT&CK: Containers Matrix(MITRE)
  3. [3]NIST SP 800-190 Application Container Security Guide(NIST)
Related terms

Common questions

Container security, asked often

Want your containers and clusters tested for these paths?

Scope an engagement

Find the container escape paths before an attacker does.

We test your Docker hosts and Kubernetes clusters the way a real intruder would, from a compromised pod to the node and the rest of the cluster, then hand your team reproducible evidence and a fix for every step. Free re-test included.

See cloud penetration testing30-min scoping call, fixed-price proposal in 48 hours.