ADC support for SPIFFE as a first-class external credential source

[jeengbe]

Library Name

google-auth-library

A screenshot that you have tested with "Try this API".

n/a

What would you like to see in the library?

This feature request spans beyond just the JS library, but I am unsure where else to start.

It would be useful for ADC to support SPIFFE as a kind of credential source, e.g.:

{
  "universe_domain": "googleapis.com",
  "type": "external_account",
  "audience": "//iam.googleapis.com/projects/<project>/locations/global/workloadIdentityPools/<pool>/providers/<provider>",
  "subject_token_type": "urn:ietf:params:oauth:token-type:jwt",
  "token_url": "https://sts.googleapis.com/v1/token",
  "credential_source": {
    "spiffe": {
      "type": "jwt"
    }
  }
}

This should instruct the SDK to fetch a JWT-SVID from the Workload API and use that for STS token exchanges. Since both JWT-SVIDs and X509-SVIDs are compatible with OIDC and X.509 workload identity pool providers, respectively, the type annotation necessarily indicates the desired format. The configuration should additionally allow a hint parameter in the scenario that a workload is entitled to multiple SVIDs.

In a future, ADC (clients and GCP, that is) could also support the urn:ietf:params:oauth:client-assertion-type:jwt-spiffe subject token type.

Describe alternatives you've considered

Alternatives include:

• Using one of the existing credential sources with files that are written to disk by a separate component or a dedicated HTTP server on loopback, e.g. SPIFFE Helper or custom code. Drawbacks: Complex to set up and maintain, duplication of the "audience" parameter that needs to match //iam.googleapis.com/... exactly, and the ADC configuration no longer exactly matches reality.
• Using an external executable to fetch a JWT-SVID from, such as the SPIRE Agent. Drawbacks: Many moving parts, also requires GOOGLE_EXTERNAL_ACCOUNT_ALLOW_EXECUTABLES=1, so auth configuration no longer "purely" lives in ADC.
• Creating a manual SpiffeTokenSupplier implements SubjectTokenSupplier that communicates with the Workload API through user code. Drawbacks: Requries manual authClient handling (substantial overhead if several Google API clients used in multiple places). Additional ADC parameters (e.g. audience) need to be handled by user code.

All of these alternatives require custom code and an understanding of google-auth-library internals beyond "just provide an ADC file and it works".

Additional context/notes

No response

[sofisl]

@vverman is this something you'd know where to direct?

[jeengbe]

I dug a bit deeper and found that aip-dev/google.aip.dev#1609 was probably the right place to pitch this. I think we can close this issue here.