Workload Identity Practices

Workload Identity Practices Defakto Security

arndts.ietf@gmail.com

Zscaler

yrosomakho@zscaler.com

Applications and Real-Time Workload Identity in Multi System Environments Internet-Draft This document describes industry practices for providing secure identities to workloads in container orchestration, cloud platforms, and other workload platforms. It explains how workloads obtain credentials for external authentication purposes, without managing long-lived secrets directly. It does not take into account the standards work in progress for the WIMSE architecture and associated protocols.

Introduction Just like people, workloads need identifiers and associated credentials to authenticate with other systems, such as databases, web servers, or other workloads. The challenge for workloads is to obtain a credential that can be used to authenticate with these resources without managing secrets directly, for instance, an OAuth 2.0 access token. The common use of the OAuth 2.0 framework in this context poses challenges, particularly in managing credentials. To address this, the industry has shifted to a federation-based approach where credentials of the underlying workload platform are used to authenticate to identity providers, which in turn, issue credentials that grant access to resources. Traditionally, workloads were provisioned with static client credentials (e.g., passwords, API keys) and used the corresponding flow as described in to retrieve an OAuth 2.0 access token. This model presents a number of security and maintenance issues. Secrets need to be provisioned and rotated, which requires either automation to be built, or periodic manual effort. Secrets may be stolen and used by attackers to impersonate the workload. Flows outside of the OAuth 2.0 framework (such as direct API keys or HTTP basic authentication) suffer from the same issues. Instead of provisioning secret material to the workload, one solution to this problem is to attest the workload by using its underlying platform. Many platforms provision workloads with a credential, such as a JWT . Cryptographically signed by the platform's issuer, this credential attests the workload and its attributes. illustrates a generic pattern that is seen across many workload platforms, more concrete variations are found in .

1) The platform issues a credential to represent the workload identity after verification of workload environment and attributes. The way this is achieved varies by platform, for instance, the credential can be pushed to the workload or pulled by the workload. A workload may obtain multiple credentials from the platform, each with its own audience and lifetime, tailored to the specific resource or Identity Provider it needs to interact with. See and for more details and security implications.
A) The credential can give the workload direct access to resources within the platform or the platform itself, for example to perform infrastructure operations.
B1) The workload uses a credential to federate to an Identity Provider. This step is optional and only needed when accessing outside resources. The Identity Provider validates the platform-issued credential, and in return, issues a new credential, such as an OAuth 2.0 access token, that the workload can use to access resources in the Identity Provider's domain.
B2) Using the credential obtained at step B1, the workload accesses resources outside of the platform.

Accessing different outside resources may require the workload to repeat steps B1) and B2), federating to multiple Identity Providers. It is also possible that step 1) needs to be repeated, for instance in situations where the platform-issued credential is scoped to accessing a certain resource or federating to a specific Identity Provider.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Delivery Patterns Credentials can be provisioned to the workload by different mechanisms, each of which has its own advantages, challenges, and security risks. The following section highlights the pros and cons of common solutions. Security recommendations for these methods are covered in .

Filesystem Filesystem delivery allows both container secret injection and access control. Many solutions find the main benefit in the asynchronous provisioning of the credentials to the workload. This allows the workload to run independently of the credentials update, and to access them by reading the file. Credential rotation requires a solution to detect soon-to-expire secrets as a rotation trigger. One practice is that the new secret is renewed before the old secret is invalidated. For example, the solution can choose to update the secret an hour before it is invalidated. This gives applications time to update without downtime. Because credentials are written to a shared filesystem, the solution is responsible for ensuring atomicity when updating them. Writes SHOULD be performed in a way that prevents workloads from observing a partially written file (for example by writing to a temporary file and renaming it atomically). Solutions SHOULD also perform a flush operation immediately after the update to minimize the chance of race conditions and ensure durability.

