Workload & Service Identity: Beyond Static Secrets

Workload and Service Identity

In most systems, non-human identities far outnumber people: microservices calling each other, batch jobs reading buckets, CI pipelines deploying to production, functions writing to queues, devices reporting telemetry. Historically each got a static secret — an API key, an access key pair, a database password — copied into environment variables, configuration files, and CI settings, rarely rotated and often over-privileged. Those secrets leak through logs, repositories, and images, and they are a leading cause of cloud breaches.

Workload identity replaces static secrets with identities the platform can prove: a pod's service account, a VM's attached role, a CI job's signed token. Credentials are issued automatically, short-lived, scoped to one purpose, and never stored by humans. The goal is simple to state: no long-lived secrets for workloads, and every workload with exactly the permissions it needs.

TL;DR

Give each workload its own identity; never share credentials between services.
Prefer platform-issued, short-lived credentials: cloud roles for compute, Kubernetes projected tokens, managed identities.
Federate CI/CD to cloud providers with OIDC instead of storing access keys in pipeline secrets.
Use SPIFFE/SPIRE or a service mesh for cross-platform service identity and mutual TLS.
For APIs, use OAuth client credentials with narrow scopes, and token exchange when calling on behalf of others.
Keep an inventory of non-human identities with owners, apply least privilege, and remove unused credentials.

Quick Example

A GitHub Actions deployment that obtains short-lived AWS credentials through OIDC — no stored keys. The IAM role trusts only one repository's production environment:

Inside Kubernetes, a pod receives an audience-bound token that expires within an hour, for calling an internal API:

Core Concepts

Why Static Secrets Fail

See Secret Rotation and Leak Response and Secrets Management.

Platform-Issued Identities

The platform attests where the workload runs and issues credentials automatically; nothing long-lived is stored. See AWS IAM.

Federation and Token Exchange

OIDC federation lets a workload present a signed identity token from one system (a CI provider, a Kubernetes cluster) to another (a cloud provider, an API), which validates the issuer, audience, and subject claims before issuing its own short-lived credentials. OAuth token exchange (RFC 8693) converts one token into another with different audience or scopes, including acting on behalf of a user. Trust policies must pin claims tightly — repository, branch or environment, service account — not just the issuer.

SPIFFE, SPIRE, and Mutual TLS

SPIFFE defines a standard workload identity (spiffe://example.org/ns/payments/sa/api) and short-lived identity documents (X.509 certificates or JWTs called SVIDs). SPIRE issues them after attesting workloads through platform evidence. Services then authenticate each other with mutual TLS, independent of network location — the foundation of zero trust between services. Service meshes provide the same model inside Kubernetes. See Istio.

Service-to-Service Authorization

Authentication says who a workload is; authorization decides what it may do. Use the OAuth client credentials flow for service access to APIs with narrow scopes, mesh authorization policies for service-to-service calls, cloud IAM policies scoped to specific resources, and Kubernetes RBAC for cluster API access. See OAuth Client Credentials and Kubernetes RBAC.

Governing Non-Human Identities

Inventory: every service account, role, API client, and key with an owner, purpose, and environment.
Lifecycle: create identities with workloads and remove them when workloads are retired. See Identity Lifecycle Management.
Least privilege: start from no permissions and add what is used; tools that analyze access logs suggest tighter policies.
Detect drift: unused credentials, keys older than policy allows, identities with admin rights, and access from unexpected locations.
Remaining secrets: where static secrets cannot yet be removed — third-party APIs, legacy systems — store them in a secrets manager, scope them narrowly, and rotate automatically.

Best Practices

One Identity per Workload per Environment

Separate identities for each service in each environment make permissions precise, audit logs meaningful, and revocation surgical.

Pin Trust Policies Precisely

Restrict federated trust to specific repositories, branches, environments, namespaces, and service accounts, and require the correct audience.

Prefer Short Lifetimes

Choose token lifetimes measured in minutes or hours, with automatic refresh, so leaks expire quickly.

Audit What Workloads Actually Use

Compare granted permissions with access logs regularly and remove what is unused.

Common Mistakes

Long-Lived Cloud Keys in CI

Overly Broad Federation Trust

Shared Service Accounts

FAQ

What is workload identity?

A way for software workloads — services, jobs, pipelines, functions — to authenticate using identities issued and attested by their platform, with short-lived credentials, instead of static secrets stored in configuration.

How does GitHub Actions OIDC work with AWS?

The workflow requests a signed OIDC token from GitHub describing the repository, branch or environment, and workflow. AWS validates it against an IAM role's trust policy and returns temporary credentials, so no access keys are stored in GitHub.

What is SPIFFE?

The Secure Production Identity Framework for Everyone, a standard for naming workloads and issuing them short-lived identity documents. SPIRE is its reference implementation, which attests workloads and issues certificates or tokens.

Should services use API keys?

Avoid long-lived API keys where better options exist: platform workload identities, OAuth client credentials with short-lived tokens, or mutual TLS. Where keys are unavoidable, scope them narrowly, store them in a secrets manager, and rotate them automatically.

How do I find unused service credentials?

Use cloud and identity provider reports of last-used times, access analyzers, and audit logs to identify credentials and permissions that have not been used recently, then remove or narrow them.