How to grant Kubernetes namespace access with RBAC

Kubernetes RBAC is the layer that decides which authenticated users, groups, and ServiceAccounts can act on API resources. Namespace access belongs there when a team member or automation account needs a limited set of verbs in one namespace without receiving cluster-wide permissions.

A Role stores permissions inside one namespace, and a RoleBinding attaches those permissions to a subject. The RoleBinding namespace is the boundary, so the same user can list Pods in team-a while remaining unable to read secrets or list Pods elsewhere.

For a minimal namespace grant, a pod-reader Role can allow only get, list, and watch on Pods. Impersonated kubectl auth can-i checks confirm both the allowed action and the actions that should stay denied.

1. Create the target namespace.

   $ kubectl create namespace team-a
   namespace/team-a created

   Skip this step for an existing namespace. Use the namespace that should receive the access grant.
   Related: How to create a Kubernetes namespace

2. Check the subject's current access in the namespace.

   $ kubectl auth can-i list pods --namespace team-a --as=alice@example.com
   no

   --as asks the API server to evaluate the request as another user. Run the check from an administrator identity that is allowed to impersonate users, or run the same check from the target user's own kubeconfig.

3. Create a namespace-scoped Role for the allowed Pod actions.

   $ kubectl create role pod-reader --namespace team-a --verb=get --verb=list --verb=watch --resource=pods
   role.rbac.authorization.k8s.io/pod-reader created

   Use the smallest verb and resource set the subject needs. Add more verbs or resources only when the namespace job requires them.

4. Bind the Role to the user.

   $ kubectl create rolebinding alice-pod-reader --namespace team-a --role=pod-reader --user=alice@example.com
   rolebinding.rbac.authorization.k8s.io/alice-pod-reader created

   Use --group for an identity-provider group, or --serviceaccount=team-a:ci-runner when the permission belongs to an in-cluster ServiceAccount.

5. Inspect the saved RoleBinding subject and role reference.

   $ kubectl describe rolebinding alice-pod-reader --namespace team-a
   Name:         alice-pod-reader
   Labels:       <none>
   Annotations:  <none>
   Role:
     Kind:  Role
     Name:  pod-reader
   Subjects:
     Kind  Name               Namespace
     ----  ----               ---------
     User  alice@example.com

6. Confirm the granted action now succeeds as the subject.

   $ kubectl auth can-i list pods --namespace team-a --as=alice@example.com
   yes

7. Confirm a sensitive unrelated action remains denied.

   $ kubectl auth can-i get secrets --namespace team-a --as=alice@example.com
   no

   If this returns yes, another RoleBinding or ClusterRoleBinding already grants secret access. Review the existing RBAC objects before treating the new grant as least privilege.

8. Confirm the same Pod action remains denied in another namespace.

   $ kubectl auth can-i list pods --namespace default --as=alice@example.com
   no

   A RoleBinding grants access only in its own namespace. Use a ClusterRoleBinding only when cluster-wide access is intended.