Kubernetes RBAC explained: Roles, bindings and working examples

Role-Based Access Control (RBAC) is the mechanism Kubernetes uses to decide what authenticated users and service accounts are allowed to do. Once a request passes authentication (who are you?), RBAC handles authorisation (what are you allowed to do?).

This guide covers how RBAC works, the four core objects, and working examples you can apply to your own cluster.

Authorisation modes

Kubernetes supports several authorisation modes. In practice, almost all clusters use RBAC. The others are worth knowing about briefly:

The four RBAC objects

RBAC is built on four objects. Two define permissions, two bind those permissions to identities.

A subject can be a user, a group, or a service account.

One important pattern: you can bind a ClusterRole with a RoleBinding. This lets you define a reusable role at the cluster level but restrict its effect to a single namespace. This is cleaner than creating identical Roles in every namespace.

Working example: namespace access for a service account

This example creates a service account, grants it permissions on specific resources in a namespace, and verifies the access works.

Step 1: Create a namespace and service account

1kubectl create namespace demo
2kubectl create sa sam -n demo
3kubectl get serviceaccount -n demo

Expected output:

1NAME      SECRETS   AGE
2default   0         5s
3sam       0         2s

Step 2: Create a Role

1apiVersion: rbac.authorization.k8s.io/v1
2kind: Role
3metadata:
4  name: pod-reader
5  namespace: demo
6rules:
7- apiGroups: ["", "apps"]
8  resources: ["pods", "deployments"]
9  verbs: ["get", "list", "watch"]

1kubectl apply -f role.yaml

Step 3: Create a RoleBinding

1apiVersion: rbac.authorization.k8s.io/v1
2kind: RoleBinding
3metadata:
4  name: pod-reader-binding
5  namespace: demo
6subjects:
7- kind: ServiceAccount
8  name: sam
9  namespace: demo
10roleRef:
11  kind: Role
12  name: pod-reader
13  apiGroup: rbac.authorization.k8s.io

1kubectl apply -f rolebinding.yaml

Step 4: Verify with kubectl auth can-i

1kubectl auth can-i get pods --as=system:serviceaccount:demo:sam -n demo

Expected output:

1yes

1kubectl auth can-i delete pods --as=system:serviceaccount:demo:sam -n demo

Expected output:

1no

1kubectl auth can-i get pods --as=system:serviceaccount:demo:sam -n default

Expected output:

1no

The service account can read pods in the demo namespace but not delete them and not access any other namespace. This confirms the RoleBinding is scoped correctly.

Working example: ClusterRole and ClusterRoleBinding

Use a ClusterRole when you need permissions that span the whole cluster or apply to cluster-scoped resources.

1kubectl create clusterrole cr --verb=get,list,watch,delete --resource=secrets,pods,deployments

Bind the ClusterRole to the service account using a RoleBinding (namespace-scoped) rather than a ClusterRoleBinding to limit its effect to the demo namespace:

1kubectl create rolebinding super --serviceaccount=demo:sam -n demo --clusterrole=cr

Verify:

1kubectl auth can-i get pods --as=system:serviceaccount:demo:sam -n demo

Expected output:

1yes

1kubectl auth can-i get pods --as=system:serviceaccount:demo:sam -n default

Expected output:

1no

Common patterns

Read-only access to a namespace

Useful for monitoring agents, logging pipelines, and CI systems that need to inspect resources without modifying them:

1apiVersion: rbac.authorization.k8s.io/v1
2kind: Role
3metadata:
4  name: read-only
5  namespace: production
6rules:
7- apiGroups: ["", "apps"]
8  resources: ["pods", "deployments", "services", "configmaps"]
9  verbs: ["get", "list", "watch"]

CI/CD service account with deploy permissions

A service account that can create and update Deployments but cannot read Secrets:

1apiVersion: rbac.authorization.k8s.io/v1
2kind: Role
3metadata:
4  name: deployer
5  namespace: production
6rules:
7- apiGroups: ["apps"]
8  resources: ["deployments"]
9  verbs: ["get", "list", "create", "update", "patch"]
10- apiGroups: [""]
11  resources: ["services", "configmaps"]
12  verbs: ["get", "list", "create", "update", "patch"]

View-only ClusterRole for developer access

Kubernetes includes a built-in view ClusterRole you can bind to developers who need read access across all namespaces:

1kubectl create clusterrolebinding developer-view \
2  --clusterrole=view \
3  --user=developer@example.com

List all permissions for a service account

1kubectl auth can-i --list --as=system:serviceaccount:demo:sam -n demo

This outputs every verb and resource the service account is permitted to act on in the demo namespace.