Kubernetes RBAC: roles, cluster roles, bindings and service accounts
In short: Kubernetes RBAC grants permissions by binding users, groups or service accounts to roles that list allowed verbs on resources. Roles are namespaced; ClusterRoles can apply across the cluster. Least privilege means namespace-scoped bindings, no wildcards, careful handling of powerful verbs and dedicated service accounts per workload.
The building blocks
Kubernetes RBAC is additive: there are no deny rules, so a subject can do only what some binding allows. Four object types are involved:
A subject is a user, a group or a service account. Kubernetes does not store human users itself; they come from client certificates or, more commonly in the cloud, an OIDC identity provider or the cloud's IAM. Service accounts are Kubernetes objects used by pods.
A least-privilege example
This gives a deployment pipeline permission to manage Deployments in one namespace only, and nothing else:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: deployer
namespace: shop
rules:
- apiGroups: ["apps"]
resources: ["deployments"]
verbs: ["get", "list", "watch", "create", "update", "patch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: deployer-binding
namespace: shop
subjects:
- kind: ServiceAccount
name: ci-deployer
namespace: shop
roleRef:
kind: Role
name: deployer
apiGroup: rbac.authorization.k8s.ioYou can test what a subject can do with kubectl auth can-i:
kubectl auth can-i create deployments -n shop --as system:serviceaccount:shop:ci-deployer
kubectl auth can-i get secrets -n shop --as system:serviceaccount:shop:ci-deployer
kubectl auth can-i --list -n shop --as system:serviceaccount:shop:ci-deployerDangerous permissions
| Permission | Why it is risky |
|---|---|
cluster-admin binding | Full control of everything; keep to a tiny break-glass group |
Wildcards * in resources or verbs | Grants future resource types you have not thought about |
get/list on secrets | Reveals passwords and tokens, often leading to wider access |
create pods | A pod can mount any secret or service account in its namespace, and may be privileged if pod security allows |
escalate, bind, impersonate | Let a subject grant itself or act as more powerful identities |
nodes/proxy, pods/exec | Direct access into nodes or running containers |
Service accounts done well
- Give each application its own service account rather than using
default. - Set
automountServiceAccountToken: falsefor pods that never call the Kubernetes API. - Modern clusters issue short-lived, audience-bound projected tokens; avoid creating long-lived token Secrets.
- Link service accounts to cloud IAM through workload identity (for example EKS Pod Identity or IRSA, AKS Workload Identity, GKE Workload Identity Federation) instead of storing cloud keys.
Tip: review all ClusterRoleBindings regularly. Tools such as kubectl get clusterrolebindings -o wide or open-source RBAC analysers help spot unexpected cluster-admin grants.
Practice
What is the difference between a Role and a ClusterRole?
Why can permission to create pods lead to privilege escalation?
How do you check whether a service account can read secrets in a namespace?
Key takeaways
- RBAC is additive: subjects get only what bindings allow.
- Roles and RoleBindings are namespaced; Cluster versions span the cluster.
- Avoid wildcards, cluster-admin and broad access to secrets.
- Watch powerful verbs such as escalate, bind, impersonate and pod creation.
- Use one service account per app and disable token mounting when unused.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.