What Is RBAC in Kubernetes? Role-Based Access Control Explained Simply
RBAC in Kubernetes controls who can do what in your cluster. Learn what Roles, ClusterRoles, RoleBindings, and ServiceAccounts are with real examples.
When you first run kubectl, you can do anything — create pods, delete namespaces, view secrets. That's fine on your laptop. In production with a team, you need to control who can do what.
That's what RBAC is for.
What Is RBAC?
RBAC = Role-Based Access Control
It's Kubernetes' built-in permission system. You define:
- Who can do something (User, Group, or ServiceAccount)
- What they can do (list, create, delete, etc.)
- Where they can do it (specific namespace or cluster-wide)
The Four RBAC Objects
1. Role
A Role defines what actions are allowed in a specific namespace.
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: pod-reader
namespace: production
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "watch", "list"]This role can only read pods in the production namespace. Nothing else.
Common verbs:
| Verb | What it does |
|---|---|
get | Read a specific resource |
list | List all resources |
watch | Watch for changes |
create | Create new resource |
update | Update existing |
patch | Partial update |
delete | Delete resource |
2. ClusterRole
A ClusterRole is like a Role but cluster-wide (all namespaces, or cluster-scoped resources like nodes).
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: secret-reader
rules:
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get", "list"]
- apiGroups: [""]
resources: ["nodes"]
verbs: ["get", "list", "watch"]3. RoleBinding
A RoleBinding connects a Role to a User/Group/ServiceAccount.
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-pods-binding
namespace: production
subjects:
- kind: User
name: alice
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.ioNow Alice can read pods in the production namespace.
4. ClusterRoleBinding
Binds a ClusterRole to a subject cluster-wide.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: cluster-admin-binding
subjects:
- kind: User
name: admin-user
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: cluster-admin
apiGroup: rbac.authorization.k8s.ioServiceAccounts — RBAC for Pods
When your application (a pod) needs to talk to the Kubernetes API, it uses a ServiceAccount.
# 1. Create a ServiceAccount
apiVersion: v1
kind: ServiceAccount
metadata:
name: my-app
namespace: production
---
# 2. Create a Role
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: configmap-reader
namespace: production
rules:
- apiGroups: [""]
resources: ["configmaps"]
verbs: ["get", "list"]
---
# 3. Bind them
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: my-app-configmap-binding
namespace: production
subjects:
- kind: ServiceAccount
name: my-app
namespace: production
roleRef:
kind: Role
name: configmap-reader
apiGroup: rbac.authorization.k8s.io
---
# 4. Use the ServiceAccount in your Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
namespace: production
spec:
template:
spec:
serviceAccountName: my-app
containers:
- name: app
image: my-app:1.0Built-in ClusterRoles
Kubernetes includes several ready-to-use ClusterRoles:
| ClusterRole | Access |
|---|---|
cluster-admin | Full access to everything |
admin | Full access within a namespace |
edit | Create/update/delete most resources |
view | Read-only access |
# Give a user edit access to a namespace
kubectl create rolebinding dev-edit \
--clusterrole=edit \
--user=dev-user \
--namespace=staging
# Give a user view access cluster-wide
kubectl create clusterrolebinding readonly-global \
--clusterrole=view \
--user=readonly-userCheck What You Can Do
# Can I create pods in production?
kubectl auth can-i create pods -n production
# Can user alice delete deployments?
kubectl auth can-i delete deployments \
--as=alice \
-n production
# List all permissions for a user
kubectl auth can-i --list --as=alice -n productionCommon RBAC Patterns
Developer — can deploy but not delete
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: developer
namespace: staging
rules:
- apiGroups: ["apps"]
resources: ["deployments"]
verbs: ["get", "list", "create", "update", "patch"]
- apiGroups: [""]
resources: ["pods", "pods/logs"]
verbs: ["get", "list", "watch"]
- apiGroups: [""]
resources: ["configmaps"]
verbs: ["get", "list", "create", "update"]Read-only access for monitoring tools
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: monitoring-reader
rules:
- apiGroups: [""]
resources: ["nodes", "pods", "services", "endpoints"]
verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
resources: ["deployments", "replicasets", "daemonsets"]
verbs: ["get", "list", "watch"]
- nonResourceURLs: ["/metrics"]
verbs: ["get"]Debugging RBAC Issues
When you get Error from server (Forbidden):
# Step 1: Check the error
kubectl get pods -n production
# Error: User "alice" cannot list resource "pods"
# Step 2: Check permissions
kubectl auth can-i list pods -n production
# Step 3: Find what role they have
kubectl get rolebindings -n production -o yaml | grep -A5 alice
# Step 4: Check the role
kubectl describe role pod-reader -n productionRBAC Best Practices
- Least privilege — give only the permissions actually needed
- Use Roles (not ClusterRoles) for namespace-scoped work
- Never use
cluster-adminfor application ServiceAccounts - Audit with
kubectl auth can-i --list - Set
automountServiceAccountToken: falseon pods that don't need API access
spec:
automountServiceAccountToken: false
containers:
- name: appSummary
Role → permissions in one namespace
ClusterRole → permissions cluster-wide
RoleBinding → attach Role to User/Group/ServiceAccount
ClusterRoleBinding → attach ClusterRole cluster-wide
ServiceAccount → identity for pods
RBAC is one of those things that seems complex until you use it once. After that, it's just: create role → create binding → done.
CKA Exam Tip: RBAC is heavily tested in the CKA exam. Practice creating Roles, ClusterRoles, and Bindings from scratch with
kubectl createcommands.
KodeKloud CKA Course — the best resource for mastering RBAC with hands-on labs. Covers all the scenarios you'll see in the exam and in production.
Today I Fixed
Short real fixes from production — posted daily
Stay ahead of the curve
Get the latest DevOps, Kubernetes, AWS, and AI/ML guides delivered straight to your inbox. No spam — just practical engineering content.
Related Articles
How to Set Up HashiCorp Vault for Secrets Management from Scratch (2026)
HashiCorp Vault is the industry standard for secrets management. This step-by-step guide shows you how to install Vault, configure it, and integrate it with Kubernetes.
What is a Service Mesh? Explained Simply (No Jargon)
Service mesh sounds complicated but the concept is simple. Here's what it actually does, why teams use it, and whether you need one — explained without the buzzwords.
What is a ConfigMap and Secret in Kubernetes? Explained Simply (2026)
ConfigMaps and Secrets separate configuration from code in Kubernetes. Here's what they are, how they work, and when to use each one — explained simply.