Namespaces (lesson 2) divide a cluster into separate areas, but by default nothing stops a person or a Pod's own credentials from reading or modifying objects in a namespace they have no real business touching — RBAC is the mechanism that actually enforces that boundary.
3 min read
Lesson 2 was explicit that namespaces are primarily an organizational and
naming boundary, not automatically a security one. Without a separate
access-control layer, anyone with cluster credentials can read or modify
objects in any namespace — team-search's engineers could delete
team-payments' Deployments, not through malice necessarily, but simply
because nothing actually prevented it.
Kubernetes' Role-Based Access Control (RBAC) system is built from three connected pieces:
get, list, create,
delete) are allowed on which resource types.apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: team-payments
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-pods-binding
namespace: team-payments
subjects:
- kind: User
name: alex
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.ioThis grants the user alex read-only access to Pods, and only within the
team-payments namespace — no access to Deployments, Secrets, or any
other resource type, and no access at all outside that one namespace,
directly closing the gap lesson 2 described.
Pods themselves often need permission to call the Kubernetes API — a controller or operator Pod that needs to read or modify other objects. A ServiceAccount is an identity a Pod runs as, and RBAC rules can be bound to a ServiceAccount exactly the same way they're bound to a human user:
spec:
serviceAccountName: log-collector-sa
containers:
- name: fluentd
image: fluentd:v1.16This connects directly to lesson 8's DaemonSet example — a log-collector Pod that needs to read Pod metadata across the cluster would run under a ServiceAccount granted exactly that permission, and nothing broader, via the same Role/RoleBinding mechanism.
RBAC's actual value comes from granting the narrowest permissions that let something do its job — a ServiceAccount that only ever needs to read ConfigMaps (lesson 3) should never be granted permission to delete Deployments, even if it would be more convenient to grant broad access once and never think about it again. A compromised or buggy Pod running under an overly-broad ServiceAccount can do proportionally more damage, which is exactly why real production clusters take RBAC scoping seriously rather than defaulting every ServiceAccount to broad, convenient access.
A Role only grants permissions within one specific namespace; a ClusterRole can grant permissions across the entire cluster (or for cluster-scoped resources like Nodes, which don't belong to any namespace at all). Reaching for a ClusterRole by default, when a namespace-scoped Role would do, is a common way least-privilege intentions get undermined in practice — it's more convenient in the moment and quietly grants far more access than the task actually needs.
Check your understanding
A quick comprehension check — not tracked, not graded, just for you.
1. What are the three connected building blocks of Kubernetes RBAC?
2. What is a ServiceAccount, and why does RBAC apply to it the same way it applies to human users?
3. Why is granting a ClusterRole when a namespace-scoped Role would suffice a common way least-privilege intentions get undermined?
Kubernetes