feat(auth): Authenticate existing clusters via their declared cloud identity#324
Merged
Merged
Conversation
negz
reviewed
Jul 7, 2026
…dentity Signed-off-by: Christopher Haar <christopher.haar@upbound.io>
c9e093f to
b851c39
Compare
Signed-off-by: Christopher Haar <christopher.haar@upbound.io>
negz
approved these changes
Jul 7, 2026
4 tasks
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
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.
Description of your changes
Bringing your own cluster with an
identitySecretRefalways authenticated as a Google credential, whatever the cloud. So a Nebius or AWS credential got the wrong type, the providers couldn't log in, and the cluster never went Ready, with no upfront error.identitySecretRefnow takes atypefor the cloud identity (defaultGoogleApplicationCredentials, so existing setups are unchanged). It's threaded through to both ProviderConfigs, and an unsupported type is rejected at apply time. GKE stays Google as before.Nebius needs provider builds carrying the
NebiusServiceAccountCredentialsidentity (crossplane-contrib/provider-kubernetes#499), so both providers are pinned to pre-release builds for now. Tested end-to-end against a real Nebius cluster.Depends on crossplane-contrib/provider-kubernetes#499.
Fixes #321
I have:
nix flake check(or./nix.sh flake check) and made sure it passes.git commit -s.How this PR gets tested
tested servingStack only
on the nebius side:
inside the controlplane where modelplane is installed:
inside nebius kubernetes cluster:
setup serving stack: