RBAC & ServiceAccounts

Every pod runs as someone. Not a human someone — a ServiceAccount, the identity a pod presents whenever it talks to the Kubernetes API itself. If you've never set one, your pods use the default ServiceAccount of their namespace, which (sensibly) can do almost nothing.

The permission chain

RBAC (Role-Based Access Control) decides what a given identity can do, through three objects chained together:

• Role (or ClusterRole) — a list of permissions: which verbs (get, list, watch, create, delete, ...) are allowed on which resources (pods, deployments, secrets, ...), optionally scoped to specific resource names. A Role is namespaced; a ClusterRole applies cluster-wide or can be reused across namespaces.
• RoleBinding (or ClusterRoleBinding) — grants a Role to a subject: a User, a Group, or — the one that matters here — a ServiceAccount.
• ServiceAccount — the identity itself, attached to a pod via spec.serviceAccountName. Kubernetes mounts its token into the pod automatically, which is how the pod authenticates.

Nothing is granted by default beyond this chain. No Role, no RoleBinding, no permission — full stop. This is "default deny": the safest possible starting position, but it means a pod that needs to talk to the API (an operator, a controller, a CI job calling kubectl from inside the cluster) needs this chain deliberately wired up, every time.

Reading a Forbidden error

When the chain is missing or incomplete, the API server's rejection is unusually specific — it names the exact subject, verb, resource, and scope it refused:

Error from server (Forbidden): pods is forbidden: User
"system:serviceaccount:my-ns:report-reader" cannot list resource "pods"
in API group "" in the namespace "my-ns"

That single line is almost always enough to write the fix: a Role granting list on pods, bound to report-reader via a RoleBinding, in my-ns. The fastest way to test a fix before touching a real pod is kubectl auth can-i <verb> <resource> --as=system:serviceaccount:<ns>:<name> -n <ns> — it asks the API server to evaluate the same decision without needing a running pod at all.

The infrastructure analogy

This is IAM, reshaped for an API instead of a cloud console: a Role is a policy document, a RoleBinding is a policy attachment, a ServiceAccount is closest to an instance role — an identity your compute assumes, not a human's credentials. If you've attached an IAM role to an EC2 instance or an IRSA role to an EKS pod (more on that in Module 15), this chain will feel immediately familiar — right down to "default deny" being the only sane starting position.

In the lab, you'll hit exactly the Forbidden error above, from inside a real pod using its own mounted identity, and fix it the same way you would in production.