cannot list resource at the cluster scope: A cluster-wide request was made with only namespaced permissions

The phrase at the cluster scope in a Forbidden message means the request was not limited to a namespace. That requires a ClusterRole bound with a ClusterRoleBinding — a RoleBinding will not do it.

Applies to: All Kubernetes versions with RBAC enabled

What it means

Kubernetes distinguishes three situations that look similar and are not: a namespaced request, a cluster-wide request across all namespaces, and a request for a resource that has no namespace at all. Listing pods in one namespace needs a Role or a ClusterRole bound by a RoleBinding. Listing pods across every namespace, which is what --all-namespaces does, is a cluster-scoped request and needs a ClusterRoleBinding. And resources such as nodes, PersistentVolumes, and namespaces themselves are cluster-scoped objects, so access to them is always cluster-scoped regardless of intent. The at the cluster scope phrasing in the error is the signal that you are in one of the latter two situations.

Most common causes

• A ClusterRole was bound with a RoleBinding, which limits it to a single namespace.
• A client using --all-namespaces or watching across all namespaces with only namespaced permissions.
• Access requested to an inherently cluster-scoped resource such as nodes or PersistentVolumes.
• A controller that watches cluster-wide by default, deployed with namespace-scoped RBAC.
• An operator installed with a Role where its documentation specified a ClusterRole.

How to diagnose it

1. Read whether the message says in the namespace "…" or at the cluster scope — that distinction is the whole diagnosis.
2. Check what exists: kubectl get clusterrolebinding -o wide | grep SUBJECT.
3. Test directly: kubectl auth can-i list nodes --as=system:serviceaccount:NS:NAME.
4. Determine whether the resource is namespaced at all: kubectl api-resources | grep RESOURCE shows a NAMESPACED column.
5. For a controller, check whether it is configured to watch one namespace or all of them — many have a flag for this.

How to fix it

1. Create a ClusterRoleBinding rather than a RoleBinding when cluster-wide access is genuinely required.
2. Alternatively, configure the controller to watch only the namespaces it needs, and keep the narrower RoleBinding. This is usually the better choice.
3. For cluster-scoped resources there is no namespaced alternative — a ClusterRoleBinding is the only option.
4. Grant the narrowest set of resources and verbs that works, since cluster-scoped grants apply everywhere by definition.

Notes

A ClusterRole bound by a RoleBinding is a genuinely useful pattern: it lets one role definition be reused across namespaces while granting access only within each. It is also the exact configuration that produces this error when cluster-wide access was what was actually needed.

Related

• Error from server (Forbidden) — RBAC denied the request
• Unauthorized — The request was not authenticated

Sources

• Kubernetes documentation — Using RBAC Authorization
• Kubernetes documentation — Authorization Overview