v36.0.0 regression: load_incluster_config() sends requests as system:anonymous on GKE

[starboyhassan]

What happened

After upgrading from kubernetes==35.0.0 to kubernetes==36.0.0, all API calls
made via load_incluster_config() are rejected with 403 Forbidden and
User "system:anonymous", resulting in requests being treated as unauthenticated.

Downgrading back to kubernetes==35.0.0 immediately resolves the issue with
zero other changes.

Environment

• Kubernetes version: GKE v1.32.4
• Python client version: kubernetes==36.0.0 (broken), kubernetes==35.0.0 (working)
• Python version: 3.11
• Container image: python:3.11-slim
• Runtime environment: Python application running inside a Docker container on GKE
• Authentication method: config.load_incluster_config() using mounted ServiceAccount token
• Cloud: Google Kubernetes Engine (GKE) with Workload Identity enabled

How to reproduce

1. Run a pod on GKE with Workload Identity enabled on the node pool
2. Use kubernetes==36.0.0
3. Call config.load_incluster_config() followed by any API call:

from kubernetes import client, config

config.load_incluster_config()
v1 = client.CoreV1Api()
v1.list_pod_for_all_namespaces(watch=False)  # 403 — system:anonymous

What you expected to happen

Requests should authenticate as the pod's ServiceAccount, same as v35.0.0.

What actually happened

(403)
Reason: Forbidden
HTTP response body:
{
  "message": "pods is forbidden: User \"system:anonymous\" cannot list resource \"pods\" in API group \"\" at the cluster scope"
}

Anything else we need to know?

Additional validation performed:

• ServiceAccount token exists correctly at:
  /var/run/secrets/kubernetes.io/serviceaccount/token
• kubectl auth can-i confirms RBAC permissions are valid
• Raw authenticated requests using the mounted token succeed
• Only the Python Kubernetes client in v36.0.0 fails

Confirmed workaround:

kubernetes==35.0.0

[aojea]

This is a duplicate, a fix has been merged and a release is going to be cut soon

[starboyhassan]

Thanks for looking into this.

While I understand this likely stems from the same underlying regression in v36.0.0 (the BearerToken vs authorization key change), I believe the observed behavior here is different enough to be worth highlighting separately.

Unlike the 401 Unauthorized reported in #2584 and #2591, my cluster setup results in a 403 Forbidden with system:anonymous. This appears to happen in environments like GKE where a missing token is treated as an anonymous request rather than being rejected immediately as unauthorized.

So while the root cause may be the same, I think this issue provides a useful additional data point for the 403 system:anonymous scenario, which might not be immediately obvious from the existing reports.

If this is already covered by the fix in PR #2585, feel free to close this as a duplicate — I just wanted to make sure this specific behavior is captured.