Skip to content

RBAC in Kubernetes

First PublishedByAtif Alam

RBAC (Role-Based Access Control) authorizes who can do what after authentication establishes identity. Effective access is always authn + authz + bindings.

ObjectScopeBinds to
RoleOne namespacePermissions inside that namespace
ClusterRoleWhole clusterCluster-wide or namespaced resources (depending on rules)
RoleBindingOne namespaceUsers/groups/SAs → Role or ClusterRole (in that namespace)
ClusterRoleBindingWhole clusterUsers/groups/SAs → ClusterRole

A RoleBinding to a ClusterRole is a common pattern: reuse a cluster-defined role template but limit its effect to one namespace.

  • Namespace RoleBinding to a privileged ClusterRole still affects only that namespace — bad, but bounded.
  • ClusterRoleBinding to cluster-admin (or equivalent) is cluster-wide — treat as break-glass; automate detection and quarterly review.

With OIDC, the API server maps claims (for example groups) to Kubernetes groups; RBAC bindings reference those group names.

Typical flow:

  1. Configure API server --oidc-* flags (or use your cloud’s managed integration).
  2. Map groups claim → Kubernetes groups in the identity.
  3. Bind ClusterRole view or custom roles to group:platform-readers.

Worked kubeconfig patterns (including aws eks get-token) live on Kubeconfig and authentication.

Terminal window
kubectl auth can-i create deployments --namespace team-a
kubectl auth can-i '*' '*' --all-namespaces # cluster-admin check — use sparingly

Use --as and --as-group to simulate another principal when debugging RBAC tickets.

  • Granting verbs: ['*'] on resources: ['*'] for convenience.
  • Using ClusterRoleBinding where RoleBinding would suffice.
  • Wildcard resourceNames omissions on Secrets — narrow where possible.

Log who changed RoleBinding and ClusterRoleBinding objects; alert on cluster-admin grants. Pair with Multi-tenancy and policy for audit shipping patterns.