Cybersecurity glossary
What is Workload Identity?
Learn what workload identity is, how pods and CI federate into Cloud IAM without access keys, and how mis-bound service accounts recreate standing privilege.
Definition
Workload identity is a pattern that gives applications, pods, functions, and CI jobs their own short-lived cloud credentials by federating a platform identity (Kubernetes service account, environment identity, or OIDC token) into Cloud IAM—instead of distributing long-lived access keys.
Why workload identity matters
Static access keys in CI variables and Kubernetes Secrets are long-lived, copyable, and rarely rotated. They also tend to be shared: one key for “the app,” used by every replica and every environment.
Workload identity binds cloud IAM to the thing that is actually running. The credential expires, the trust is cryptographic, and a compromised frontend should not present the same role as the backup job.
How a pod gets a cloud role
The pod runs as a service account
A dedicated Kubernetes SA, not default, with automount only if needed.
The platform issues a projected token
An OIDC JWT identifies the namespace, SA, and often the pod.
Cloud IAM trusts the issuer
A trust policy names the cluster OIDC provider, audience, and subject.
The SDK exchanges the token
STS, Workload Identity Federation, or Azure federated credentials return short-lived cloud keys.
API calls use that role only
The node IMDS role is unused. IAM still must be least privilege for this SA.
Where workload identity should show up
Application pods
Read one bucket prefix, publish to one queue—never the node’s admin-like profile.
CI and GitOps
OIDC from the pipeline to a deploy role scoped to one repo and environment.
Functions and jobs
Each function’s execution role is already a form of workload identity—keep it unique.
Operators and CSI
Controllers that talk to cloud APIs need their own mapped roles, not cluster-admin plus IMDS.
Trust-policy pitfalls
| Pitfall | What goes wrong | Tighten |
|---|---|---|
| Subject: * | Any SA in the cluster can assume the role | Pin system:serviceaccount:ns:name |
| Shared SA across apps | The weakest app inherits the strongest permissions | One SA and one IAM role per workload |
| Developers can annotate any SA | A namespace admin binds their SA to a privileged role | Admission control on IAM annotations and RoleBindings |
| CI trust on the whole org | A forked or sibling repo deploys to production | Pin repository, ref, and environment claims |
Workload identity checklist
- Give each application a dedicated service account mapped to a dedicated IAM role.
- Pin OIDC trust to issuer, audience, and subject; never a wildcard subject in production.
- Keep application pods off the node instance role (IMDS hop limit 1 plus NetworkPolicy).
- Restrict who can create service accounts and who can set federation annotations.
- Use OIDC for CI; delete long-lived cloud access keys from pipeline variable stores.
- Log AssumeRoleWithWebIdentity (or equivalent) and alert on unexpected subjects.
- Still retrieve third-party secrets from a manager using this identity—do not revert to static cloud keys.
- Review mapped roles like any other Cloud IAM: no wildcards, no standing admin.
The practical takeaway
Workload identity federates a platform identity into Cloud IAM so pods, jobs, and pipelines receive short-lived roles instead of copied access keys.
The cryptography only helps if the trust policy names a specific workload. A wildcard subject plus a powerful role is the old shared key, with extra steps.
Related security terms
Cloud IAM
The policies the federated workload principal is evaluated against.
Kubernetes RBAC
Controls who can bind a service account that maps to a powerful cloud role.
Instance Metadata Service (IMDS)
The node identity path that workload identity is meant to replace for applications.
Secrets Manager
Workloads still retrieve third-party secrets; they should not store cloud API keys.
CI/CD Pipeline
Pipelines should federate via OIDC rather than hold cloud access keys.
Frequently asked questions
What is workload identity in simple terms?
The application proves “I am this pod or this CI job” to the cloud, and the cloud issues a short-lived role. Nobody pastes an access key into a Kubernetes Secret.
How is this different from an instance profile?
An instance profile is shared by everything on the VM. Workload identity is per service account or job, so a frontend pod need not inherit the node’s ability to attach disks or read all buckets.
What is IRSA or GKE Workload Identity?
Provider implementations of the same idea: a Kubernetes service account is annotated or mapped to a cloud IAM role, and the token exchange happens via OIDC.
Does workload identity remove the need for a secrets manager?
It removes static cloud keys. Third-party APIs and some databases still need stored credentials, retrieved using the workload’s IAM.
What is the main misconfiguration?
Mapping a broad IAM role to a service account that any namespace can use, or letting developers create service accounts that federate to admin roles.
Can CI use workload identity?
Yes. GitHub Actions, GitLab, and others can present OIDC tokens that a cloud trust policy accepts for a deploy role—scoped to that repository and environment.
What happens if the OIDC trust is too wide?
Any token that matches the issuer and a loose subject claim can assume the role. Pin audience, subject, and repository claims the way you would pin an IAM principal.
References
Explore authoritative guidance and frameworks related to workload identity.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.