Namespaces organize workloads and policies. Role-Based Access Control, or RBAC, decides which users, groups and applications may perform specific actions. This guide explains both concepts with practical, production-oriented examples.
What problem do Namespaces solve?
A Kubernetes cluster may host many applications, teams and environments. Without a logical boundary, hundreds of Pods, Services, Secrets and ConfigMaps can become difficult to manage. A Namespace groups namespaced resources so teams can apply access rules, quotas, naming conventions and operational ownership more safely.
Environment separation
Use namespaces such as dev , staging and production .
Team separation
Give application teams access only to the namespaces they own.
Policy boundary
Apply RBAC, ResourceQuota, LimitRange and NetworkPolicy per namespace.
Default Kubernetes Namespaces
Namespace — Purpose
default — Used when no namespace is specified. Avoid placing every production workload here.
kube-system — Contains Kubernetes system components and add-ons.
kube-public — Contains publicly readable cluster information when required.
kube-node-lease — Stores node lease objects used for node heartbeat performance.
Create and use a Namespace
kubectl create namespace dev
kubectl get namespaces
kubectl get all -n dev
kubectl config set-context --current --namespace=dev
The final command changes the default namespace for the current kubectl context. Verify it before running destructive commands:
kubectl config view --minify | grep namespace
Namespace YAML with labels
apiVersion: v1
kind: Namespace
metadata:
name: dev
labels:
environment: development
owner: platform-team
What is Kubernetes RBAC?
RBAC evaluates a request using four basic questions: who is making the request, which action is requested, which resource is targeted and where the resource exists. Permissions are additive: Kubernetes combines all applicable roles. RBAC does not provide an explicit deny rule.
The four primary RBAC objects
Object — Scope — Purpose
Role — One namespace — Defines allowed operations on namespaced resources.
ClusterRole — Cluster-wide definition — Defines permissions for cluster-scoped resources or reusable namespaced permissions.
RoleBinding — One namespace — Grants a Role or ClusterRole to subjects inside a namespace.
ClusterRoleBinding — Entire cluster — Grants a ClusterRole across the whole cluster.
RBAC subjects: users, groups and ServiceAccounts
User: An external human identity authenticated through certificates, OIDC, cloud IAM or another identity provider.
Group: A collection of users supplied by the authentication system.
ServiceAccount: A Kubernetes identity used by Pods, controllers and automation.
Kubernetes stores ServiceAccounts as API objects, but it does not normally manage human user accounts itself.
Practical example: read-only Pod access in dev
1. Create the ServiceAccount
apiVersion: v1
kind: ServiceAccount
metadata:
name: app-reader
namespace: dev
2. Create a namespace-scoped Role
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: pod-reader
namespace: dev
rules:
- apiGroups: [""]
resources: ["pods", "pods/log"]
verbs: ["get", "list", "watch"]
3. Bind the Role to the ServiceAccount
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: app-reader-pod-access
namespace: dev
subjects:
- kind: ServiceAccount
name: app-reader
namespace: dev
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: pod-reader
The roleRef points to the permission definition. The subjects section identifies who receives those permissions.
Understanding apiGroups, resources and verbs
Field — Meaning — Examples
apiGroups — API group containing the resource — "" for Pods and Services; apps for Deployments
Nodes are cluster-scoped resources, so a namespace Role cannot grant node access.
Test permissions before troubleshooting applications
kubectl auth can-i get pods -n dev
kubectl auth can-i delete pods -n dev
kubectl auth can-i list secrets -n dev \
--as=system:serviceaccount:dev:app-reader
kubectl auth can-i --list -n dev \
--as=system:serviceaccount:dev:app-reader
Administrators can also impersonate a user or group while testing:
kubectl auth can-i create deployments -n dev --as=alice
kubectl auth can-i get pods -n production --as=alice --as-group=developers
Common RBAC errors and how to fix them
Symptom — Likely cause — Check
Forbidden — No matching permission — Run kubectl auth can-i for the exact subject, verb, resource and namespace.
RoleBinding exists but access fails — Wrong subject name, namespace or roleRef — Describe the binding and verify all references.
Pod cannot call the API — Wrong ServiceAccount or missing token permission — Check spec.serviceAccountName and the bound role.
User has too much access — Broad ClusterRoleBinding or wildcard rules — Review all bindings and avoid * where possible.
Useful investigation commands
kubectl get roles,rolebindings -n dev
kubectl get clusterroles,clusterrolebindings
kubectl describe role pod-reader -n dev
kubectl describe rolebinding app-reader-pod-access -n dev
kubectl get serviceaccounts -n dev
kubectl get pod APP_POD -n dev -o jsonpath='{.spec.serviceAccountName}'
kubectl api-resources
Namespaces with ResourceQuota
RBAC controls actions, while ResourceQuota controls consumption. They solve different problems and are often used together.
The first permission check should return yes ; the delete check should return no .
Frequently asked questions
No. It organizes resources and provides a scope for policies, but effective isolation also depends on RBAC, network controls, workload security and the surrounding infrastructure.
No. Nodes are cluster-scoped. Use a ClusterRole for node permissions.
Yes. The ClusterRole permissions are then granted only inside the RoleBinding's namespace.
No. Standard RBAC permissions are additive. Avoid granting the unwanted permission in the first place.
Prefer a dedicated ServiceAccount with explicitly defined minimal permissions.
No comments yet. Start the discussion.