0 / 15 lessons — 0%
Lesson 13 / 15

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
Default deny, not default allow. A ServiceAccount with no RoleBinding can do almost nothing through the API. That's the correct default — grant only the specific verbs on the specific resources a workload actually needs.
Try it yourselfRun 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?