Kubernetes RBAC: Who Can Do What, and Where?

Let’s be honest: giving everyone admin access to your cluster is fast… until it isn’t. Enter RBAC, short for Role-Based Access Control—Kubernetes’ way of saying “hold up, who let you in here?”

RBAC defines who can perform what actions on which resources—like a VIP list for your Kubernetes API server.

What Is RBAC?

RBAC in Kubernetes is all about permissions. It answers:

• Who is making the request? (a user, group, or service account)
• What are they trying to do? (e.g., list pods, delete deployments)
• Where are they trying to do it? (namespace or cluster)

RBAC is made up of four core objects:

Roles: The Namespace Enforcer

A Role is like a door key, but it only works in one hallway (namespace).

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

This allows whoever holds this Role to list and watch pods in the dev namespace. Elsewhere? No access.

ClusterRoles: Permissions for the Big Leagues

ClusterRoles can do everything a Role can—but they also work cluster-wide, and can cover non-namespaced resources like nodes or persistentvolumes.

1apiVersion: rbac.authorization.k8s.io/v1
2kind: ClusterRole
3metadata:
4  name: node-reader
5rules:
6- apiGroups: [""]
7  resources: ["nodes"]
8  verbs: ["get", "list"]

If your Role is a floor pass, a ClusterRole is the building master key.

RoleBinding: Assign the Role

Roles don’t mean anything until they’re bound to someone. Enter the RoleBinding.

 1apiVersion: rbac.authorization.k8s.io/v1
 2kind: RoleBinding
 3metadata:
 4  name: read-pods
 5  namespace: dev
 6subjects:
 7- kind: User
 8  name: alice
 9  apiGroup: rbac.authorization.k8s.io
10roleRef:
11  kind: Role
12  name: pod-reader
13  apiGroup: rbac.authorization.k8s.io

This says: "Hey Kubernetes, let Alice use the pod-reader Role—but only in dev."

You can bind:

• User – for human users
• Group – for teams or groups via identity provider
• ServiceAccount – for workloads inside the cluster

ClusterRoleBinding: Global Permission Giver

If you want to bind a ClusterRole across the whole cluster—whether for users or service accounts—use a ClusterRoleBinding.

 1apiVersion: rbac.authorization.k8s.io/v1
 2kind: ClusterRoleBinding
 3metadata:
 4  name: global-read-nodes
 5subjects:
 6- kind: User
 7  name: bob
 8  apiGroup: rbac.authorization.k8s.io
 9roleRef:
10  kind: ClusterRole
11  name: node-reader
12  apiGroup: rbac.authorization.k8s.io

Now Bob can read nodes in any namespace. Dangerous? Could be. Useful? Also yes.

Common Use Cases

Gotchas and Tips

• RBAC is default-deny: No access unless explicitly granted.
• ClusterRoleBindings ignore namespaces: They're global.
• Don’t bind cluster-admin casually: It's the nuclear option.
• Use Groups: Managing permissions by group is more scalable than binding dozens of users individually.
• Use kubectl auth can-i to debug access issues:

1kubectl auth can-i create deployments --as=alice --namespace=dev

Example: Read-Only Access for Devs

You want devs to view deployments and pods in staging, but not mess things up. Here’s how:

Create a Role:

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

Bind it:

 1kind: RoleBinding
 2apiVersion: rbac.authorization.k8s.io/v1
 3metadata:
 4  name: devs-read
 5  namespace: staging
 6subjects:
 7- kind: Group
 8  name: devs
 9  apiGroup: rbac.authorization.k8s.io
10roleRef:
11  kind: Role
12  name: read-only
13  apiGroup: rbac.authorization.k8s.io

Boom. Devs can now read pods and deployments—but not delete them.

Cleaning Up

When roles change or people leave:

• Delete old RoleBindings and ClusterRoleBindings
• Use kubectl describe clusterrolebinding to audit who’s got what

Wrapping It Up

RBAC gives you fine-grained control over who can do what in your cluster. It’s essential for:

• Security
• Compliance
• Sanity

Remember:

• Use Roles and RoleBindings for namespace-scoped access
• Use ClusterRoles and ClusterRoleBindings for cluster-wide or non-namespaced resources
• Least privilege is your friend

RBAC is your cluster’s bouncer. Use it wisely—and don’t let just anyone into the kube-VIP lounge.