Local APIs In this pattern, the workload obtains credentials by communicating with a Local API exposed by the credential issuer. Implementations commonly use UNIX domain sockets (e.g., SPIFFE), loopback interfaces, or link-local "magic addresses" 169.254.169.254 commonly used for cloud provider Instance Metadata Services as the transport mechanism. Local APIs support re-provisioning of updated credentials, either on demand or through persistent connections that enable the issuer to push new credentials. This enables the use of short-lived, narrowly scoped credentials, improving security posture compared to long-lived secrets. The security of this approach relies heavily on network isolation to prevent unauthorized access to the Local API. In addition, the pattern requires client-side code that is specific to the exposed API, which may introduce portability challenges across platforms and providers. Further security considerations for Local APIs are discussed in .

Environment Variables Injecting the credentials into the environment variables allows for simple and fast deployments. Applications can directly access them through system-level mechanisms, e.g., through the env command in Linux. Note that environment variables are static in nature in that they cannot be changed after application initialization. While environment variables are a common delivery pattern, they are highly susceptible to leakage through logging, process inspection, error reporting, and other means. Filesystem delivery () or Local APIs () are therefore preferred, and environment variables MUST NOT be used for such credentials where the platform offers one of these alternatives. Some platforms offer no other delivery pattern; that case, along with the underlying security considerations, is discussed in .

Practices The following practices outline more concrete examples of platforms, including their delivery patterns.

Kubernetes In Kubernetes, machine identity is implemented through "service accounts" . Service accounts can be explicitly created, or a default one is automatically assigned. Service accounts use JSON Web Tokens () as their credential format, with the Kubernetes Control Plane acting as the signer. Service accounts serve multiple authentication purposes within the Kubernetes ecosystem. They are used to authenticate to Kubernetes APIs, between different workloads and to access external resources. This latter use case is particularly relevant for the purposes of this document. To programmatically use service accounts, workloads can:

Have the token "projected" into the file system of the workload. This is similar to volume mounting in non-Kubernetes environments, and is commonly referred to as "projected service account token".
Use the Token Request API of the control plane. This option, however, requires an initial projected service account token as a means of authentication.

Both options allow workloads to:

Specify a custom audience. Possible audiences can be restricted based on policy.
Specify a custom lifetime. Maximum lifetime can be restricted by policy.
Bind the token lifetime to an object lifecycle. This allows the token to be invalidated when the object is deleted. For example, this may happen when a Kubernetes Deployment is removed from the server. Note that invalidation is only detected when the Token Review API of Kubernetes is used to validate the token.
Obtain multiple tokens, each with its own customized audience and lifetime. For example, a workload may obtain one token audienced for the Kubernetes API server, another for an internal service, and yet another for federation with an external Identity Provider. Tokens SHOULD have a minimal set of audiences; see for more details and security implications.

To validate service account tokens, Kubernetes allows workloads to:

Make use of the Token Review API . This API introspects the token, makes sure it hasn't been invalidated and returns the claims.
Mount the public keys used to sign the tokens into the file system of the workload. This allows workloads to validate a token's signature without calling the Token Review API.
Optionally, a JSON Web Key Set is exposed via a web server. This allows external systems to validate Service Account Tokens independently, without requiring direct network access to, or credentials for, the Kubernetes Control Plane API.

Kubernetes workload identity in practice | API Server | | | | | | | | | +--------------+ | | +----+----+ ^ 1) request token | | | | 2) schedule +----+----+ | | | Pod |<------------+ Kubelet | | | | | +---------+ | | +-+-+---+-+ | | | | | +--------------+ | | | | | A2) access | | | | | | +--------------------->| Resource | | | | | | | | | | | +--------------+ | | | | | +---+-+-------------------------------------------+ | | | | +--------------+ B1) federate | | B2) access | | | +------------------------->| Resource | v | | +---------------------+ +--------------+ | | | Identity Provider | | | +---------------------+ ]]> The steps shown in are:

1) The kubelet is tasked to schedule a Pod. Based on configuration, it requests one or more Service Account Tokens from the Kubernetes API server, each scoped to its intended use, for example with a distinct audience.
2) The kubelet starts the Pod and, based on the configuration of the Pod, delivers the token(s) to the containers within the Pod.

Now, the Pod can use the tokens to:

