Kubernetes RBAC: Lock Down Your Cluster with Role-Based Access Control

Most Kubernetes clusters start the same way: you create the cluster, add yourself as cluster-admin, and everyone who needs to touch it gets admin too. Then a developer with cluster-admin runs kubectl delete ns production by accident, or a CI token with full permissions leaks, and suddenly your whole cluster is someone else's sandbox.

RBAC (Role-Based Access Control) is how Kubernetes answers the question "who can do what, where?" It's the difference between "everyone can do everything everywhere" and "developers deploy to their namespace, SREs manage the cluster, CI robots only touch their own pipeline." This guide covers the four core objects, real YAML you can copy, and the mistakes that show up in almost every security audit.

1. The Four Core Objects

RBAC has exactly four resource types. Understand these and everything else is composition:

Role — a set of permissions inside one namespace. Scoped to a namespace.
ClusterRole — a set of permissions cluster-wide (or reusable across namespaces). Not scoped.
RoleBinding — grants a Role to users, groups, or service accounts within a namespace.
ClusterRoleBinding — grants a Role/ClusterRole cluster-wide.

The relationship is simple: a Role defines permissions, a Binding attaches them to a subject. A RoleBinding can even reference a ClusterRole — that's the standard pattern for sharing read-only access across namespaces without duplicating rules.

2. A Role, Not a RoleModel: Your First Namespaced Role

Say you want to give the backend team full control over deployments, pods, and services in the staging namespace — but nothing else:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: staging
  name: backend-deployer
rules:
- apiGroups: [""]
  resources: ["pods", "services", "configmaps", "secrets"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
  resources: ["deployments", "statefulsets", "replicasets"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

Notice the details that matter:

apiGroups: core resources (pods, services) live in "", workload resources live in "apps".
verbs: read-only get/list/watch for pods and secrets — the team can see secrets but not edit them.
scope: namespace: staging means this role is powerless anywhere else.

3. Binding It: RoleBinding

A Role with no binding grants nothing. Attach it to the team:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: staging
  name: backend-deployer-binding
subjects:
- kind: Group
  name: backend-team
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: backend-deployer
  apiGroup: rbac.authorization.k8s.io

Bind to groups, not individual users. When someone joins or leaves the team, your OIDC/SSO provider updates the group membership and your cluster config doesn't change. Binding to individual usernames means editing RBAC YAML for every hire and firing — a maintenance trap.

4. ClusterRoles: When You Need Cluster-Wide Access

ClusterRoles exist for two cases: permissions that span namespaces (like reading nodes, or managing a CRD), and permissions you want to reuse namespace-by-namespace via RoleBindings.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: namespace-viewer
rules:
- apiGroups: [""]
  resources: ["namespaces", "nodes", "persistentvolumes"]
  verbs: ["get", "list", "watch"]

Then give a developer read-only access to every namespace without one Role per namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: sre-viewer
subjects:
- kind: User
  name: sre-alice
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: namespace-viewer
  apiGroup: rbac.authorization.k8s.io

The built-in view, edit, admin, and cluster-admin ClusterRoles cover most day-one needs. view is read-only across a namespace, edit adds create/update/delete, admin adds role management, and cluster-admin can do literally anything. Start from view and add only what the job requires.

5. Service Accounts: The CI/CD Pattern

Pipelines shouldn't use your personal kubeconfig. Create a dedicated service account and bind it to the minimum it needs:

kubectl create serviceaccount ci-deployer -n staging
kubectl create rolebinding ci-deployer-binding \
  --clusterrole=edit \
  --serviceaccount=staging:ci-deployer \
  -n staging

Now your CI job authenticates with the ci-deployer token and can edit resources in staging — but cannot touch production, cannot delete namespaces, and cannot grant anyone else permissions. If that token leaks, the blast radius is one namespace.

6. Verify Before You Trust: kubectl auth can-i

Never guess whether a subject has access. Ask the API server:

# Can the current user delete pods in staging?
kubectl auth can-i delete pods -n staging

# Can the ci-deployer SA list secrets in production?
kubectl auth can-i list secrets -n production \
  --as=system:serviceaccount:staging:ci-deployer

# What can the current user do across the cluster?
kubectl auth can-i --list -n staging

Run these checks after every binding change. They're instant, they test the real authorization chain, and they catch typos like a missing apiGroup that silently scopes your rule to the wrong resource group.

7. Mistakes That Get Clusters Hacked

After auditing real clusters, the same five issues show up again and again:

Everyone is cluster-admin. If more than a handful of humans have cluster-admin, your cluster is one leaked kubeconfig away from being deleted. Audit with kubectl get clusterrolebindings and prune.
Wildcard verbs. verbs: ["*"] on a role is a code smell. It grants future verbs you don't even know exist yet.
Secrets readable by everyone. A read-only view role can still read all secrets in a namespace. If your deployment pipeline stores real credentials in plain Secrets (it shouldn't — use Sealed Secrets or External Secrets), limit who can read them.
Binding users instead of groups. Individual user bindings don't scale and rot silently.
Ignoring the default deny. RBAC is deny-by-default. If something doesn't work after adding a role, check kubectl auth can-i before assuming the role is broken — usually the subject isn't actually bound.

Least privilege isn't a compliance checkbox. In Kubernetes, RBAC is the difference between a leaked token being an incident and a leaked token being a catastrophe.

Summary

RBAC is four objects and one principle. Roles and ClusterRoles define permissions; RoleBindings and ClusterRoleBindings grant them. Bind to groups, scope to namespaces, prefer view over edit over admin, give CI its own service accounts, and verify everything with kubectl auth can-i. Do that and the next security audit won't have a single finding about your cluster's access control.