Kubernetes RBAC Cheat Sheet
Configuring Role-Based Access Control with Roles, ClusterRoles, and bindings to control who can do what in a cluster.
2 PagesAdvancedFeb 5, 2026
RBAC Objects
The four objects that make up Kubernetes RBAC.
- Role- Namespaced set of permissions (verbs on resources)
- ClusterRole- Cluster-scoped permissions, can also be used for namespaced resources across all namespaces
- RoleBinding- Grants a Role (or ClusterRole) to a subject within a specific namespace
- ClusterRoleBinding- Grants a ClusterRole to a subject across the entire cluster
Role - Read-only Pods
Grant get/list/watch on pods within a namespace.
yaml
apiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata: namespace: staging name: pod-readerrules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "list", "watch"]
RoleBinding
Bind the pod-reader Role to a specific user.
yaml
apiVersion: rbac.authorization.k8s.io/v1kind: RoleBindingmetadata: name: read-pods namespace: stagingsubjects: - kind: User name: [email protected] apiGroup: rbac.authorization.k8s.ioroleRef: kind: Role name: pod-reader apiGroup: rbac.authorization.k8s.io
ServiceAccount + ClusterRoleBinding
Grant a workload's ServiceAccount permissions across the cluster.
yaml
apiVersion: v1kind: ServiceAccountmetadata: name: ci-deployer namespace: ci---apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata: name: ci-deployer-bindingsubjects: - kind: ServiceAccount name: ci-deployer namespace: ciroleRef: kind: ClusterRole name: edit apiGroup: rbac.authorization.k8s.io
Debugging Permissions
Check what a user or service account is allowed to do.
bash
# Can I delete pods in the default namespace?kubectl auth can-i delete pods --namespace default# Check as a specific service accountkubectl auth can-i list secrets \ --as=system:serviceaccount:ci:ci-deployer -n ci# List all Roles/ClusterRoles bound to a subjectkubectl get rolebindings,clusterrolebindings -A -o wide
Aggregated ClusterRoles
Compose a ClusterRole automatically from labeled fragments, so plugins/operators can extend built-in roles like `edit` or `view`.
yaml
apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata: name: crd-controller-aggregate labels: rbac.authorization.k8s.io/aggregate-to-edit: "true"rules: - apiGroups: ["batch.example.com"] resources: ["jobs"] verbs: ["get", "list", "watch", "create", "update", "delete"]# Any rule set labeled aggregate-to-edit is automatically merged into the# built-in "edit" ClusterRole's aggregationRule at reconcile time - no need# to edit the built-in role or track a growing rules list by hand.
Scoping to resourceNames and non-resource URLs
Restrict a Role to specific named objects, and grant access to API server endpoints that aren't resources at all.
yaml
apiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata: namespace: staging name: configmap-editor-scopedrules: - apiGroups: [""] resources: ["configmaps"] resourceNames: ["app-config", "feature-flags"] verbs: ["get", "update", "patch"]---# ClusterRole granting access to a non-resource URL (only valid in ClusterRole)apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata: name: metrics-readerrules: - nonResourceURLs: ["/metrics", "/healthz"] verbs: ["get"]
escalate, bind & impersonate Verbs
The special verbs that control whether a subject can grant permissions it doesn't itself hold.
yaml
# Without 'escalate', a subject cannot create/edit a Role/ClusterRole that# contains permissions it doesn't already have - this is the default,# API-server-enforced guardrail against privilege escalation via RBAC edits.apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata: name: role-admin-scopedrules: - apiGroups: ["rbac.authorization.k8s.io"] resources: ["roles", "rolebindings"] verbs: ["get", "list", "create", "update", "bind"] # 'bind' lets this subject bind ONLY roles it already possesses, # even without 'escalate'---# Impersonation lets a controller/CI identity act 'as' another subjectapiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata: name: impersonatorrules: - apiGroups: [""] resources: ["users", "groups", "serviceaccounts"] verbs: ["impersonate"]
kubectl RBAC Authoring & Audit Shortcuts
Generate Role/RoleBinding manifests imperatively and audit who has access to what.
bash
# Generate a Role without applying it, then pipe to a filekubectl create role deploy-manager \ --verb=get,list,watch,update \ --resource=deployments,deployments/scale \ -n staging --dry-run=client -o yaml > role.yamlkubectl create rolebinding deploy-manager-binding \ --role=deploy-manager \ --serviceaccount=staging:ci-deployer \ -n staging --dry-run=client -o yaml > rolebinding.yaml# Full audit: who can do what across the whole cluster (requires plugin)kubectl krew install access-matrixkubectl access-matrix --namespace staging# List every ClusterRoleBinding subject bound to cluster-adminkubectl get clusterrolebindings -o json | \ jq -r '.items[] | select(.roleRef.name=="cluster-admin") | .subjects[]?.name'
RBAC Advanced Concepts
Terminology that matters once you go beyond basic Role/RoleBinding pairs.
- Default ClusterRoles- `cluster-admin`, `admin`, `edit`, `view` ship built-in; prefer binding these over hand-rolled roles when they fit
- Aggregation rule- `aggregationRule.clusterRoleSelectors` on a ClusterRole auto-merges in any ClusterRole matching the label selector
- RoleBinding to a ClusterRole- Grants the ClusterRole's permissions but scoped ONLY to the RoleBinding's namespace - a common way to reuse `edit`/`view` per-namespace
- Privilege escalation prevention- The API server rejects a create/update of a Role granting permissions the requester doesn't already hold, unless it also has `escalate`
- Subject types- User, Group, and ServiceAccount - Users/Groups come from your auth provider (OIDC, client certs), not native Kubernetes objects
- system: prefixed groups- `system:authenticated`, `system:unauthenticated`, `system:masters` are implicit groups every request is evaluated against
Pro Tip
Avoid binding the built-in `cluster-admin` ClusterRole to service accounts — grant the narrowest built-in role that fits (`view`, `edit`) or author a custom Role scoped to the exact verbs and resources the workload needs.
Was this cheat sheet helpful?
Explore Topics
#KubernetesRBAC#KubernetesRBACCheatSheet#DevOps#Advanced#RBACObjects#Role#Read#Only#Kubernetes#CheatSheet#SkillVeris