A1) Access the Kubernetes Control Plane, using a token audienced for the API server, considering it has access to it.
A2) Access other resources within the cluster, for instance, other Pods, using a token audienced for the target resource.
B) Access resources outside of the cluster:
B1) The application within the Pod uses a Service Account Token audienced for the external Identity Provider to federate to that Identity Provider outside of the Kubernetes Cluster. This token SHOULD NOT be the same token used for steps A1 or A2. The Identity Provider validates the token and issues a new credential to the workload, such as an OAuth 2.0 access token.
B2) Using the credential issued in step C1, the application within the Pod accesses resources outside of the cluster.

As an example, the following JSON illustrates the claims contained in a Kubernetes Service Account token.

Example Kubernetes Service Account Token claims

Secure Production Identity Framework For Everyone (SPIFFE) The Secure Production Identity Framework For Everyone, also known as SPIFFE , is a Cloud Native Computing Foundation (CNCF) project that defines a "Workload API" to deliver machine identity to workloads. Workloads can retrieve identity credentials in one of two forms:

X509-SVID, a X.509 certificate containing the workload's SPIFFE ID in the Subject Alternative Name (SAN) URI field, along with the corresponding key pair.
JWT-SVID, a signed JWT containing the workload's SPIFFE ID in the "sub" claim.

The Workload API does not require clients to authenticate themselves. Instead, the API implementation identifies workloads by collecting contextual information from the environment, such as process attributes, kernel metadata, or orchestrator-provided labels. This out-of-band identification allows workloads to obtain their identity credentials without needing a pre-existing secret, avoiding the bootstrapping problem of requiring a credential to obtain a credential. Workloads may request multiple JWT-SVIDs, each with a distinct audience, to interact with different resources or Identity Providers. As with all patterns in this document, it is best practice to use a separate credential for each target; see for details. For validation, SPIFFE defines a "trust bundle" per trust domain. A trust bundle is a set of public keys encoded in JWK format that can be used to validate credentials. For JWT-SVIDs, the bundle contains signing keys identified by a "use" value of jwt-svid. For X509-SVIDs, the bundle contains CA certificates identified by a "use" value of x509-svid. Trust bundle contents can be retrieved from the Workload API or from a dedicated SPIFFE Bundle Endpoint (see ). The following figure illustrates how a workload can use its SPIFFE identity to access a protected resource outside of the trust domain. The example uses a JWT-SVID, but using an X509-SVID is also possible.

Workload identity in SPIFFE | SPIFFE | | | | Workload | | Workload API | | | | | +--------------+ | | +----+-+----+--+ | | | | | +--------------+ | | | | | A) access | | | | | | +----------------------->| Resource | | | | | | | | | | | +--------------+ | +------+-+-----------------------------------------------+ | | | | +--------------+ B1) federate | | B2) access | | | +---------------------------->| Resource | v | | +---------------------+ +--------------+ | | | Identity Provider | | | +---------------------+ ]]> The steps shown in are:

1) The workload requests one or more JWT-SVIDs from the SPIFFE Workload API, each with a distinct audience matching its intended use.
A) A JWT-SVID audienced for the target resource can be used to directly access resources or other workloads within the same SPIFFE Trust Domain.
B1) To access resources protected by other Identity Providers, the workload uses a JWT-SVID audienced for the Identity Provider to federate. This SHOULD be a separate JWT-SVID from the one used in step A). The Identity Provider validates the JWT-SVID and issues a new credential such as an OAuth 2.0 access token, to the workload.
B2) Using the credential issued in step B1, the workload can access resources outside of its trust domain.

Here are example claims for a JWT-SVID:

