Kubernetes workload identity links ServiceAccounts to short-lived tokens that recipients verify and authorize, enabling safer access to cloud and cluster services.
Workload identity is a trust system, not a token mount
A Kubernetes workload can need to reach object storage, a vault, another service, a message queue, the Kubernetes API or a cloud provider. In each case, the receiving system has to establish which workload is making the request—and decide whether that identity should be trusted. That’s more than a credential problem. A ServiceAccount names an identity inside the cluster; a signed, short-lived token represents it to another system. The recipient must verify the signature, trust the issuer, check that the token was meant for it and apply its own authorization rules. If any link fails, a valid-looking workload can still be denied.
The ServiceAccount names the workload
A ServiceAccount is a non-human identity represented by an object in the Kubernetes API. It belongs to a namespace, so it isn’t a universal identity across the cluster. If a Pod doesn’t specify one, Kubernetes assigns the namespace’s default ServiceAccount. The ServiceAccount is not itself the credential. It identifies the workload; a separately issued credential represents that identity and can have its own lifetime, audience and binding information. Different Pod instances can use the same ServiceAccount over time while receiving short-lived credentials. That separation avoids making a permanent secret the workload’s enduring identity. Authentication and authorization remain distinct. Authentication establishes who is making a request. Authorization determines what that identity may do. Kubernetes uses RBAC and other authorization mechanisms to decide what a ServiceAccount can access, and recommends granting it only the permissions its workload needs.Tokens have a life cycle
Modern Kubernetes clusters generally issue short-lived ServiceAccount tokens through the TokenRequest mechanism and expose them through projected volumes. This is the standard approach Kubernetes has supported since version 1.22, replacing the older pattern of storing long-lived ServiceAccount tokens in Secrets. The kubelet obtains a time-bound token through the TokenRequest API, makes it available to the Pod’s containers and refreshes it before expiration. The documented default lifetime is one hour, though administrators can configure related limits and workloads can request different expiration periods within those limits. That rotation has a practical consequence: an application can’t assume the credential it read at startup will remain valid indefinitely. It needs to reload the projected token when Kubernetes replaces it. A workload that fails to do so may lose access even when its ServiceAccount and permissions are otherwise correct.A signed token still needs the right audience
A ServiceAccount token is a signed JSON Web Token (JWT). Its claims can include the issuer (`iss`), subject (`sub`), audience (`aud`), expiration (`exp`), issue time (`iat`), token ID (`jti`) and Kubernetes-specific details tied to the ServiceAccount, Pod or other objects. These claims shape the trust decision. The issuer identifies who created the token; the subject identifies the represented identity; the audience says which recipient or security domain the token is meant for; and the expiration limits its lifetime. Kubernetes can also bind a token to objects such as a Pod. A valid signature alone doesn’t make a token appropriate for every service. If a Pod requests a token for a vault, for example, the vault should check that the audience matches its expectations. Another API should reject a token intended only for the vault. Without that check, a credential could be accepted outside its intended trust domain. The signature shows that a trusted issuer created the token; audience validation helps establish whether the recipient should accept it.Signing keys are part of the infrastructure
Kubernetes configures a ServiceAccount token issuer and signing key. The API server maintains verification material, while external verifiers need trusted issuer information and the corresponding public verification material. The private key signs tokens; a verifier uses public material to check that the token came from a trusted issuer and hasn’t been changed. That makes workload identity part of the organization’s cryptographic trust infrastructure. Issuer configuration, signing keys, verification material and rotation procedures all need ownership. The application may never handle a private signing key, but it still depends on the systems that issue and validate its credentials.Identity doesn’t grant permission
The same distinction applies outside Kubernetes. A cloud provider may successfully authenticate a ServiceAccount and still deny access to an object storage bucket if that identity lacks the required cloud-side permission. When access fails, the cause could sit anywhere along the chain: the Pod’s ServiceAccount, token issuance, kubelet delivery, audience, expiration, issuer trust, application token reload or the receiving system’s authorization policy. Understanding the protocol helps explain both where workload identity succeeds and where it can break.By Michael Carter · October 26, 2026
Topics: Contributed Content, Kubernetes, Social - Facebook, Social - LinkedIn, Social - X, Topics.
Tags: Cloud IAM, cloud native security, identity and access management, JWT Authentication, kubernetes, Kubernetes RBAC, Kubernetes security, Kubernetes Workload Identity, OIDC Federation, PKI, Pod Security, ServiceAccounts, Short-Lived Credentials, SPIFFE, TokenRequest API, Workload Identity Federation, zero-trust.
Federation is where workload identity gets complicated
Replacing a static cloud key with workload identity changes how a workload proves who it is. It doesn’t decide what that identity is allowed to do. Authorization still needs its own design. That distinction matters when a Kubernetes workload calls a cloud service. A Kubernetes ServiceAccount belongs to Kubernetes; AWS, Azure and Google Cloud each have separate identity and permission systems. Federation connects those domains, so developers don’t have to store long-lived cloud credentials in Pods. The Kubernetes token serves as evidence of a workload’s identity. The external provider checks its issuer, signature, audience and claims, then maps the verified identity according to its trust configuration. That’s the same broader problem explored in Cloud Native Now’s coverage of [machine and workload identity](https://cloudnativenow.com/social-facebook/machines-and-workloads-need-identities-too-not-just-humans/): machines and workloads need security controls tied to their own identities, rather than borrowed from human accounts. A simplified federation flow: —————— The key point is that a Kubernetes token doesn’t turn into a cloud credential by itself. The external provider must trust the Kubernetes issuer and define how Kubernetes identities map to its own permissions. The underlying JWT and OpenID Connect (OIDC) mechanisms may be standard; the policy that decides which namespace, ServiceAccount or workload can assume which external identity is where implementation gets difficult.OIDC sets the trust boundary
OIDC gives external systems a standard way to discover an issuer and validate its identity tokens. Kubernetes can publish discovery information for ServiceAccount tokens, allowing external systems to treat Kubernetes as an identity provider. Kubernetes documentation describes this as enabling external relying parties to federate with Kubernetes-issued identities. That doesn’t mean a verifier should accept a JWT because it recognizes a ServiceAccount name. It needs a trust configuration that identifies the issuer and provides what’s needed to validate the signature. If the issuer changes, or relying parties can’t discover updated verification keys, federation may break while the workload itself still looks healthy. The architecture depends on two trust domains: Kubernetes Trust Domain OIDC External Trust Domain Both cryptographic verification and authorization mapping must succeed. Either can block access.Tokens follow workload lifecycles
When Kubernetes authenticates a ServiceAccount token, the API server checks more than its signature. Kubernetes documents checks for expiration, object references, current validity and audience, alongside signature verification. Object binding connects a token to a Kubernetes object, such as a Pod. Kubernetes says a bound token can become invalid when that object is deleted. The credential can therefore expire with the workload instance instead of persisting as an independent secret. Say a Deployment replaces a Pod. The replacement may use the same ServiceAccount, but the old Pod’s credential doesn’t necessarily remain valid for the new instance. The logical identity can stay constant while its credentials and bindings change. That separation is central to short-lived workload credentials. A Deployment might use the `payments-api` ServiceAccount across its lifetime. Individual Pods can still receive different temporary credentials: v v Pod A Pod B v v Token A Token B This makes rolling deployments easier to reason about: authorization can stay attached to the ServiceAccount while credentials are issued and replaced as Pods start, stop and rotate. A stolen, short-lived token restricted to an audience and workload context also has less value than a permanent cloud key stored in a Kubernetes Secret.Identity isn’t the same as a Secret
Secrets store sensitive data: passwords, API keys, certificates, tokens and other credentials. Workload identity establishes who a workload is, giving another system a basis for issuing or accepting credentials. Kubernetes still supports manually created, long-lived ServiceAccount token Secrets. The project recommends TokenRequest instead, because time-limited credentials reduce the exposure created by persistent tokens. Secrets remain useful; the point is that an application’s need to authenticate doesn’t automatically mean its identity should be a static secret.ServiceAccounts and SPIFFE serve different needs
ServiceAccounts are one way to give workloads identities, not a complete identity standard for cloud-native systems. SPIFFE defines a broader framework. A SPIFFE identity can be carried in an SVID, including an X.509 certificate, for mutual TLS and other authentication. Kubernetes documentation identifies SPIFFE-based options for Pods, including the SPIFFE CSI driver, which provides X.509 certificate pairs. ServiceAccount tokens fit naturally when the target understands Kubernetes or OIDC federation. SPIFFE can suit organizations that need a common workload identity across Kubernetes clusters, service meshes, virtual machines and other infrastructure. The shared principle is straightforward: workloads need identities that can be verified cryptographically and mapped to permissions. That’s also why PKI remains part of the conversation. X.509 and mTLS bring certificate issuance, trust anchors, private keys, rotation and lifecycle management into the identity system. Cloud Native Now has covered [PKI challenges in Kubernetes](https://cloudnativenow.com/topics/cloudnativedevelopment/kubernetes/pki-for-kubernetes-are-you-set-up-for-security-and-scale/), especially as environments become more distributed. The mechanics also connect to [client certificate authentication](https://comparecheapssl.com/what-is-the-difference-between-a-client-certificate-and-server-certificate/), where a client proves it holds the private key associated with its certificate. At first glance, Kubernetes workload identity looks like a JWT and OIDC problem. Larger environments often combine several systems: signed JWTs for ServiceAccount authentication, OIDC federation for cloud access, X.509 certificates from a service mesh, mTLS between services, and certificates or keys for external systems. That creates a wider chain of dependencies: v v v Kubernetes JWT OIDC Federation SPIFFE v v v Kubernetes API Cloud IAM mTLS Each mechanism brings its own trust relationships and lifecycle. A broken issuer, signing key, certificate authority, discovery endpoint or permission mapping can look like an ordinary application authentication failure. For enterprises running large Kubernetes estates, identity is security infrastructure, not just a configuration setting.Failures cross team boundaries
A Pod can run normally while authentication to an external service fails. Its ServiceAccount exists, RBAC appears correct and the token file is readable, yet the receiver may reject the request because it doesn’t trust the issuer, expects a different audience, can’t validate the signing key, sees an expired token or has a different identity-to-permission mapping. The dependency chain often crosses teams: platform engineering owns Kubernetes, security owns identity policy, cloud engineering manages IAM, and application teams handle token consumption and reload behavior. Without clear ownership, each component can look healthy in isolation while teams investigate the same failure from different ends.Design the identity boundary first
Start by deciding which workloads share an identity and which need separate ones. The boundary might follow a namespace, application, environment, tenant or another organizational division. That decision should come before choosing how credentials reach a Pod. Then set credential lifetimes. When the target supports them, short-lived tokens are generally preferable to permanent credentials. Kubernetes provides TokenRequest and projected volumes for this approach, with the kubelet automatically refreshing tokens. Audience restrictions also belong in the security design: a token issued for one service shouldn’t automatically work as a general credential elsewhere. Federation still requires least-privilege authorization. A cloud IAM role, Kubernetes RBAC role or external resource permission should match the workload’s actual needs, not simply inherit a human administrator’s access. Finally, treat issuers, signing and verification keys, OIDC discovery, certificate authorities and workload credentials as production infrastructure with their own lifecycles. That connects directly to the challenge of [managing PKI at Kubernetes scale](https://cloudnativenow.com/topics/cloudnativedevelopment/kubernetes/pki-for-kubernetes-are-you-set-up-for-security-and-scale/): identity and certificate systems can become distributed dependencies across a platform. Workload identity is often summarized as removing static credentials from Pods. That’s a real benefit, but it describes the result, not the machinery behind it. Kubernetes establishes an identity through a ServiceAccount, issues and delivers a signed credential, and provides ways to validate its claims. External systems can then trust that identity through federation. Short lifetimes, audience limits and object bindings can make this design safer than storing permanent credentials in Pods. They also mean access depends on issuer settings, signing keys, kubelet behavior, OIDC discovery, external IAM mappings and authorization policy. The application may see a token file. The platform is running a trust system. Once other infrastructure relies on Kubernetes as an identity provider, that system becomes part of the security architecture for the wider cloud-native environment.Frequently Asked Questions
What does Kubernetes workload identity do?
It lets applications in Pods authenticate with ServiceAccounts and signed tokens. That gives workloads access to Kubernetes APIs and external services without storing permanent credentials in the application.
How does OIDC federation connect Kubernetes workloads to external services?
An external provider, such as a cloud IAM service, checks a Kubernetes-issued ServiceAccount token’s issuer, signature, audience and claims. It can then map the workload to an external identity with defined permissions. The token carries proof the provider can verify; the resulting access still depends on how those permissions are configured.
Why use short-lived ServiceAccount tokens instead of static credentials?
A stolen token has less value if it expires quickly. Tokens can also be limited to an audience and tied to a specific workload object, while the kubelet handles automatic rotation. Those controls narrow exposure, though they don’t remove the need to configure access carefully.
Discussion
Sign in to join the discussion.