RBAC, ServiceAccounts & Namespaces
Three things this lesson ties together: how you split a cluster into separate zones, how a pod proves its identity to the API server, and how you control exactly what that identity is allowed to do.
Namespaces — virtual clusters inside a cluster
A Namespace partitions one physical cluster into separate logical spaces — commonly one per team or per environment (dev, staging, prod). Names only need to be unique within a namespace, and you can attach a ResourceQuota to cap how much CPU/memory/storage a namespace is allowed to consume in total.
kubectl create namespace staging kubectl get pods -n staging kubectl config set-context --current --namespace=staging
ServiceAccounts — identity for pods, not people
When you run kubectl, you authenticate as a user. When a pod needs to call the Kubernetes API — to list other pods, read a ConfigMap, whatever — it authenticates as a ServiceAccount instead. Every pod gets one automatically (default) unless you specify otherwise.
apiVersion: v1 kind: ServiceAccount metadata: name: report-runner namespace: staging
RBAC — what that identity is actually allowed to do
Role-Based Access Control ties it together: a Role lists allowed actions (verbs like get, list, create, delete) on specific resources, scoped to one namespace. A RoleBinding attaches that Role to a ServiceAccount (or user). Need cluster-wide instead of one namespace? Use ClusterRole / ClusterRoleBinding instead.
# role.yaml — read-only access to pods, in this namespace only apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: pod-reader namespace: staging rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "list", "watch"] # rolebinding.yaml — actually grants it to the ServiceAccount above apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: report-runner-can-read-pods namespace: staging subjects: - kind: ServiceAccount name: report-runner namespace: staging roleRef: kind: Role name: pod-reader apiGroup: rbac.authorization.k8s.io
kubectl auth can-i delete pods --as=system:serviceaccount:staging:report-runner. That single command answers exactly the question RBAC exists to answer — can this identity do this thing?