Skip to main content
Everything on your platform starts with one question: who is allowed to do what and where? Role-Based Access Control (RBAC) is a core Kubernetes security model that answers that question. Roles define permissions (verbs on resources) and bindings attach those permissions to identities (users, groups, or service accounts). Misconfigured RBAC either locks teams out or leaves the cluster exposed — so use least privilege and verify changes.
RBAC follows the principle of least privilege: grant only the permissions that an identity needs. If a permission isn’t explicitly granted, it’s denied.
This guide walks through:
  • Inspecting namespaces and service accounts
  • Creating a namespaced Role and RoleBinding
  • Creating a ClusterRole and ClusterRoleBinding
  • Binding roles to service accounts
  • Verifying permissions with impersonation and best practices

​
Inspect namespaces and service accounts

List namespaces and then list service accounts in each team namespace:
Example output:

​
Namespaced Role: developer

Create a Role scoped to the team-alpha namespace that grants CRUD-like permissions on core resources and the apps group.
Apply the Role:
You should see:

​
Bind the Role to a user (RoleBinding)

Bind the developer Role to the user alice in team-alpha:
Expected output:

​
Verify Alice’s permissions (impersonation)

Use kubectl auth can-i with --as to impersonate alice and validate permissions:
Expected output:
Because the RoleBinding is namespaced to team-alpha, Alice can create pods there but not in team-beta. This enforces least privilege by design.
When granting or revoking RBAC permissions, exercise caution. Impersonation (using --as) helps validate changes before committing them.

​
ClusterRole: viewer

For cluster-wide view-only access, use a ClusterRole (not namespaced). The viewer ClusterRole below grants get, list, and watch on selected core and apps resources across the cluster.
Apply the ClusterRole and create a ClusterRoleBinding for user bob:
Expected output:
Verify Bob’s permissions with impersonation:
Expected output:
Bob has read-only access across the cluster but cannot create or modify resources.

​
Binding a Role to a ServiceAccount

Service accounts are identities used by in-cluster workloads (CI/CD pipelines, controllers, automation). You bind Roles the same way you bind users. Create a RoleBinding to give the team-alpha:deploy-bot service account the developer role:
Expected output:
Verify the service account can create deployments in team-alpha by impersonating its system name:
Expected output:
Now check the readonly-sa in team-beta, which has no bindings — it should not be able to get pods:
Expected output:
By default, Kubernetes RBAC denies permissions that are not explicitly granted.

​
Role vs ClusterRole and Bindings — quick reference

​
Debugging and best practices

  • Validate permissions with kubectl auth can-i and --as to impersonate users or service accounts.
  • Prefer namespaced Roles and RoleBindings whenever possible; use ClusterRoles sparingly.
  • Follow least privilege: grant only the verbs/resources required and scope them to the appropriate namespace.
  • Test RBAC changes in a staging or non-production cluster before rolling them out to production.
  • Keep Role and ClusterRole manifests in version control and review changes (code review/PR) before applying.
Practice creating Roles, RoleBindings, ClusterRoles, and ClusterRoleBindings in a safe environment to build confidence and enforce secure access patterns.

Watch Video

Practice Lab