Kubernetes RBAC Explained — The Permissions Model Most Teams Get Wrong

If you've ever handed out cluster-admin because a Role "just wasn't working," this tutorial is for you — RBAC isn't broken, it's just not what most people think it is.

Most teams don't learn Kubernetes RBAC on purpose. They learn it the day a Role doesn't work, and the fastest fix is a ClusterRoleBinding to cluster-admin. It works. Nobody goes back to fix it. Six months later, every service account in the cluster can read every secret in every namespace.

This isn't a step-by-step install guide. It's the mental model that actually makes RBAC click — so the next permission problem you hit, you fix it correctly the first time.

What RBAC Actually Controls

RBAC answers one question: can this identity perform this verb on this resource? Nothing more. It doesn't know about your app logic, your network, or your data. It only checks requests against the Kubernetes API server — things like "can this service account list pods in namespace billing?"

Every RBAC rule is really three parts: a subject (who), a verb (what action — get, list, create, delete, watch), and a resource (what object — pods, secrets, deployments). Once you see rules as "subject does verb to resource," the YAML stops looking like magic.

The Four Objects You Need to Know

RBAC in Kubernetes is built from four object types, and almost all confusion comes from mixing up the first pair with the second:

• Role — a set of permissions, scoped to one namespace.
• ClusterRole — the same idea, but scoped to the whole cluster (or reusable across namespaces).
• RoleBinding — grants a Role (or a ClusterRole) to a subject, inside one namespace.
• ClusterRoleBinding — grants a ClusterRole to a subject, across the entire cluster.

A Role or ClusterRole defines permissions. A RoleBinding or ClusterRoleBinding is what actually hands those permissions to someone. Defining a Role and never binding it does nothing — it's a template sitting on a shelf.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: billing
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: billing
subjects:
- kind: ServiceAccount
  name: billing-reader
  namespace: billing
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

This grants exactly one thing: the billing-reader service account can read pod info, and only inside the billing namespace. That's the whole blast radius.

Where Teams Get It Wrong

Three mistakes show up in almost every cluster that's grown past its first few months:

1. Binding a ClusterRole when a Role would do. A ClusterRole can be bound with a plain RoleBinding to stay namespace-scoped — but it's just as easy to reach for a ClusterRoleBinding instead, and that grants the permission everywhere. If an app only ever touches one namespace, it should never hold a cluster-wide grant.

2. Reaching for wildcards. verbs: ["*"] or resources: ["*"] feels like it saves time during setup. In practice it means "this identity can do anything to anything it matches" — including delete. Wildcards are almost never what the app actually needs; they're what fixes the error message fastest.

3. Forgetting the default service account. Every pod that doesn't specify a service account uses default in its namespace. If that namespace's default service account ever picks up a broad binding — even accidentally, through a shared RoleBinding — every pod without an explicit identity inherits it.

A Mental Model That Actually Sticks

Stop thinking of RBAC as "permissions config." Think of it as answering one question per request: subject, verb, resource — then nothing else matters. When something gets denied, don't reach for a broader Role. Ask which of the three parts is missing, and grant exactly that.

The habit that separates teams who trust their RBAC setup from teams who don't: every new ClusterRoleBinding gets a one-line reason written down — why this subject, why this scope. If you can't write that reason, it probably shouldn't be cluster-wide.

Get the Cheat Sheet

We put the four objects, the common verb list, and a "Role vs ClusterRole" decision flow into a single reference sheet. Download the RBAC cheat sheet and keep it next to your terminal for the next time a permission error shows up.

Mumuni Mohammed

Experienced DevOps Engineer proficient in Python, Docker, Kubernetes, CI/CD, and cloud technologies. Specialized in automating processes and building scalable infrastructure for seamless development and deployment.