feat: support Google Workload Identity Federation for multi-cloud#4739
Open
sergiocharpineljr wants to merge 1 commit intodexidp:masterfrom
Open
feat: support Google Workload Identity Federation for multi-cloud#4739sergiocharpineljr wants to merge 1 commit intodexidp:masterfrom
sergiocharpineljr wants to merge 1 commit intodexidp:masterfrom
Conversation
Signed-off-by: Sergio Charpinel <sergiocharpinel@gmail.com>
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.
Overview
Add support for
external_accountcredentials (Workload Identity Federation) in the Google connector's directory service for group fetching. This enables Dex to fetch Google Groups when running outside GCP (e.g. AWS, Azure) without requiring a service account key file.What this PR does / why we need it
Closes #4688
When Dex is configured to fetch Google Groups via the Admin Directory API,
createDirectoryServiceusedgoogle.JWTConfigFromJSONwhich only acceptsservice_accounttype credentials. This forced operators to provision and manage a service account key file, even when running on non-GCP clouds (e.g. AWS) where Google Workload Identity Federation (external_account credentials) is the recommended approach.There was a first attempt to simplify things by using
google.CredentialsFromJSONWithParams, which already supports all credential types and theSubjectfield for domain-wide delegation internally. So the fix would be a single-call replacement. But this didn't work since thegolang.org/x/oauth2/googlelib only respects theSubjectfield forservice_accounttype credential.createDirectoryServicenow handles credentials in two paths:service_account(existing):google.JWTConfigFromJSONwithSubjectfor domain-wide delegation — unchanged behavior.external_account(new):impersonate.CredentialsTokenSourcewithSubject, following the same pattern as Vault's GSuite provider.Additionally,
getCredentialsFromDefaultandgetCredentialsFromFilePathwere inlined intocreateDirectoryServiceto reduce indirection, and the ADC path now usesgoogle.FindDefaultCredentialsWithParamsto avoid redundant credential parsing.Future improvements
serviceAccountEmailconfig field: Currently the service account email is extracted from theservice_account_impersonation_url in the credential file. A dedicated config field (similar to Vault's impersonate_principal) would be cleaner and eliminate the URL parsing.
AWS_WEB_IDENTITY_TOKEN_FILEenv var). A customAwsSecurityCredentialsSuppliercould address this.Special notes for your reviewer
There is a deprecation notice for WithCredentialsJSON as per below:
I don't think it applies for our scenario. Let me know if you think otherwise.
Apart from the code tests I did a manual validation for Dex running along with ArgoCD in EKS (AWS) with IMDS. I've configured Dex with a WIF credential file (
gcloud iam workload-identity-pools create-cred-config --aws) and group fetching works.