- Metadata server identity token: Compute Engine, Cloud Run, Cloud Functions, App Engine and GKE pods with an attached Google service account request a Google-signed ID token.
- Google Kubernetes Engine (GKE): a pod uses a projected Kubernetes service account token issued by the cluster.
Metadata server identity tokens
Set up the service account
Create a Google service account for the workload and attach it to the VM, Cloud Run service or function. Do not create a service account key.Get and inspect a token
From the resource, request an ID token with the Reducto audience:sub is the service account’s unique numeric ID. If you delete a service account and create one with the same email, the new one gets a new ID. Find it with gcloud iam service-accounts describe reducto-client@acme-payments.iam.gserviceaccount.com --format='value(uniqueId)'.
Configure Reducto
In Studio, open Settings > Workload identity and create a provider with the Google Cloud preset:
Add a mapping for the service account:
Always match
sub. Every Google account can get a token with issuer https://accounts.google.com and your audience, so a mapping without sub is not safe. The email claim is present only when the token is requested with format=full, so match on it only if your token source requests that format.
Call Reducto
gcp_id_token_provider(audience=...) in Python and gcpIdTokenProvider({ audience }) in Node.js set the audience. It defaults to https://platform.reducto.ai.
Google Kubernetes Engine (GKE)
GKE pods can use either token source:- If the pod uses GKE Workload Identity Federation with a Google service account, the metadata server returns Google ID tokens. Follow the metadata server steps.
- Otherwise, use a projected Kubernetes service account token, as below.
Add a mapping with
sub = system:serviceaccount:payments:reducto-client. Then use k8s_service_account_token_provider("/var/run/secrets/reducto/token") (Python) or k8sServiceAccountTokenProvider("/var/run/secrets/reducto/token") (Node.js), as shown in the Kubernetes guide.
Google Cloud best practices
- Use one Google service account per workload, and match its
sub. - Never download service account keys for this flow. The metadata server needs none.
- Keep production and non-production workloads in separate projects with separate service accounts and mappings.
- Review mappings when you delete or recreate service accounts. A recreated account has a new
sub.