CloudOpsGuide
kubernetes

Kubernetes RBAC Explained: Roles, Bindings, and Least Privilege

Advanced
10 minutes
October 2026
CloudOpsGuide Team

Kubernetes RBAC Explained: Roles, Bindings, and Least Privilege

RBAC is the question every cluster eventually asks: "who is allowed to do what?" Get it wrong in one direction and nothing works; wrong in the other and a compromised pod can read every Secret in the cluster.

Table of Contents

The four objects

  • Role — a set of permissions within one namespace.
  • ClusterRole — permissions cluster-wide (or reusable across namespaces).
  • RoleBinding — grants a Role (or ClusterRole) to subjects in a namespace.
  • ClusterRoleBinding — grants a ClusterRole across the whole cluster.

Subjects are ServiceAccounts (workloads), Users, and Groups (humans). Verbs are get list watch create update patch delete; resources are the API objects — pods, secrets, deployments.

The minimum-viable example

An app that needs to read its own ConfigMaps:

apiVersion: v1
kind: ServiceAccount
metadata: { name: myapp, namespace: prod }
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata: { name: config-reader, namespace: prod }
rules:
  - apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata: { name: myapp-read-config, namespace: prod }
subjects:
  - kind: ServiceAccount
    name: myapp
roleRef:
  kind: Role
  name: config-reader
  apiGroup: rbac.authorization.k8s.io

# pod uses it:
spec:
  serviceAccountName: myapp

The debugging commands that save hours

kubectl auth can-i create deployments -n prod          # me?
kubectl auth can-i list secrets \
  --as=system:serviceaccount:prod:myapp -n prod        # as the SA
kubectl auth can-i '*' '*' --as=system:serviceaccount:prod:myapp
kubectl describe rolebinding -n prod
kubectl get clusterrolebinding | grep cluster-admin  # who has god mode

auth can-i --as is the tool — it answers "will this identity be allowed?" without a broken deploy to find out.

Rules that keep you safe

  • Never default to cluster-admin. It exists for bootstrap; real workloads get the smallest Role that works.
  • Scope to namespaces. Role + RoleBinding beats ClusterRole + ClusterRoleBinding whenever the permissions allow it.
  • Prefer Role→ClusterRole reference. A RoleBinding can reference a ClusterRole, scoping its (reusable) permissions to one namespace — the pattern for shared permission sets.
  • Guard secrets verbs aggressively. list/get on secrets in a namespace often equals total compromise of that namespace.
  • Automount off by default. Pods get a ServiceAccount token mounted automatically; set automountServiceAccountToken: false unless the workload calls the API.
  • Wildcard * is a code smell — fine in an emergency, debt in production.

Reading an existing mess

kubectl get roles,rolebindings -A | grep prod
kubectl get clusterroles | less          # the built-ins
kubectl describe clusterrole admin       # what "admin" actually does

Kubernetes ships admin, edit, and view ClusterRoles covering the common cases — bind view for read-only dashboards and auditors before writing custom roles.

RBAC is least-privilege made declarative: start from zero, grant exactly what the workload proves it needs, and auth can-i everything before it ships.

Related Articles

Last Updated: October 2026 Author: CloudOpsGuide Team Difficulty: Advanced Estimated Reading Time: 10 minutes