Workload identity

Retire the long-lived secret.

Keyless workload identity for Kubernetes and CI: workloads exchange the token their platform already signs for a short-lived HelixIAM token. No long-lived secrets.

Book a technical demo Request a sandbox

What you get

Keyless by federation

Trust an external issuer once. Kubernetes service-account tokens and CI pipeline tokens are verified against that issuer's keys.

Kubernetes projected service-account tokens
CI platforms that issue OIDC tokens
Nothing stored in the pipeline

Bound to real roles

A federated workload is bound to an application, so its token carries exactly the roles that application should have.

Issuer, subject and audience must all match
One generic error on any mismatch
Short-lived tokens

Harder to replay

Pair workload identity with sender-constrained and audience-restricted tokens.

Sender-constrained tokens with DPoP
Audience-restricted tokens with resource indicators
Managed in the console and through the admin API

One exchange, no stored secret.

A CI job presents its platform-signed token and receives a short-lived HelixIAM token.

workload identity · JWT exchange200 OK

Request · CI job presents its platform token

POST /realms/acme/workload-identity/token
grant_type=urn:ietf:params:oauth:grant-type:token-exchange
subject_token=eyJ…  # signed by the CI platform

Issued token · decoded

{
  "sub": "service-account-deploy-pipeline",
  "realm_access": { "roles": ["deployer"] },
  "exp": 1798732800,
  "iss": "https://id.acme.example/realms/acme"
}

issTrusted issuer, subject and audience must all match, or the request is refused.
expShort-lived, bound to the roles of one application.
secretNothing to store or rotate in the pipeline.

Illustrative values · workload identity federation

See keyless workload identity in your pipeline.

Request a sandbox or book a technical demo.

Book a technical demo Request a sandbox