Introduction

The message "forbidden: User ... cannot get path /" means the request reached the server with a real authenticated identity, but that identity is not authorized to read the requested path. In Kubernetes, this often appears when a user, service account, or client certificate is valid but lacks the RBAC permission needed to query the API root or a specific endpoint. The fix is not to bypass authentication; it is to confirm which identity is making the request and grant only the permissions that identity actually needs.

What the Error Tells You

There are two important clues in the message.

First, forbidden means authentication probably succeeded. If the client were truly unauthenticated, you would more likely see an unauthorized response.

Second, not anonymous user tells you the server has identified a concrete principal. In Kubernetes terms, that might be:

• a human user from a kubeconfig credential
• a service account token
• a client certificate subject
• an OIDC-authenticated identity

So the problem is usually authorization, not login failure.

Verify the Identity First

Before changing RBAC, confirm who the server thinks you are. A common source of confusion is using the wrong kubeconfig context or an unexpected service account inside a pod.

Start with the basics:

kubectl config current-context
kubectl config view --minify
kubectl auth whoami

If the failing request comes from inside a pod, inspect the mounted service account and namespace:

cat /var/run/secrets/kubernetes.io/serviceaccount/namespace
cat /var/run/secrets/kubernetes.io/serviceaccount/token | cut -c1-20

You do not need the full token value in logs. The point is to verify which service account is in play.

Check RBAC with kubectl auth can-i

Once you know the identity, test whether it can perform the operation you need. For resource requests, kubectl auth can-i is the quickest check.

kubectl auth can-i get pods --namespace default
kubectl auth can-i list deployments --namespace production
kubectl auth can-i get --raw /healthz

If the command returns no, RBAC is the next place to look.

A minimal Role and RoleBinding example for reading pods in one namespace is:

1apiVersion: rbac.authorization.k8s.io/v1
2kind: Role
3metadata:
4  name: pod-reader
5  namespace: default
6rules:
7  - apiGroups: [""]
8    resources: ["pods"]
9    verbs: ["get", "list", "watch"]
10---
11apiVersion: rbac.authorization.k8s.io/v1
12kind: RoleBinding
13metadata:
14  name: pod-reader-binding
15  namespace: default
16subjects:
17  - kind: ServiceAccount
18    name: app-sa
19    namespace: default
20roleRef:
21  apiGroup: rbac.authorization.k8s.io
22  kind: Role
23  name: pod-reader

That is the right pattern: grant a specific identity specific verbs on specific resources.

Why the Path / Can Be Special

The exact path / is not the same as a normal namespaced resource such as pods. If a client library or reverse proxy is probing the API root, the permission check may apply to a non-resource URL rather than a resource type.

In Kubernetes RBAC, non-resource URLs are handled separately. If you truly need access to /, /healthz, or /version, the rule can look like this:

1apiVersion: rbac.authorization.k8s.io/v1
2kind: ClusterRole
3metadata:
4  name: api-root-reader
5rules:
6  - nonResourceURLs: ["/", "/healthz", "/version"]
7    verbs: ["get"]

Then bind it with a ClusterRoleBinding.

1apiVersion: rbac.authorization.k8s.io/v1
2kind: ClusterRoleBinding
3metadata:
4  name: api-root-reader-binding
5subjects:
6  - kind: User
7    name: my-user
8    apiGroup: rbac.authorization.k8s.io
9roleRef:
10  apiGroup: rbac.authorization.k8s.io
11  kind: ClusterRole
12  name: api-root-reader

This is one of the reasons the error looks odd. People expect a normal resource permission problem, but the failing request can actually be a non-resource URL request.

Debug the Caller, Not Just the Cluster

If the error comes from an application, inspect what it is actually requesting. Some clients probe / on startup just to verify connectivity. If that probe is unnecessary, removing it may be better than broadening permissions.

A clean debugging sequence is:

1. identify the exact caller identity
2. capture the exact failing path and HTTP verb
3. test authorization with kubectl auth can-i
4. grant the narrowest possible RBAC rule
5. retry and verify logs

That process is safer than adding cluster-admin access because it keeps the authorization surface tight.

Common Pitfalls

The most common mistake is granting a broad role before identifying the actual user or service account. That fixes the symptom while hiding the real configuration problem.

Another mistake is treating the root path / as if it were a normal Kubernetes resource. Non-resource URLs use different RBAC rules.

People also frequently debug the wrong kubeconfig context and end up changing permissions for an identity that was never making the request.

Finally, do not confuse authorization failures with anonymous access. The message explicitly says the server recognized a non-anonymous user.

Summary

• "cannot get path /" usually means authentication worked but authorization failed
• The first step is to identify the exact user or service account making the request
• Use kubectl auth can-i to test whether the identity has the required permission
• Requests to / may require RBAC rules for non-resource URLs rather than normal resources
• Grant the narrowest possible Role, ClusterRole, or binding needed for the real caller
• Fix the caller's unnecessary API probes if broader access is not justified