Skip to content

Prefer higher-priority bearer tokens over kubeconfig basic auth - #8002

Open
HarshDevelops wants to merge 1 commit into
fabric8io:mainfrom
HarshDevelops:iss_7960
Open

Prefer higher-priority bearer tokens over kubeconfig basic auth#8002
HarshDevelops wants to merge 1 commit into
fabric8io:mainfrom
HarshDevelops:iss_7960

Conversation

@HarshDevelops

Copy link
Copy Markdown

Fixes #7960

What was wrong

Auto-configuration keeps both a higher-priority bearer token (system property or environment) and lower-priority kubeconfig basic credentials. TokenRefreshInterceptor checks basic auth first, so the client can send Basic credentials even when a higher-priority token was supplied.

What changed

Config now ranks auth sources (system property > environment > kubeconfig) and clears the losing form when token and basic credentials compete. Same-rank values still keep both, matching previous same-source behaviour.

Testing

  • RED: TokenRefreshInterceptorConfigOrderTest fails without setRankedAuth (username/token retained from lower rank)
  • GREEN: ./mvnw -pl kubernetes-client-api -Dtest=TokenRefreshInterceptorConfigOrderTest test — 2 tests, 0 failures (JDK 21)
  • spotless:check on kubernetes-client-api

When a higher-priority bearer token (system property/env) competes
with lower-priority kubeconfig basic credentials, clear the losing
form so TokenRefreshInterceptor does not send Basic auth over the
token. Prefer higher-priority basic credentials over a lower-ranked
token the same way. Same-rank values keep previous combined behaviour.

Fixes fabric8io#7960
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Config order issue - lower-priority basic credentials override a higher-priority bearer token

1 participant