What Is Workload Identity?

Quick answer
Workload identity is a platform-issued identity for a process, pod, or job, usually delivered as a short-lived token rather than a stored secret.
The platform attests the workload first — which namespace, which service account, which repository, which cloud role — and then issues credentials scoped to that identity.
It replaces long-lived cloud keys in CI and Kubernetes, which removes the most commonly leaked credential type from the deploy path.
Setup is a trust relationship: the issuer’s metadata, the subject that is allowed, and the audience the token is valid for.
A misconfigured trust policy is the new risk: a subject pattern that is too broad lets another workload assume the role.

What is workload identity?

Workload identity is a way for a process to prove what it is and receive a credential for that identity without carrying a long-lived secret. The process asks a local platform component — a Kubernetes service account token issuer, a cloud metadata service, a CI provider’s OIDC endpoint — and the platform checks the workload’s attributes before issuing a short-lived token.

The token is then exchanged for access: a cloud role, a database session, or an API call. The application never stores a key. What it stores is a reference to the identity it should run as, which is configuration rather than a secret.

How does workload identity federation work?

The workload’s platform acts as an identity provider and signs a token with claims: issuer, subject, audience, and sometimes custom attributes. The receiving cloud or service is configured to trust that issuer, and to allow a specific subject to assume a specific role. When the workload presents the token, the receiver verifies the signature and the claims, then issues temporary credentials.

The subject is the critical field. In GitHub Actions it encodes the repository, branch, and environment; in Kubernetes it encodes the namespace and service account. A trust policy that matches on a loose prefix rather than an exact subject is how a workload identity setup becomes a confused-deputy problem.

# GitHub Actions: request an OIDC token and exchange it for a cloud role.
permissions:
  id-token: write   # required for the OIDC token
  contents: read
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/deploy-app
          aws-region: eu-west-1
      # No AWS_SECRET_ACCESS_KEY exists in this workflow.

Where should you use it?

Everywhere a static cloud key currently lives: CI deploy jobs, Kubernetes workloads that call cloud APIs, batch jobs, and serverless functions. The pattern is strongest in CI, because a repository secret with production credentials is both highly privileged and widely copied into forks, logs, and local environments.

It also fits multi-cloud and SaaS access, where a workload can exchange its platform token for a scoped credential in another system. The prerequisite is that the receiving service supports the issuer you have. When it does not, a secrets manager with short-lived dynamic credentials is the next best option.

What can go wrong?

The trust policy is the attack surface. A subject condition that accepts any branch, any pull request, or any repository with a matching name lets an attacker obtain the role. So does an audience that is not checked, or a role that is assumable by a federated identity from a tenant you do not control.

The second failure is scope. Teams often replace a broad static key with an equally broad role because the migration is easier. The benefit is that the credential expires; the risk that it can delete the database remains. Narrow the role in the same change, and log the assume-role events so unexpected issuance is visible.

Where this bites vibecoders
An AI assistant deploying to AWS will write a workflow with AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY in repository secrets, because that is the pattern in most examples. Replacing it with an OIDC role is a small, well-documented change that removes two long-lived production credentials from the repository, and it is usually the highest-value security edit available.

Where AI coding assistants get this wrong

Keeping long-lived cloud keys in CI because the OIDC setup looks complicated.
Matching the trust policy on a repository name prefix instead of the full subject.
Granting the assumed role administrator access to avoid permission errors.
Forgetting the id-token: write permission, then disabling OIDC when it fails.
Trusting tokens from any audience rather than the specific service.
Not logging assume-role events, so misuse is invisible.

Checklist

Inventory static cloud keys used by CI and workloads.
Configure the platform’s OIDC issuer as a trusted identity provider.
Restrict the trust policy to the exact subject and audience.
Scope the role to the resources the workload actually needs.
Remove the static keys after the first successful deploy.
Alert on unexpected assume-role activity.

FAQ

Is workload identity the same as a service account?

The service account is the identity; workload identity is the mechanism that issues short-lived credentials for it. In Kubernetes, a pod runs as a service account and receives a projected token for that account, which can then be exchanged for cloud access. The account persists; the credential does not.

Does workload identity eliminate secrets entirely?

It eliminates the static cloud credential, not every secret. Application secrets such as third-party API keys and encryption keys still need a store. What changes is that the credential used to reach the store can itself be short-lived, so the blast radius of a compromise is smaller.

What is the difference between OIDC and SPIFFE?

Both attest workload identity. OIDC federation is typically used between a platform and a cloud provider, with a signed JWT. SPIFFE is a standard for issuing and verifying workload identities, usually with X.509 certificates, across services. They solve the same problem at different layers and are sometimes used together.

Can I use workload identity outside Kubernetes and CI?

Yes, wherever the compute platform can attest the workload and expose a token: cloud VMs with instance roles, serverless functions with execution roles, and some container platforms. The principle is the same — the platform knows what is running and issues a credential for it, so the application does not carry one.