What is Workload Identity?
A workload identity identifies software that makes a request, such as a service, job, pipeline, or agent application. The workload presents a credential that a receiving service can validate. The identity needs a clear owner, scope, audience, lifetime, and rotation process. It is distinct from the identity of a human user, even when a workload acts for that user.
Why it matters
Private services receive requests from people and software. A distinct workload identity lets policy limit automation without sharing a human password or treating every machine as one trusted network peer.
How it works
- Assign a stable identity to the workload and record the system and team that own it.
- Issue a credential with a narrow audience, scope, lifetime, and storage boundary. Send it only to the intended protected service.
- Validate the credential at the access boundary, apply least-privilege policy, log the decision, and rotate or revoke the credential through an owned process.
Example
A deployment pipeline uses one workload credential to call a protected release API. The route policy permits only that pipeline identity. The release API still verifies the requested environment and operation.
Pomerium boundary
Pomerium Enterprise and Pomerium Zero service accounts can authenticate machine-to-machine requests to protected services. A service account can have its own identity or impersonate a directory user. Namespace scope, route policy, credential storage, and the downstream service remain separate controls.
Limits and non-claims
- A workload identity does not prove which human requested an action unless the design preserves separate delegation context.
- A long-lived bearer credential can be copied and replayed if its storage boundary fails.
- Pomerium service accounts are Pomerium Enterprise and Pomerium Zero features.
- A Pomerium service account is not a SPIFFE implementation and does not replace workload isolation or downstream authorization.
Evaluation checklist
- Identify whether the caller is an autonomous workload or an application acting for a user.
- Limit each credential to the required audience, namespace, service, and lifetime.
- Store, rotate, and revoke workload credentials through an owned secret lifecycle.
- Preserve user delegation separately when the downstream action must remain attributable to a person.
