Cap kubernetes client to <36 to fix cluster auth 401 regression#69025
Closed
shahar1 wants to merge 1 commit into
Closed
Cap kubernetes client to <36 to fix cluster auth 401 regression#69025shahar1 wants to merge 1 commit into
shahar1 wants to merge 1 commit into
Conversation
shahar1
requested review from
hussein-awala,
jedcunningham and
jscheffl
as code owners
boring-cyborg
Bot
added
area:providers
kind:documentation
provider:cncf-kubernetes
Client 36.x renamed the bearer-token auth key from 'authorization' to 'BearerToken' (kubernetes-client/python#2582). Provider code that hand-builds a Configuration with api_key={'authorization': ...} -- the google (GKE) sync hook -- then loses the "Bearer " prefix and sends the raw token, so the cluster rejects requests with 401. 36.0.1 fixed only the in-cluster and kube_config loaders, not that path. 35.x is the last known-good line, so restore the previous cap until the provider auth paths are fixed and validated on 36.x.
shahar1
force-pushed
the
cap-kubernetes-client-below-36
branch
from
beb98ff to
b9e69e5
Compare
3 tasks
1 task
Contributor
|
@shahar1 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
apache-airflow-providers-cncf-kubernetes10.18.0 widened the kubernetes client bound to allow 36.x (#68041). Client 36.x renamed the bearer-token auth key fromauthorizationtoBearerToken(kubernetes-client/python#2582), which breaks authentication for code that hand-builds aConfiguration.The google (GKE) sync hook sets
api_key={"authorization": token}/api_key_prefix={"authorization": "Bearer"}. On 36.x,get_api_key_with_prefix("BearerToken", alias="authorization")finds the token via theauthorizationalias but looks up the prefix by the primary identifierBearerToken(absent), so theBearerprefix is dropped and the request goes out asAuthorization: <raw token>→ 401 Unauthorized (immediate, not token-rotation related). This was caught while testing the google (GKE) provider; downgrading the provider to 10.17.1 (client 35.x) is the reported workaround.36.0.1 (kubernetes-client/python#2585) fixed this only for
load_incluster_config()/load_kube_config()(which cncf's own hooks use), not for hand-built configs — so the google GKE sync path still breaks on 36.0.1/36.0.2. It is the same 36.xConfigurationchange behind the in-cluster pickling crash (#68827).35.x is the last known-good line, so this restores the previous
<36cap for bothkubernetesandkubernetes_asynciountil the provider auth paths support 36.x. Full 36.x support (google GKE sync hook fix + a regression test assertingAuthorization: Bearer <token>) is tracked in #69023, linked from the cap site inpyproject.toml.related: #69023
related: #68827
Was generative AI tooling used to co-author this PR?
Generated-by: Claude Code (Opus 4.8) following the guidelines