Cloud Providers Workload forms in cloud platforms vary. Historically, virtual machines were the most common. The introduction of containerization brought hosted container environments or Kubernetes clusters. Containers have evolved into serverless offerings. Regardless of the actual workload packaging, distribution, or runtime platform, all these workloads need identities. The biggest cloud providers have established the pattern of an "Instance Metadata Endpoint". Aside from allowing workloads to retrieve metadata about themselves, it also allows them to receive identity. The credential types offered can vary, and JWTs are commonly found across cloud providers. The issued credential provides proof to anyone it is being presented to that the workload platform has attested the workload and it can be considered authenticated. Within a cloud provider, the issued credential can often directly be used to access resources of any kind across the platform, making integration between the services straightforward. From the workload perspective, no credential needs to be issued, provisioned, rotated or revoked, as everything is handled internally by the platform. This is not true for resources outside of the platform, such as on-premise resources, generic web servers or other cloud provider resources. Here, the workload first needs to federate to the Secure Token Service (STS) of the respective cloud, which is effectively an Identity Provider. The STS issues a new credential with which the workload can then access resources. This pattern also applies when accessing resources in the same cloud but across different security boundaries (e.g., different account or tenant). The actual flows and implementations may vary in these situations though. When a workload needs to access both internal platform resources and external resources, it SHOULD obtain separate credentials for each purpose. The credential used for internal platform access (step A) SHOULD NOT be reused for federation to an external STS (step B1), as these represent different trust and audience boundaries. The workload may need to contact the Instance Metadata Service multiple times to obtain appropriately scoped credentials.

Workload identity in a cloud provider | Instance Metadata | | | | Workload | | Service/Endpoint | | | | | | | | | +-----+-+----+-+ +-------------------+ | | | | | | | | | | +--------------+ | | | | | A) access | | | | | | +-------------------------->| Resource | | | | | | | | | | | +--------------+ | +--------+-+--------------------------------------------------+ | | B1) federate | | B2) access | | +--------+-+--------------------------------------------------+ | | | External (e.g. other cloud) | | | | | | | | +--------------+ | | | | | | | | | +------------------------------->| Resource | | | v | | | | +-----------------------------+ +--------------+ | | | | | | | Secure Token Service (STS) | | | | | | | +-----------------------------+ | +-------------------------------------------------------------+ ]]> The steps shown in are:

1) The workload retrieves one or more identity credentials from the Instance Metadata Service or Endpoint. This endpoint exposes an API and is available at a well-known, but local-only location such as 169.254.169.254. Each credential SHOULD be scoped to its intended use with a distinct audience.

When the workload needs to access a resource within the cloud (e.g., located in the same security boundary; protected by the same issuer as the workload identity):

A) The workload directly accesses the protected resource with a credential scoped for that resource, as issued in Step 1.

When the workload needs to access a resource outside of the cloud (e.g., different cloud; same cloud, but different security boundary):

B1) The workload uses a separate cloud-issued credential, audienced for the external STS, to federate to the Secure Token Service of the other cloud/account. This credential SHOULD NOT be the same as the one used in step A). The STS validates the credential and issues a new credential, such as an access token to the workload.
B2) Using the credential issued in step B1, the workload can access the resource outside, assuming the credential has the necessary permissions.

It is important to distinguish the credential obtained from the Instance Metadata Service from a workload identity document commonly used in attestation systems. A workload identity document typically represents attestation evidence that is evaluated by a relying party or attestation service. In contrast, some credentials issued by the metadata service are already the result of such attestation and are intended to be directly consumed by relying services for authentication and authorization decisions. In many cloud environments, the credential retrieved from the metadata service is a bearer token. Possession of such a token is sufficient to use it, which introduces risks around token handling and exposure. Some providers mitigate this by constraining token scope, lifetime, or audience, or by requiring additional proof-of-possession mechanisms. These mechanisms reduce the risk of token replay or misuse if the token is exfiltrated. The same bearer credential MUST NOT be used across different trust domains without appropriate controls. While direct use of the issued credential within the same cloud security boundary is common, reusing that credential outside of its intended scope can increase the risk of credential leakage and enable impersonation. The federation step via the Secure Token Service (Step B1) serves as a boundary, allowing the original credential to be exchanged for a new credential that is scoped, audience-restricted, and appropriate for the target resource.

Continuous Integration and Deployment Systems Continuous integration and deployment (CI-CD) systems allow their pipelines (or workflows) to receive an identity at runtime. It is a common task to upload build outputs and other artifacts to external resources. For this, federation to external Identity Providers is often necessary. As with other platforms, CI-CD workloads may obtain multiple tokens from the platform, each with a distinct audience for the specific resource or Identity Provider it needs to interact with.

