shahar1 opened a new pull request, #69032: URL: https://github.com/apache/airflow/pull/69032
Addresses the GKE 401 regression reported on the cncf.kubernetes 2026-06-16 RC by fixing the **google provider** rather than capping the kubernetes client to `<36` (which would reintroduce the NO_PROXY issue that 36.x fixed). ### Problem kubernetes-client 36.x renamed the bearer-token auth key from `authorization` to `BearerToken` ([kubernetes-client/python#2582](https://github.com/kubernetes-client/python/issues/2582)). `GKEClusterConnection` hand-builds a `Configuration` and registered the token/prefix only under `authorization`. On 36.x, `auth_settings()` resolves the bearer value via `get_api_key_with_prefix("BearerToken", alias="authorization")`: the token is found through the `authorization` alias, but the **prefix** is looked up by the primary identifier `BearerToken` (absent), so the `Bearer ` prefix is dropped. Requests then go out as `Authorization: <raw token>` and the cluster rejects them with **401**. (36.0.1 fixed this only for `load_incluster_config`/`load_kube_config`, not hand-built configs.) ### Fix Register the bearer token and prefix under **both** `authorization` (client 35.x) and `BearerToken` (client 36.x), in `_get_config` and the token-refresh hook. Authentication now works on both client lines, so the provider supports 36.x without a downgrade. The refresh-on-expiry behavior is preserved. ### Test `TestGKEClusterConnection.test_auth_settings_send_bearer_prefixed_token` asserts the real `auth_settings()["BearerToken"]["value"]` is `Bearer <token>` (both valid and expiring credentials). Verified it fails on the pre-fix code under client 36.0.2 and passes after. related: #69023 --- ##### Was generative AI tooling used to co-author this PR? - [X] Yes — Claude Code (Opus 4.8) Generated-by: Claude Code (Opus 4.8) following [the guidelines](https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
