Skip to content

feat: support Google Workload Identity Federation for multi-cloud#4739

Open
sergiocharpineljr wants to merge 1 commit intodexidp:masterfrom
sergiocharpineljr:master
Open

feat: support Google Workload Identity Federation for multi-cloud#4739
sergiocharpineljr wants to merge 1 commit intodexidp:masterfrom
sergiocharpineljr:master

Conversation

@sergiocharpineljr
Copy link
Copy Markdown

Overview

Add support for external_account credentials (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, createDirectoryService used google.JWTConfigFromJSON which only accepts service_account type 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 the Subject field for domain-wide delegation internally. So the fix would be a single-call replacement. But this didn't work since the golang.org/x/oauth2/google lib only respects the Subject field for service_account type credential.

createDirectoryService now handles credentials in two paths:

  1. service_account (existing): google.JWTConfigFromJSON with Subject for domain-wide delegation — unchanged behavior.
  2. external_account (new): impersonate.CredentialsTokenSource with Subject, following the same pattern as Vault's GSuite provider.

Additionally, getCredentialsFromDefault and getCredentialsFromFilePath were inlined into createDirectoryService to reduce indirection, and the ADC path now uses google.FindDefaultCredentialsWithParams to avoid redundant credential parsing.

Future improvements
  • Explicit serviceAccountEmail config field: Currently the service account email is extracted from the
    service_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.
  • IRSA support: The Google oauth2 library's AWS credential source does not support EKS IRSA (AWS_WEB_IDENTITY_TOKEN_FILE env var). A custom AwsSecurityCredentialsSupplier could address this.

Special notes for your reviewer

There is a deprecation notice for WithCredentialsJSON as per below:

Deprecated: This function is being deprecated because of a potential security risk.
This function does not validate the credential configuration. The security risk occurs when a credential configuration is accepted from a source that is not under your control and used without validation on your side.

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.

Signed-off-by: Sergio Charpinel <sergiocharpinel@gmail.com>
@sergiocharpineljr sergiocharpineljr marked this pull request as ready for review April 10, 2026 19:21
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.

Support Google Workload Identity Federation for multi-cloud

1 participant