Cybersecurity glossary
What is Kubernetes RBAC?
Learn what Kubernetes RBAC is, how Roles, ClusterRoles, and bindings authorize API verbs, and how to avoid cluster-admin and overbroad service accounts.
Definition
Kubernetes RBAC is the API server’s role-based authorization mode: Roles and ClusterRoles list allowed verbs on API resources, and RoleBindings or ClusterRoleBindings attach those permissions to users, groups, or service accounts.
Why Kubernetes RBAC matters
Everything that changes a cluster goes through the API server: kubectl, operators, CI, and in-cluster controllers. Kubernetes RBAC is the map of who may get, list, create, bind, or delete those objects.
A leaked service account token with cluster-admin is not a “container issue.” It is full control of workloads, Secrets, RBAC itself, and often the cloud identity attached to nodes.
How an API call is authorized
The caller is identified
A user, group, or service account presents a certificate, token, or OIDC assertion.
The request names a verb and resource
Examples: get pods, create deployments, bind clusterroles, impersonate users.
Bindings are collected
RoleBindings in the namespace and ClusterRoleBindings at cluster scope attach Roles to the identity.
Rules are matched
apiGroups, resources, resourceNames, and verbs must cover the request. Wildcards match everything.
Escalate and impersonate checks apply
Kubernetes blocks some self-grants of extra privileges unless the caller already has them.
The four objects you will edit
Role
Namespaced permission set: which verbs on which resources inside one namespace.
ClusterRole
Cluster-wide permission set, or a reusable template bound into many namespaces.
RoleBinding
Attaches a Role or ClusterRole to subjects in a single namespace.
ClusterRoleBinding
Attaches a ClusterRole to subjects across the whole cluster—handle like production IAM.
Kubernetes RBAC anti-patterns
| Pattern | Why it appears | Replace with |
|---|---|---|
| cluster-admin on CI or humans | Fastest way to make kubectl apply work | A Role limited to the app’s namespace and resource types |
| verbs: ['*'] / resources: ['*'] | Copy-paste from a tutorial ClusterRole | Explicit get/list/watch/create/update/patch/delete as needed |
| Default service account in every pod | Automount enabled by default in older clusters | Dedicated SA, automount disabled unless the API is required |
| bind / escalate / impersonate for operators | The operator “needs to create roles” | Pre-created Roles the operator may only use, not edit |
| Secrets get/list for the whole namespace | A debug container or dashboard convenience | resourceNames limits or a secrets CSI driver with workload identity |
Kubernetes RBAC checklist
- Inventory ClusterRoleBindings and treat cluster-admin as break-glass only.
- Give each controller and CI job its own service account and a Role that lists exact resources.
- Disable automountServiceAccountToken on pods that never call the Kubernetes API.
- Forbid wildcard verbs and resources in custom Roles; review bind, escalate, impersonate, and secrets.
- Prefer RoleBindings in the app namespace over ClusterRoleBindings for application teams.
- Use impersonation only for audited break-glass, never as a standing dashboard feature.
- Audit RBAC objects themselves; who can edit Roles is as sensitive as who can exec into pods.
- Remember RBAC does not isolate networks or nodes—pair it with NetworkPolicy and pod security.
The practical takeaway
Kubernetes RBAC authorizes API verbs through Roles and bindings. It is not pod isolation, not cloud IAM, and not a substitute for admission policy.
Grant the smallest Role that makes the controller work, never bind cluster-admin to pipelines or default service accounts, and watch the verbs that create more RBAC. The API server is the cluster’s front door—RBAC is the lock map.
Related security terms
Role-Based Access Control (RBAC)
The general authorization model that Kubernetes implements for its API.
Kubernetes Admission Controller
Runs after RBAC and can still reject an authorized but unsafe object.
Workload Identity
How pods obtain cloud credentials; Kubernetes RBAC still governs their API access.
Least Privilege
The design target for every Role and ClusterRole in the cluster.
Privilege Escalation
bind, escalate, and impersonate verbs are classic Kubernetes privilege paths.
Frequently asked questions
What is Kubernetes RBAC in simple terms?
It is the permission system for the Kubernetes API. Roles name what verbs you may call on which resources; bindings name who gets those roles.
How is Kubernetes RBAC different from generic RBAC?
Generic RBAC is a model. Kubernetes RBAC is a specific implementation: Role/ClusterRole objects, namespace versus cluster scope, and verbs such as get, list, watch, create, bind, and impersonate.
What is the difference between a Role and a ClusterRole?
A Role is namespaced. A ClusterRole is cluster-scoped and can grant access to cluster resources (nodes, CRDs) or be reused across namespaces via RoleBinding.
Why is cluster-admin dangerous?
It can do every verb on every resource, including creating new ClusterRoleBindings. Anyone or any controller that holds it can take over the cluster.
Do NetworkPolicies or Pod specs use Kubernetes RBAC?
RBAC only authorizes Kubernetes API calls. It does not filter pod traffic or syscalls. A service account that cannot list Secrets can still read a Secret volume if the pod mounts it.
What is RBAC privilege escalation inside Kubernetes?
Granting bind, escalate, impersonate, or wildcard create on Roles lets a principal mint more power than they currently have. Kubernetes has an 'escalate' check—do not disable the thinking behind it.
Should every pod get a service account token?
Automount only when the workload must call the API. Bound tokens should be audience-scoped, short-lived, and tied to a Role that lists exact resources.
References
Explore authoritative guidance and frameworks related to kubernetes rbac.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.