Kubernetes RBAC Builder

RBAC (Role-Based Access Control) in Kubernetes controls what actions subjects (users, groups, service accounts) can perform on resources. It works through four objects: Role (namespaced permissions), ClusterRole (cluster-wide), RoleBinding (grants a Role to a subject in a namespace), and ClusterRoleBinding (grants a ClusterRole cluster-wide).

Use Role when permissions should be scoped to a single namespace (most application workloads). Use ClusterRole for cross-namespace access, cluster-level resources (nodes, PersistentVolumes, namespaces), or when you need to reuse the same permission set in multiple namespaces via multiple RoleBindings.

RoleBinding grants permissions within a specific namespace. ClusterRoleBinding grants permissions cluster-wide. You can use a RoleBinding with a ClusterRole — this lets you define permissions once in a ClusterRole and reuse them in specific namespaces. ClusterRoleBindings should be used sparingly as they grant broad access.

1. Binding cluster-admin to application service accounts. 2. Using wildcard verbs (*) or resources (*) without necessity. 3. Granting create/delete on pods directly — prefer Deployments with limited scope. 4. Forgetting that secrets access grants full secret contents. 5. Not auditing RBAC regularly with 'kubectl auth can-i'.

Use kubectl auth can-i: 'kubectl auth can-i list pods --namespace=default --as=system:serviceaccount:default:my-sa'. The --as flag impersonates a user or service account. For comprehensive RBAC auditing, tools like rbac-lookup, kubectl-who-can, and Polaris can show all effective permissions.