How-to · Keyless GCP workloads

GCP access for workloads.
No service account keys.

Workload Identity Federation lets anything running outside GCP (an on-prem service, a CI/CD agent, an app in another cloud) reach Google APIs with a short-lived token issued by Monosign. The downloadable service account key, the one that leaks into repos and backups, disappears from the architecture.

Start free trial →Open the docs

OIDC · client_credentials
Closed-network option (inline JWKS)
Verified end to end

Walkthrough

From client credentials to GCP API call.

Five steps. The token chain does the rest at runtime.

01
Prepare Monosign: certificate, issuer, API application
Configure an organization signing certificate and pin the global JWT issuer: Google validates signatures against your JWKS and rejects tokens whose iss varies by hostname. Then create an API-type application with an OIDC key; its Client Id and Secret are the workload’s credentials.
Tip — Without a pinned certificate, Monosign generates an ephemeral signing key on every restart and the federation silently breaks.
02
Set the audience on the OIDC key
Enter the full resource name of the GCP provider (https://iam.googleapis.com/projects/PROJECT_NUMBER/…/providers/PROVIDER_ID) in the key’s Audience field. Google requires the token’s aud claim to match the provider exactly, and client_credentials tokens carry no aud until this field is set.
Tip — You need the project number, not the project ID; gcloud projects describe shows it.
03
Create the workload identity pool and provider
On the GCP project, create a workload identity pool and an OIDC provider for it. Two models work: a public issuer that Google discovers over the internet, or, unique to this scenario, a closed-network setup where you upload Monosign’s JWKS inline and the issuer never needs to be reachable from outside.
Tip — The inline-JWKS model means an air-gapped or on-prem-only Monosign can still federate into GCP.
04
Bind a service account for impersonation
Create a service account with the roles the workload actually needs, and grant the pool identity workloadIdentityUser on it. The workload’s federated token then exchanges for short-lived service account credentials: permissions stay on the service account, identity stays in Monosign.
05
Wire the token chain into the workload
At runtime the workload requests a Monosign token via client_credentials, exchanges it at Google STS for a federated token, and calls generateAccessToken for the service account. Google’s client libraries drive the whole chain from one credential-configuration JSON: no code changes beyond pointing at the file.
Tip — Keep token lifetimes short; Google rejects federated tokens that live longer than 24 hours, and the 5-minute Monosign default is fine.