Add support to impersonate SA when GoogleApplicationCredentials identity type is used #378
+172
−78
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
Use case:
Multiple GKE environments across different GCP projects are managed by Crossplane. Each environment has a preconfigured
managementservice account, which can be impersonated by the Crossplane service account.After provisioning GKE clusters, we want to manage Kubernetes API objects using
provider-kubernetes, leveraging the same authentication flow—specifically, impersonating the respective service account in each target project.This pull request adds support for setting
identity.impersonatedServiceAccount.namewhenidentity.type: GoogleApplicationCredentialsis used. This allows the retrieved credentials to be exchanged for an impersonated service account token.I have:
make reviewable testto ensure this PR is ready for review.How has this code been tested
This code has been built, published to a private repo, and tested with Crossplane v1.20 in our GCP environment. As we don't see the way to test google auth in local environment.
For reference, the built image has been pushed to Docker Hub: https://hub.docker.com/r/kostyaplis/provider-kubernetes/tags
Please let us know if the logic introduced aligns with the provider's design principles, so this feature has the potential to be officially released.
If not, we would appreciate any guidance on whether the same authentication flow can be achieved using existing tools. Thank you in advance!