Mint Google access tokens in the Kubernetes credential provider

[dhaifley]

A Google service account key cannot be injected into a request as it stands. Vertex AI and the other Google APIs accept OAuth 2.0 access tokens, and minting one means signing a JWT with the key's private key, which a static header value cannot do. Once every credential goes through the egress gateway, a workload behind it such as Claude Code or the Google SDKs has no way to reach Vertex AI.

This adds a second provider name to the Kubernetes credential provider, google-access-token.kubernetes.io, served by the same Deployment. The path is the same <namespace>/<secret>[/<key>], and the same injector identity, atespace-to-namespace grant and Secret RBAC apply. The provider parses the entry as a service account key, signs the JWT bearer assertion, exchanges it at the key's token_uri (HTTPS only) for a cloud-platform access token, and returns the token in place of the key. The service account's IAM roles decide what the token may do.

Tokens are cached per key contents and handed out while at least fifteen minutes remain. The gateway caches a fetched credential for five minutes per actor, so a token returned with less than that left would be used after it expired; the margin keeps the two caches apart and still exchanges a key about once every 45 minutes of an hour-long token. Concurrent fetches of one key share a single exchange, and a rotated key is exchanged on its next fetch. A Secret that is not a service account key, or a key Google rejects, fails with FAILED_PRECONDITION naming the reason; an unreachable token endpoint fails with UNAVAILABLE. Neither the key nor the token is logged.

The Helm chart and the agentgateway kustomize component route the new authority to the provider on both the HTTPS and HTTP routes. agentgateway matches the URI authority exactly against that list, so a URI naming the new authority is denied until the entry is present. The Envoy data plane's --credential-provider-name flag names one provider and is unchanged; the docs say so. golang.org/x/oauth2 becomes a direct dependency; it was already vendored.

Not included: a case in the credentials e2e suite, which would need an in-cluster stand-in for Google's token endpoint with a certificate the provider trusts. The unit tests cover the exchange against a TLS stand-in instead.

Testing:

• go test -race ./cmd/credential-provider/...: exchange, caching, refresh ahead of the gateway cache, shared concurrent exchange, key rotation, error mapping (non-key Secret, user credential, plaintext token endpoint, corrupt private key, rejected assertion, endpoint failure, short-lived token, missing expiry), denial before any lookup, both authorities on both gateway routes in the chart and kustomize renders.

• golangci-lint (0 issues), boilerplate headers, go mod tidy and go mod vendor produce no further change, hack/render-manifests.sh --check passes.

• By hand, not committed: with a real service account key the exchanger minted a token from Google's token endpoint, served the second call from cache, and Vertex AI accepted the token for a Claude Sonnet 4.5 request (HTTP 200).

• Tests pass

• Appropriate changes to documentation are included in the PR