load_incluster_config() sets api_key['authorization'] but auth_settings() expects api_key['BearerToken'] in v36

[arghaffari]

What happened

After upgrading from kubernetes==35.0.0 to kubernetes==36.0.0, all API calls from pods using load_incluster_config() fail with 401 Unauthorized. The Bearer token is never sent in the Authorization header.

Root cause

In v36, Configuration.auth_settings() (auto-generated) checks for api_key['BearerToken']:

def auth_settings(self):
    auth = {}
    if 'BearerToken' in self.api_key:
        auth['BearerToken'] = {
            'type': 'api_key',
            'in': 'header',
            'key': 'authorization',
            'value': self.get_api_key_with_prefix('BearerToken'),
        }
    return auth

But InClusterConfigLoader._set_config() (manually maintained in kubernetes/base/) still sets the old key:

def _set_config(self, client_configuration):
    client_configuration.host = self.host
    client_configuration.ssl_ca_cert = self.ssl_ca_cert
    if self.token is not None:
        client_configuration.api_key['authorization'] = self.token  # <-- old key

Since auth_settings() looks for 'BearerToken' and load_incluster_config sets 'authorization', the token is never picked up by ApiClient.update_params_for_auth(), so no Authorization header is sent.

In v35, auth_settings() checked for 'authorization', so both sides agreed and everything worked.

How to reproduce

# Inside a pod with a service account
from kubernetes import client, config

config.load_incluster_config()
v1 = client.CoreV1Api()
v1.list_namespaced_pod('default', limit=1)
# => kubernetes.client.exceptions.UnauthorizedException: (401)

Verified that the token itself is valid — a direct urllib.request call with the same token from /var/run/secrets/kubernetes.io/serviceaccount/token returns 200.

Expected behavior

load_incluster_config() should set api_key['BearerToken'] (matching what auth_settings() expects), or auth_settings() should check for api_key['authorization'] (matching what load_incluster_config sets).

Environment

• Kubernetes cluster version: 1.31
• Python version: 3.13.12
• kubernetes client version: 36.0.0 (works fine on 35.0.0)

[MatanKoby]

Happened to me too.
Modifiying lines 528-530 in file kubernetes/base/config/kube_config.py:

def _set_config(self, client_configuration): if 'token' in self.__dict__: client_configuration.api_key['authorization'] = self.token

into

def _set_config(self, client_configuration): if 'token' in self.__dict__: client_configuration.api_key['authorization'] = self.token client_configuration.api_key['BearerToken'] = self.token

is an instant fix for me.

EDIT: Downgrading to v35 is obviously a better fix till a fix is merged, just to mention.

[exherb]

crazy bug.

[faust64]

EDIT: Downgrading to v35 is obviously a better fix till a fix

... or 33.1.0, if you were impacted by the no_proxy regression that should finally be fixed in 36.0.0.

or give up and rewrite your code using reliable libraries, like requests ...

[saviomuniz]

We had a similar issue, while trying to run a PATCH to a Pod using default service account. RBAC was properly set. Downgrading to 35.0.0 also fixed the issue for us
{"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"Unauthorized","reason":"Unauthorized","code":401}

[roycaihw]

This is a duplicate of #2582 and is being fixed in #2585