Fix a Forbidden Error with a Role and RoleBinding

Original Prepium guide · Written for Kubernetes v1.35 and checked against the official documentation on 6 October 2026. Use a disposable practice cluster. You need an admin kubeconfig, because the examples impersonate a ServiceAccount with --as.

Read a Forbidden error, then grant exactly what it asks for

When a client calls the API with an identity that RBAC does not allow, the API server answers HTTP 403. The message a client prints usually names everything you need for the fix: the user, the verb, the resource, the API group and the namespace. Reading it field by field gives you a Role that is as small as the request, which is faster on the exam than guessing and safer than reaching for a broad ClusterRole.

User "system:serviceaccount:NS:NAME" ──→ RoleBinding subject (kind ServiceAccount)
cannot VERB                          ──→ Role rule: verbs
resource "RESOURCE"                  ──→ Role rule: resources
in API group "GROUP"                 ──→ Role rule: apiGroups ("" means core)
in the namespace "NS"                ──→ where the Role and RoleBinding live

1. Reproduce a denial without writing an app

Impersonation lets an admin send a request as another identity, so you see the same denial a Pod running under that ServiceAccount would get.

kubectl create namespace prepium-tutorial
kubectl -n prepium-tutorial create serviceaccount report-bot
kubectl -n prepium-tutorial create deployment web --image=nginx:1.27-alpine
kubectl -n prepium-tutorial get deployments \
  --as=system:serviceaccount:prepium-tutorial:report-bot

The reply is a Forbidden error. Read it in this order. The user string follows the documented pattern system:serviceaccount:<namespace>:<name>, so it tells you which ServiceAccount to bind and where it lives. The verb is list, not get, because a GET on a whole collection is authorized as list (a GET on one named object is get, and following changes is a separate verb, watch). The resource is deployments and the group is apps. An empty group "" would mean the core group, home of Pods, Services, ConfigMaps and Secrets.

2. Write the Role from the message, not from memory

kubectl -n prepium-tutorial create role deploy-watcher \
  --verb=list,watch --resource=deployments.apps
kubectl -n prepium-tutorial get role deploy-watcher -o yaml

The resource.group form keeps the rule in the right group. Check the YAML: the rule should show apiGroups: ["apps"]. We added watch deliberately because a controller-style client that lists usually watches next; add only verbs you can justify. RBAC has no deny rules, so anything you leave out stays forbidden.

3. Bind it to the ServiceAccount

kubectl -n prepium-tutorial create rolebinding report-bot-deploys \
  --role=deploy-watcher --serviceaccount=prepium-tutorial:report-bot

--serviceaccount takes namespace:name. A RoleBinding only grants inside its own namespace, even if the subject lives elsewhere. Its roleRef cannot be changed after creation; to point a binding at a different Role, delete and recreate it.

4. Prove it, including what must still fail

SA=system:serviceaccount:prepium-tutorial:report-bot
kubectl auth can-i list deployments.apps -n prepium-tutorial --as=$SA
kubectl auth can-i watch deployments.apps -n prepium-tutorial --as=$SA
kubectl auth can-i delete deployments.apps -n prepium-tutorial --as=$SA
kubectl auth can-i list deployments.apps -n default --as=$SA
kubectl auth can-i --list -n prepium-tutorial --as=$SA

Expect yes, yes, no, no. The two negatives matter as much as the positives: they show the grant is narrow and namespaced. Finally, a Pod only acts as this identity if its spec.serviceAccountName names it, and that field can only be set when the Pod is created.

Common mistakes

• Putting a non-core resource under apiGroups: [""]. The Role applies cleanly, but the next request is still Forbidden and the message still says the real group.
• Granting pods but not the pods/log subresource. Listing works, reading logs is denied. Subresources are written with a slash in the rule and checked with can-i get pods --subresource=log.
• Running kubectl auth can-i without --as. You test your own admin rights, which always say yes.
• Getting the subject namespace wrong in --serviceaccount. The binding exists but binds a different (or nonexistent) account.

Cleanup: kubectl delete namespace prepium-tutorial. References: Using RBAC Authorization, Authorization (request verbs and can-i), kubectl auth can-i. Next, try choosing the right ServiceAccount or CKA RBAC.