1) The CI-CD platform schedules a workload (pipeline or task). Based on configuration, a Workload Identity is made available by the platform.
B1) The workload uses the platform-issued credential to federate to an Identity Provider, which validates the credential and issues a new credential, such as an access token, for the workload.
B2) The workload uses the issued credential to access resources. For instance, an artifact store to upload compiled binaries, or to download libraries needed to resolve dependencies. It is also common to access actual infrastructure as resources to make deployments or changes to it.

While token structure is vendor-specific, all tokens contain claims carrying the basic context of the executed tasks, such as source code management data such as git branch, initiation context and more. CI-CD pipelines sometimes use credentials to perform code signing operations integrity proof of the build output. As explained in the , strength of the integrity is limited to the strength of the credential used.

Service Meshes Service meshes provide infrastructure-level workload identity and secure communication for applications through sidecar proxies deployed alongside each workload. In a service mesh, workload identity is typically implemented using X.509 certificates issued by the service mesh. Service meshes handle identity credential provisioning to sidecar proxies rather than directly to application workloads. The sidecar intercepts network traffic and handles authentication transparently to the application code.

1) The Service Mesh issues identity credentials to proxies. For X.509-based meshes, this consists of an X.509 certificate containing the workload's identity along with the associated key pair.
2) The proxies act on behalf of workloads that delegate their communication to them. In above figure each workload has its own proxy that solely represents it and no other workload.
3) The proxies communicate with each other on behalf of the workloads they represent. This communication includes authentication aspects, for instance mutual TLS using X.509 certificates.

In above pattern each workload has a specific sidecar. An alternative deployment is to share proxies between workloads. This often results in a single proxy on each node acting on behalf of all workloads on the node.

Security Considerations All security considerations in section 8 of apply.

Credential Delivery

General Credentials Requirements Credentials SHOULD be scoped as narrowly as possible: each SHOULD carry the smallest set of audiences that lets it serve its purpose. A credential for direct access to a platform resource SHOULD be scoped to that resource; a credential used to federate to an Identity Provider SHOULD carry that Identity Provider as its sole audience. See for the rationale and for specific requirements on the "aud" claim of JWT-based credentials. As long as the workload platform supports issuance of multiple credentials, a workload SHOULD obtain a distinct credential for each resource or Identity Provider it interacts with. In particular, the credential used to federate to an Identity Provider SHOULD NOT be used for direct platform access; reusing a credential across these contexts conflates trust boundaries and increases the impact of a compromise (see ).

Filesystem Access control to the mounted file SHOULD be configured to limit reads to authorized applications. Linux supports solutions such as DAC (uid and gid) or MAC (e.g., SELinux, AppArmor). Credentials written to durable storage persist until they are overwritten or removed, and may be captured in backups, snapshots, or images. Implementations therefore commonly mount credentials from memory-backed storage instead. Such a mount SHOULD be isolated from other host OS paths and processes. For example, on Linux this can be achieved by using namespaces.

Local APIs Local APIs often operate in clear-text, such as unencrypted HTTP, without any confidentiality or integrity protection. Privileged components on a host or in the infrastructure may be able to eavesdrop on a connection and view a credential within it. Mitigations are required for Server-Side Request Forgery (SSRF) attacks against Local APIs. For example, implementations can require a specific header that cannot be controlled externally or prevent untrusted input from triggering requests to link-local IPs, including through redirects. See for details. Adequate assurance that the identity represents the workload is required to make sure unauthorized access is denied and credentials are not issued to other parties when the Local API is unauthenticated. What constitutes adequate assurance depends on the security requirements of the deployment. Introspection of the platform, like in SPIFFE or cloud providers, can be used to identify workloads and grant access. The more fine-grained and strict this verification, the smaller the attack surface. For instance, allowing access by IP or other machine-global identifiers permits any process to receive the identity, while including user ID or other process-scoped identifiers prevents this broader access. The potential for denial-of-service attacks against Local APIs needs to be taken into account and protective measures SHOULD be implemented. Depending on the platform these attacks can affect other workloads and their ability to receive a platform credential.

