How to Fix Kubernetes Forbidden Errors
Diagnose kubectl Forbidden errors by checking identity, context, RBAC permissions, namespace scope, service accounts, and admission policy.
A Kubernetes Forbidden response means the API server authenticated the request but did not authorize the requested action, or a later admission policy denied it. Do not solve it by granting cluster-admin before identifying the exact identity, verb, resource, and scope involved.
Read the complete error
A typical authorization error identifies the user, verb, resource, and namespace:
Error from server (Forbidden): pods is forbidden: User "developer@example.com"
cannot list resource "pods" in API group "" in the namespace "production"
Keep that information. It describes the permission Kubernetes evaluated.
Confirm the active context and identity
kubectl config current-context
kubectl config view --minify
kubectl auth whoami
kubectl auth whoami requires support from the cluster API version. If unavailable, inspect the minified kubeconfig without printing embedded tokens or client keys into shared logs.
Verify the namespace used by the command:
kubectl config view --minify --output 'jsonpath={..namespace}'
An omitted namespace may send a request to default while the permission exists somewhere else.
Ask Kubernetes about the exact permission
Use kubectl auth can-i with the same verb, resource, and namespace:
kubectl auth can-i list pods -n production
kubectl auth can-i create deployments.apps -n production
For a service account, an authorized administrator can test impersonation:
kubectl auth can-i get secrets \
--as=system:serviceaccount:production:my-service \
-n production
Impersonation itself requires permission. A failed impersonation test does not necessarily describe the service account’s actual access.
Trace the relevant RBAC bindings
List names and subjects without exposing Secret data:
kubectl get rolebindings,clusterrolebindings -A
kubectl describe rolebinding BINDING -n production
kubectl describe clusterrole ROLE
Check whether the subject kind, name, group, and namespace exactly match the authenticated identity. A RoleBinding grants access only in its namespace, even when it references a ClusterRole.
Distinguish authorization from admission denial
If kubectl auth can-i says yes but the operation is still forbidden, read the full API response and cluster events. A validating admission policy, policy engine, or managed-cluster restriction may reject the object after RBAC authorization.
The denial message often names the responsible webhook or policy. Fix the requested object or approved policy exception rather than broadening RBAC unnecessarily.
Diagnose it with Rumus
Rumus is an AI-native terminal that can use your current Kubernetes context to correlate pods, events, logs, controllers, resources, and nodes. It keeps the investigation read-only until you approve a proposed change.
What Rumus can inspect
- Pods, events, previous logs, and owning controllers
- Resources, probes, scheduling rules, and node state
- Secret-aware output and approval before cluster changes
Diagnose this Kubernetes Forbidden error. Identify the active context, authenticated
subject, verb, API group, resource, subresource, namespace, and the result of exact
kubectl auth can-i checks. Trace relevant Roles and Bindings, then determine whether
RBAC or admission denied the request. Never print credentials or grant cluster-admin,
and do not change access without approval.
Confirm the fix
Repeat the narrow authorization check before retrying the real operation:
kubectl auth can-i list pods -n production
kubectl get pods -n production
Confirm that the intended identity can perform only the required action and that unrelated privileged operations remain denied.
Open the server in Rumus and let the AI agent inspect context, propose a plan, and ask before it runs changes.