Fix regressions in Configuration.get_api_key_with_prefix bearer-token prefix lookup

[HaimLC]

What type of PR is this?

/kind bug
/kind regression

What this PR does / why we need it:

#2604 restored the api_key['authorization'] fallback in auth_settings() by calling get_api_key_with_prefix('BearerToken', alias='authorization'), but get_api_key_with_prefix only applies the alias fallback to the api_key lookup, not the api_key_prefix lookup:

key = self.api_key.get(identifier, self.api_key.get(alias) if alias is not None else None)
if key:
    prefix = self.api_key_prefix.get(identifier)  # never checks `alias`

So callers that set the prefix under the legacy 'authorization' key (rather than embedding "Bearer " directly in the token string) get a bearer token with no "Bearer " prefix in the resulting Authorization header. Most API servers — and specifically GKE's anonymous-auth fallback — don't recognize an unprefixed token as a valid bearer credential, so the request is treated as system:anonymous.

This reproduces with a plain manual Configuration(), no load_incluster_config()/load_kube_config() involved:

from kubernetes import client

configuration = client.Configuration()
configuration.api_key["authorization"] = "<token>"
configuration.api_key_prefix["authorization"] = "Bearer"

print(configuration.auth_settings())
# before this PR: value = '<token>'          (missing "Bearer " prefix)
# after this PR:  value = 'Bearer <token>'   (correct)

This PR applies the same alias fallback already used for the key lookup to the prefix lookup, symmetrically in the sync (kubernetes/client/configuration.py) and async (kubernetes/aio/client/configuration.py) variants.

Verified against a real cluster in production: a service using this exact pattern (manual Configuration with api_key/api_key_prefix under 'authorization', talking to an external GKE cluster) was hitting system:anonymous on 36.0.2. Built this fix into that service via a git+ dependency pointing at this branch and confirmed it now authenticates correctly against the live cluster with zero code changes on the caller's side.

Which issue(s) this PR fixes:

Fixes #2592

• Comments in v36.0.0 regression: load_incluster_config() sends requests as system:anonymous on GKE #2592 from @markafarrell and @anastasiyatolstikenableu independently confirm 36.0.2 doesn't fully fix this for callers outside load_incluster_config()/load_kube_config(), matching this root cause.
• Applied symmetrically to the sync and async variants, matching the precedent set by Restore bearer-token fallback in Configuration.auth_settings() #2604.
• Added a regression test, test_auth_settings_with_authorization_key_and_prefix, covering the split key/prefix case that the existing Restore bearer-token fallback in Configuration.auth_settings() #2604 tests didn't exercise (those set the full 'Bearer abc123' string directly in api_key['authorization'], which doesn't touch the prefix lookup at all).
• I did not touch scripts/apply-hotfixes.sh in this PR since it needs this commit's final SHA — happy to follow up with that once this merges, same as was done for 5621a4c after Restore bearer-token fallback in Configuration.auth_settings() #2604.

Does this PR introduce a user-facing change?

Fixed a regression where `Configuration.auth_settings()` would drop the `"Bearer "` prefix for callers using the legacy `api_key['authorization']` / `api_key_prefix['authorization']` convention, causing requests to be sent without a valid Authorization header and rejected as `system:anonymous`. This is a follow-up to the fix in #2604, which restored the key fallback but missed the prefix fallback.

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: HaimLC / name: HaimLC (5a8b6a5)

[kubernetes-prow]

Welcome @HaimLC!

It looks like this is your first PR to kubernetes-client/python 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-client/python has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[Copilot]

Pull request overview

Fixes a regression in Configuration.get_api_key_with_prefix() where the alias= fallback was applied to api_key but not to api_key_prefix, causing legacy bearer-token configurations (token and "Bearer" prefix stored separately under 'authorization') to emit an unprefixed Authorization header value.

Changes:

• Apply alias fallback to api_key_prefix lookup in the sync Configuration.get_api_key_with_prefix().
• Apply the same alias fallback to api_key_prefix lookup in the async aio Configuration.get_api_key_with_prefix().
• Add a regression test covering the legacy split token/prefix case for the sync configuration.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
kubernetes/client/configuration.py	Adds alias fallback to the prefix lookup so legacy 'authorization' prefix keys are honored.
kubernetes/aio/client/configuration.py	Mirrors the same alias fallback behavior in the async configuration implementation.
kubernetes/test/test_api_client.py	Adds a regression test ensuring split api_key/api_key_prefix under 'authorization' produces a properly prefixed bearer value.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[yliaog]

could you please add a test case for async, similar to the sync case?

[yliaog]

@HaimLC friendly ping ...

[HaimLC]

sorry didnt saw it in conversation :) fixing.

[yliaog]

please sign the CLA

[HaimLC]

signed

[yliaog]

@kramaranya could you review this PR ?

[yliaog]

/lgtm
/approve

[kubernetes-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: HaimLC, yliaog

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [yliaog]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[yliaog]

thanks for the PR