Environment Variables Leveraging environment variables to provide credentials presents many security limitations. Environment variables have a wide set of use cases and are observed by many components. They are often captured for monitoring, observability, debugging and logging purposes and sent to components outside of the workload. Access control is not trivial and does not achieve the same security results as other methods. Additionally, environment variables may be spoofed or altered by other processes running on the same host, making them an unreliable transport for credentials in environments where process isolation is not strictly enforced. For these reasons, environment variables MUST NOT be used to deliver workload identity credentials in production deployments where the platform offers another delivery pattern.

Application Interaction with Credential Sources Implementations MUST assume that application vulnerabilities can expose workload credentials even when platform isolation is correctly configured. Attackers commonly exploit the workload itself to retrieve credentials rather than accessing the credential service directly. For example, untrusted input may be used to manipulate file paths when credentials are mounted on a filesystem, or to trigger requests to local credential endpoints such as metadata or workload APIs (for example via SSRF). Similarly, command execution or unintended outbound requests may result in bearer tokens or proof-of-possession key material being disclosed. Workloads therefore MUST treat credential locations as sensitive security boundaries. Untrusted input MUST NOT influence how credential files are accessed or how local credential APIs are contacted. Implementations SHOULD minimize which components can access credentials and prefer proof-of-possession credentials over bearer tokens where supported. Failure to minimize credential access increases the attack surface by allowing more code paths to interact with sensitive material. Failing to use proof-of-possession credentials where available means that stolen bearer tokens can be replayed by an attacker from any location. These risks exist even when credential services are reachable only locally, since compromise often occurs through application behavior rather than network access to the credential provider.

Token typing Issuers SHOULD strongly type the issued tokens to workloads via the JOSE "typ" header parameter (), and Identity Providers accepting these tokens SHOULD validate its value according to policy. See for details on explicit typing. Without explicit typing, a token intended for one purpose (e.g., a refresh token or an identity assertion) may be accepted in a context where a different token type is expected, enabling cross-protocol or cross-context token confusion attacks. Issuers SHOULD use authorization-grant+jwt as a "typ" value according to . For broad support, JWT or JOSE MAY be used by issuers and accepted by authorization servers but it is important to highlight that a wide range of tokens, meant for all sorts of purposes, use these values and would be accepted. Using generic type values such as JWT or JOSE is acceptable only when the deployment cannot support more specific types, for instance due to limitations in existing infrastructure or token libraries. Even in such cases, additional validation of token claims and context is essential to mitigate confusion.

Custom claims are important for context Some platform-issued credentials carry custom claims that are vital for context. Relying parties need to consider the values of these claims, not merely check that they are present. For example, in a continuous integration and deployment platform where a workload is scheduled for a Git repository, the branch is crucial. A "main" branch may be protected and considered trusted to federate to external authorization servers. But other branches may not be allowed to access protected resources. Authorization servers that validate assertions SHOULD make use of these claims. Ignoring custom claims may result in overly permissive authorization decisions, such as granting a credential issued for an untrusted branch the same access as one issued for a protected branch. Platform issuers SHOULD allow differentiation based on the "sub" (subject) claim alone, so that authorization policies can be expressed without requiring deep knowledge of vendor-specific claim structures.

Token lifetime Tokens SHOULD NOT exceed the lifetime of the workloads instance they represent. For example, a token valid for two hours or more exceeds the lifetime of a workload that is expected to run for one hour. A token that outlives its workload may continue to be accepted by relying parties even after the workload (and its associated authorization context) has ceased to exist, enabling unauthorized access if the token is compromised. Within the scope of this document, where a platform-issued credential is used to authenticate to retrieve an access token for an external authorization domain, short-lived credentials are RECOMMENDED. Short-lived credentials reduce the window during which a stolen credential can be exploited and limit the need for explicit revocation infrastructure.

