Stop 08 · Kubernetes & OrchestrationTopics · 8/12

Namespaces & RBAC

In short

When five teams share one cluster, you don't want an intern's script deleting the payments database. Namespaces split the cluster into rooms, and RBAC decides who holds which keys.

Namespaces logically partition a cluster (e.g. by team or environment); Role-Based Access Control governs who can do what within those namespaces — both essential for multi-team cluster safety.

The mascot stands in front of colourful hostel doors holding a ring of matching colour-coded keys.

Think of it like this

The hostel warden's key ring

A hostel has many rooms. Each student gets the key to their own room, the cleaner gets keys to corridors, and only the warden holds the master. Namespaces are the rooms. RBAC is the key ring: exactly who can open which door, and do what inside.

Watch it happen

Riya can read dev, not delete prod

Riya

API server

RBAC

get pods -n dev

1/6Riya runs kubectl. Her request reaches the API server with her identity attached.

The big ideas

What you need to know

Namespaces group things

Split by team or environment. Names only need to be unique inside a namespace, and quotas can cap each one.

Role = what

A Role lists verbs (get, list, delete) on resources (pods, secrets) inside one namespace. ClusterRole works cluster-wide.

RoleBinding = who

A binding attaches a Role to users, groups or service accounts. No binding, no access.

Least privilege

Start with nothing and add only what's needed. Be very careful with access to secrets and cluster-admin.

See it in code

Walk through the code

yaml

1apiVersion: rbac.authorization.k8s.io/v12kind: Role3metadata: { name: pod-reader, namespace: dev }4rules:5  - apiGroups: [""]6    resources: ["pods", "pods/log"]7    verbs: ["get", "list", "watch"]8---9apiVersion: rbac.authorization.k8s.io/v110kind: RoleBinding11metadata: { name: riya-reads-pods, namespace: dev }12subjects:13  - { kind: User, name: riya, apiGroup: rbac.authorization.k8s.io }14roleRef: { kind: Role, name: pod-reader, apiGroup: rbac.authorization.k8s.io }

1/3A Role that only exists in the dev namespace.

Test it without logging in as Riya: kubectl auth can-i list pods -n dev --as riya, then the same for delete pods -n prod.

Save yourself the pain

Common mistakes

Oops

Giving every developer cluster-admin because RBAC errors are annoying.

Do this instead

Read the 403 message: it names the verb and resource. Grant exactly that, in the right namespace.

Oops

Treating namespaces as a security wall on their own.

Do this instead

Namespaces only group objects. Isolation needs RBAC, NetworkPolicies and resource quotas on top.

Your mission

Lock down a namespace

~30 min

Quick check

Riya has a Role allowing everything on pods in dev, but no bindings in prod. What happens when she lists pods in prod?

Go deeper

1Create a namespace and deploy a resource into it, rather than the default namespace.
2Define a basic Role and RoleBinding restricting a user to read-only access in one namespace.
3Learn why namespace isolation alone isn't security — RBAC is what actually enforces access limits.