Skip to main content
Role-based access control (RBAC) is the most fundamental security layer in Kubernetes. This guide makes RBAC practical: you’ll learn the four RBAC resources, how to author Roles, how to bind them to users and ServiceAccounts, and how to debug permissions with kubectl auth can-i. Why RBAC matters — a real cost of skipping least privilege A SaaS company avoided delays by giving all forty developers cluster-admin. A junior developer ran:
but their kubeconfig pointed at production. The production namespace was deleted: thirty-two Deployments, fifteen Services, eight StatefulSets, and all PVCs. Because the PVC reclaim policy was Delete, that data was permanently lost. The outage lasted six hours and cost the company significant revenue and recovery expenses. The root cause: everyone had broad cluster-admin rights, so there was no separation of environments and no restriction on destructive actions.
A slide titled "The cluster-admin Anti-Pattern" showing three colored arrows pointing down with reasons why it happened: "Everyone had cluster-admin," "No restriction on destructive actions," and "No separation between environments." The slide is © KodeKloud.
That entire class of incidents is prevented by well-applied RBAC. Below is a concise reference and practical examples. What are the four RBAC resources? Kubernetes RBAC has exactly four objects. Two define permissions (the “what”) and two assign those permissions to identities (the “who”):
  • Role — namespace-scoped permissions.
  • ClusterRole — cluster-scoped permissions or permissions for non-namespaced resources (nodes, CRDs).
  • RoleBinding — grants a Role or ClusterRole within a single namespace.
  • ClusterRoleBinding — grants a ClusterRole across all namespaces.
Start with namespace-scoped Roles and RoleBindings. Only escalate to cluster-scoped permissions when there is a documented, repeatable need.
An infographic titled "The Four RBAC Resources" that summarizes Kubernetes RBAC objects: Role (namespace-scoped) and ClusterRole (cluster-wide) under "WHAT (Permissions)", and RoleBinding (namespace) and ClusterRoleBinding (cluster-wide) under "WHO (Binding)". Each box briefly explains the scope and purpose of the resource.
Quick reference table How to write a Role (example) Create a namespace-scoped Role that grants read-only access to pods in the payments namespace:
Rule fields explained
  • apiGroups: an empty string ("") is the core API group (pods, services, secrets). Other groups include apps (Deployments, StatefulSets) and batch (Jobs).
  • resources: the resource types this rule applies to (e.g., pods, secrets, deployments).
  • verbs: allowed actions. Common sets:
    • Read-only: get, list, watch
    • Read-write: add create, update, patch
    • Delete: include delete
    • Wildcard: "*" — avoid unless absolutely necessary
  • resourceNames: narrow scope to specific named resources for very precise access control.
A Role by itself does nothing — you must bind it. RoleBinding examples RoleBindings connect subjects (the who) with Roles or ClusterRoles (the what). Two common examples:
  • RoleBinding for a single user in the payments namespace:
  • RoleBinding that grants the reusable edit ClusterRole to a CI/CD ServiceAccount (bound per-namespace):
Subject kinds you’ll use
  • User — human identities provisioned by your identity provider.
  • Group — collections of users from your IdP (useful for role assignment at scale).
  • ServiceAccount — identities used by Pods inside the cluster.
When to choose Role vs. ClusterRole (decision guide)
  • Developer viewing pods in their own namespace: use Role + RoleBinding.
  • CI/CD deploying to multiple namespaces: create a reusable ClusterRole, and bind it per-namespace with RoleBinding.
  • Monitoring or tools that require read access across namespaces: ClusterRole + ClusterRoleBinding.
  • Platform teams that manage nodes, CRDs, or cluster-level resources: ClusterRole + ClusterRoleBinding.
  • cluster-admin should be reserved for emergency or break-glass scenarios only — not day-to-day use.
A presentation slide titled "Namespace vs Cluster Scope: The Key Decision" showing a table that maps example scenarios (e.g., dev viewing pods, CI/CD deploying, monitoring, admin tasks) to Kubernetes role types and binding types. The slide includes entries like Role/RoleBinding for namespace access and ClusterRole/ClusterRoleBinding for cluster-wide access.
Debugging RBAC with kubectl auth can-i kubectl auth can-i is the primary tool for testing and troubleshooting RBAC permissions. Basic examples:
Tips for using can-i effectively
  • Single-action checks return a simple yes or no.
  • Use --as=<user> or --as=system:serviceaccount:<ns>:<name> to impersonate an identity.
  • Use --list to enumerate all allowed actions for the impersonated identity in a namespace.
  • Apply your Role and RoleBinding manifests, then confirm behavior with kubectl auth can-i before granting wider access.
Avoid granting broad cluster-scoped rights to large groups. The cluster-admin anti-pattern leads to accidental deletions and data loss — follow least-privilege principles.
Summary — practical checklist
  • Know the four RBAC objects: Role, ClusterRole, RoleBinding, ClusterRoleBinding.
  • Start with namespace-scoped Role + RoleBinding. Escalate only when necessary.
  • Build Roles from apiGroups, resources, and verbs. Use resourceNames for precise limits.
  • Bind Roles to User, Group, or ServiceAccount.
  • Validate and debug with kubectl auth can-i.
Links and references

Watch Video