Workload lifecycle and invalidation Platform issuers SHOULD invalidate credentials when an instance of the workload stops, pauses, or ceases to exist and SHOULD offer validators a mechanism to query this status. Because a workload may run as multiple instances (for example, replicas or parallel tasks), this applies to each instance individually. Without this capability, credentials for terminated instances remain usable until their natural expiry, creating a window for unauthorized use. Without a status query mechanism, relying parties have no way to detect that an instance has been removed. How these credentials are invalidated and the status is queried varies and is not in scope of this document.

Proof of possession Identity credentials SHOULD be bound to the workload instance they represent, and proof of possession SHOULD be performed when these credentials are used. This reduces the impact of token theft to the scope of the proof of possession. Without proof of possession, a bearer token intercepted in transit (e.g., via a compromised log, a man-in-the-middle, or SSRF) can be replayed by any party, from any location, for the remaining lifetime of the token. For X.509-based credentials, proof of possession is inherent through the private key associated with the certificate. For JWT-based credentials, the JWT SHOULD be key-bound with an adequate proof-of-key-possession mechanism. Where proof of possession is not supported by the platform or the relying party, deployments SHOULD compensate with shorter token lifetimes, stricter audience scoping, and additional network-level controls such as IP allowlisting or mutual TLS. This proof of possession applies to both the platform credential and the access token of the external authorization domains.

Audience For issued credentials in the form of JWTs, they MUST be audienced using the "aud" claim. Each JWT SHOULD only carry a single audience. Using multiple audiences in a single token means that any relying party listed in the "aud" claim can present that token to any other party listed in the same claim, potentially gaining unintended access. A single-audience token limits the blast radius if the token is compromised or misused. We RECOMMEND using URIs to specify audiences. See for more details and security implications. Some workload platforms provide credentials for interacting with their own APIs (e.g., Kubernetes). These credentials MUST NOT be used beyond the platform API. In the example of Kubernetes, a token used for anything other than the Kubernetes API itself MUST NOT carry the Kubernetes server in the "aud" claim. Reusing a platform API token for federation or resource access outside the platform conflates trust boundaries: the token's audience includes the platform, so any relying party that accepts it could impersonate the workload back to the platform.

Multi-Tenancy Considerations In multi-tenant platforms, relying parties MUST carefully evaluate which attributes are considered trustworthy when making authorization decisions. Access or federation MUST NOT be granted based solely on untrusted or easily forgeable attributes. In particular, the "iss" (issuer) claim in such environments may not uniquely identify a trusted authority, since each tenant could be configured with the same issuer identifier. Relying parties SHOULD ensure that attributes used for authorization are bound to a trust domain under their control or validated by an entity with a clearly defined trust boundary. Failing to do so may allow a malicious tenant to obtain credentials that are indistinguishable from those of a legitimate tenant, leading to cross-tenant privilege escalation or unauthorized access to shared resources.

IANA Considerations This document does not require actions by IANA.

Acknowledgements The authors and contributors would like to thank the following people for their feedback and contributions to this document (in no particular order): Dag Sneeggen, Ned Smith, Dean H. Saxe, Yaron Sheffer, Andrii Deinega, Marcel Levy, Pieter Kasselmann, Simon Canning, Evan Gilman, Joseph Salowey, Kathleen Moriarty, Brian Campbell, Judith Kahrer and Flemming Andreasen. The authors would also like to thank Justin Richer for serving as document shepherd and Charles Eckel for his AD evaluation of this document.

