Kubernetes Namespace Scoped Access

Kubernetes Namespace Scoped Access is the pattern of confining a subject's granted permissions to a single namespace, using namespaced Role objects and RoleBindings (or namespace-bound RoleBindings referencing a ClusterRole) so that a user, group, or service account can act freely within its own namespace while having no visibility or effect on any other. It is the primary mechanism by which Kubernetes clusters support multi-tenancy at the API level, isolating teams, applications, and environments that share the same physical cluster.

How Namespace Scoping Works

Roles Are Inherently Namespace-Bound

A Role object exists within, and only applies within, a single namespace — there is no way to define a Role that spans namespaces, which makes it the natural building block for namespace-scoped access. A RoleBinding created in a namespace can only bind subjects to permissions that take effect in that same namespace, regardless of which object type (Role or ClusterRole) it references.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: team-access
  namespace: team-a
subjects:
- kind: Group
  name: team-a-developers
roleRef:
  kind: ClusterRole
  name: edit
  apiGroup: rbac.authorization.k8s.io

Reusing ClusterRoles Within a Namespace Boundary

Binding a ClusterRole such as the built-in edit or admin role through a RoleBinding rather than a ClusterRoleBinding confines its effect to the single namespace of the binding, which is how a common, well-tested permission set can be applied consistently to many teams without granting any of them access beyond their own namespace.

Designing Multi-Tenant Namespace Boundaries

One Namespace per Team or Application

A common tenancy model dedicates one or more namespaces per team, with each team's identity group bound only within its own namespaces, so that a compromised or misused credential from one team cannot read or modify resources belonging to another team sharing the same cluster.

Combining with Resource Quotas and Network Policy

Namespace-scoped RBAC access controls what API operations a subject can perform, but does not by itself limit resource consumption or network reachability; pairing it with ResourceQuota and NetworkPolicy objects scoped to the same namespace produces isolation across API access, compute consumption, and network traffic simultaneously.

Verifying Namespace Isolation

Confirming No Unintended Cross-Namespace Access

kubectl auth can-i accepts a --namespace flag, and testing a subject against every namespace they should not have access to — not only the one they should — is the more rigorous verification, since a missing --namespace flag defaults to the current context and can produce a false sense of confidence about isolation.

kubectl auth can-i get secrets --namespace team-b --as system:serviceaccount:team-a:worker

Watching for ClusterRoleBindings That Undermine Isolation

A ClusterRoleBinding granting even a modest permission set to a broad group like system:authenticated applies across every namespace, silently overriding any careful namespace-scoped design; auditing ClusterRoleBinding objects alongside namespace-level RoleBindings is necessary to confirm isolation actually holds in practice.

Limits of Namespace-Scoped RBAC

Cluster-Scoped Resources Fall Outside Namespace Boundaries

Resources such as Node, PersistentVolume, CustomResourceDefinition, and Namespace itself are cluster-scoped and cannot be governed by a namespaced Role; any access to them necessarily requires a ClusterRole, and by extension crosses whatever namespace boundary the rest of the tenancy model relies on.

Namespace Access Does Not Imply Namespace Ownership

A subject with broad edit access within a namespace can typically still read that namespace's Secret objects and modify its NetworkPolicy objects unless those are explicitly excluded, meaning namespace-scoped access alone does not guarantee separation between, for example, application developers and the platform team responsible for that namespace's security posture — finer-grained custom Roles are needed for that level of separation.

Namespaces Are Not a Hard Security Boundary Without Additional Controls

Namespace-scoped RBAC restricts API-level access but does not, on its own, prevent workloads in different namespaces from communicating over the pod network, sharing a node's kernel, or being scheduled with overlapping resource contention; genuine tenant isolation in a shared cluster requires namespace-scoped RBAC as one layer among several, not as the sole isolation mechanism.