`Configuration.auth_settings()` returns empty dict in v36.0.0 - all BearerToken-authed requests go anonymous

[Jmacek]

What happened

Upgrading from kubernetes==35.0.0 to kubernetes==36.0.0 causes every API request that relies on a Bearer token (the in-cluster ServiceAccount auth path, or any caller that sets Configuration.api_key['authorization'] directly) to be sent without an Authorization header. The server treats the request as system:anonymous and rejects it (401 on AKS, 403 on minikube).

Minimal reproducer

Direct check of the method the generated API operations call to attach auth headers before sending HTTP requests:

from kubernetes import client

cfg = client.Configuration()
cfg.api_key['authorization'] = 'Bearer fake-token'

api = client.ApiClient(cfg)
headers = {}
api.update_params_for_auth(headers, [], ['BearerToken'])
print('headers:', headers)

Expected output (matches v35.0.0)

headers: {'authorization': 'Bearer fake-token'}

Actual output on v36.0.0

headers: {}

The Bearer-token-aware code path is silently a no-op. The HTTP request goes out with no Authorization header and the server treats it as system:anonymous.

Supporting evidence

Configuration.auth_settings() - which update_params_for_auth reads to find scheme definitions - is also empty on v36:

>>> cfg.auth_settings()                # v35: {'BearerToken': {...}}
{}                                     # v36

So the regression is at the Configuration level: the BearerToken scheme entry that should be present in auth_settings() (and is in v35) is missing in v36, which cascades into update_params_for_auth having nothing to apply.

Impact

Any pod doing in-cluster API calls via this library is broken on v36.0.0 - including (but not limited to) callers of CoordinationV1Api, CoreV1Api, etc. We caught this when our Lease-coordinated workload pods started failing every read_namespaced_lease call with 401 immediately after a rebuild upgraded the lib from v35 to v36.

Environment

• kubernetes==36.0.0 (uploaded to PyPI 2026-05-20T20:44Z)
• Python 3.12 / 3.13 (reproduced on both)
• Linux container (also reproduced on macOS in a clean venv)

Regression window

The bug is present in the entire 36-series:

Version	PyPI upload	update_params_for_auth result
v35.0.0	2026-01-16	populates {'authorization': 'Bearer ...'}
v36.0.0a3	2026-05-08	empty {} (regression introduced here)
v36.0.0b1	2026-05-13	empty {}
v36.0.0	2026-05-20	empty {}

So the regression was present from the first 36-series prerelease and shipped to stable without a fix. The diff between v35.0.0..v36.0.0a3 should contain the offending change.

Workaround

Pin kubernetes>=29,<36 until a v36 patch ships.

Hypothesis (haven't dug in further)

This looks like the OpenAPI/swagger-driven code generation for Configuration regressed - the dict literal that defines the BearerToken entry under auth_settings() likely got dropped or scoped out. Worth diffing the generated Configuration class between v35.0.0 and v36.0.0.

[jhostetler]

Also experiencing this issue. Requests to create resources succeed using version 35.0.0 but raise a 403 with 36.0.0