References Normative References The OAuth 2.0 Authorization Framework The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] JSON Web Token (JWT) JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. JSON Web Key (JWK) A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants This specification provides a framework for the use of assertions with OAuth 2.0 in the form of a new client authentication mechanism and a new authorization grant type. Mechanisms are specified for transporting assertions during interactions with a token endpoint; general processing rules are also specified. The intent of this specification is to provide a common framework for OAuth 2.0 to interwork with other identity systems using assertions and to provide alternative client authentication mechanisms. Note that this specification only defines abstract message flows and processing rules. In order to be implementable, companion specifications are necessary to provide the corresponding concrete instantiations. JSON Web Signature (JWS) JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. JSON Web Token Best Current Practices JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas. This Best Current Practices document updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs. Updates to OAuth 2.0 JSON Web Token (JWT) Client Authentication and Assertion-Based Authorization Grants Self-Issued Consulting Ping Identity Disney Okta This document updates RFC7521, RFC7522, RFC7523 and RFC9126 with respect to the treatment of audience values in OAuth 2.0 Client Assertion Authentication and Assertion-based Authorization Grants to address a security vulnerability identified in the previous requirements for those audience values in multiple OAuth 2.0 specifications. Resource Indicators for OAuth 2.0 This document specifies an extension to the OAuth 2.0 Authorization Framework defining request parameters that enable a client to explicitly signal to an authorization server about the identity of the protected resource(s) to which it is requesting access. OAuth 2.0 Token Exchange This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. Informative References Kubernetes Service Account Kubernetes Token Review API V1 Kubernetes Token Request API V1 Secure Production Identity Framework for Everyone (SPIFFE)

Variations

Direct access to protected resources Resource servers that protect resources may choose to trust multiple authorization servers, including the one that issues the platform identities. Instead of using the platform-issued identity to receive an access token of a different authorization domain, workloads can directly use the platform-issued identity to access a protected resource. In this case, technically, the protected resource and workload are part of the same authorization domain.

Custom assertion flows While and are the proposed standards for this pattern, some authorization servers use or a custom API for the issuance of an access token based on existing platform identity credentials. These patterns are discouraged as they prevent interoperability.

Document History [[ To be removed from the final specification ]] -06

Address AD evaluation comments from Charles Eckel
Address review feedback from Andrii Deinega
Review use of BCP 14 language for consistency
Reformat the filesystem security considerations and cover credentials on durable storage
Reference RFC 7515 for the JOSE "typ" header parameter
Clarify Kubernetes JWK Set validation, SPIFFE Workload API client authentication, custom claim validation and workload invalidation
Update author affiliation
Update acknowledgements
Editorial improvements

-05

Rework introduction and abstract to remove normative language
Differentiate cloud provider credentials from workload identities
Discourage the use of environment variables for credentials
Clean up references and make diagram labelling consistent
Editorial improvements to the abstract, cloud provider section and examples

-04

Address review feedback from Kathleen Moriarty and Joe Salowey
Expand introduction: explain the workload identity bootstrapping problem and the limitations of static credentials
Expand SPIFFE section: trust bundles, JWT-SVID vs X509-SVID types, and Workload API identification
Explicitly discuss obtaining multiple tokens with distinct audiences across all platform patterns
Add "Application Interaction with Credential Sources" section covering SSRF and path traversal risks
Update reference formatting
Editorial improvements and updated acknowledgements

-03

Add service-mesh section
Add multi-tenancy considerations
Add atomicity and flushing requirements to filesystem section
Make it clear that invalidation is a matter of querying the status
Rework local api section & security considerations
Refer to RFC7517 in SPIFFE and add clarity on key distribution
Editorial changes

-02

Updated structure, bringing concrete examples back into the main text.
Use more generic "federation" term instead of RFC 7523 specifics.
Overall editorial improvements.
Fix reference of Kubernetes Token Request API
Prefer the term "document" over "specification".
Update contributor and acknowledgements sections.
Remove section about OIDC as it is too specific to a certain implementation.
Rewrite abstract to better reflect the current content of the document.

-01

Add credential delivery mechanisms
Highlight relationship to other WIMSE work
Add details about token typing and relation to OpenID Connect
Add security considerations for audience

-00

Rename draft with no content changes.
Set Arndt to Editor role.

[as draft-wimse-workload-identity-bcp] -02

Move scope from Kubernetes to generic workload identity platform
Add various patterns to appendix
- Kubernetes
- Cloud providers
- SPIFFE
- CI/CD
Add some security considerations
Update title

-01

Editorial updates

-00

Adopted by the WIMSE WG

Contributors Siemens

hofmann.benedikt@siemens.com

Siemens

hannes.tschofenig@gmx.net

Nokia

edoardo.giordano@nokia.com