]> SPIRL

arndts.ietf@gmail.com

Siemens

hofmann.benedikt@siemens.com

Siemens

hannes.tschofenig@gmx.net

Nokia

edoardo.giordano@nokia.com

Zscaler

yrosomakho@zscaler.com

Applications and Real-Time Workload Identity in Multi System Environments Internet-Draft The use of the OAuth 2.0 framework in container orchestration systems poses challenges, particularly in managing credentials such as client_id and client_secret, which can be complex and prone to errors. To address this, the industry has shifted towards a federation-based approach where credentials of the underlying workload platform are used as assertions towards an OAuth authorization server, leveraging the Assertion Framework for OAuth 2.0 Client Authentication , specifically . This specification describes a meta flow in , gives security recommendations in and outlines concrete patterns in . It referes to existing industry practices that are mainly built on top of OAuth. It may not be in line with the (currently work in progress) WIMSE architecture and other protocols, such as .

Introduction Workloads often require access to external resources to perform their tasks. For example, access to a database, a web server or another workload. These resources are protected by an authorization server and can only be accessed with an access token. The challenge for workloads is to get this access token issued. Traditionally, workloads were provisioned with client credentials and use the corresponding client credential flow (Section 1.3.4 ) to retrieve an access token. This model comes with a set of challenges that make it insecure and high-maintenance. Secret materials need to be provisioned and rotated, which often happens manually. It also can be stolen and used by attackers to impersonate the workload. A solution to this problem is to not provision secret material to the workload and use the platform the workload runs on to attest for it. Many workload platforms offer a credential, in most cases a JWT token. Signed by a platform-internal authorization server, the credential attests the workload and its attributes. Based on and its JWT profile , this credential can then be used as a client assertion towards a different authorization server.

Terminology 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. For the scope of this specification, the term authorization server is only used for the authorization server of the external authorization domain as highlighted in . Even though, technically, the platform credential is also issued by an authorization server within the workload platform, this specification only refers to it as "platform issuer" or just "platform".

OAuth Assertion in Workload Environments

Overview illustrates a generic pattern that applies across all of the patterns described in :

OAuth2 Assertion Flow in generic Workload Environment issued by | | | | | 1) pull/ | Platform | | | +--------------------------+ push +-------------+ | +----------------------------------------------------------+ ]]>

The figure outlines the following steps which are applicable in any pattern.

• 1) retrieve credential issued by platform. The way this is achieved and whether this is workload (pull) or platform (push) initiated differs based on the platform.
• 2) present credential as an assertion towards an authorization server in an external authorization domain. This step uses the assertion_grant flow defined in and, in case of JWT format, .
• 3) On success, an access token is returned to the workload to access the protected resource.
• 4) The access token is used to access a protected resource in the external authorization domain. For instance by making a HTTP call.

Accessing different protected resources may require steps 2) to 4) again with different scope parameters. Accessing a protected resource in an entirely different authorization domain often requires the entire flow to be followed again, to retrieve a new platform-issued credential with an audience for the external authorization server. This, however, differs based on the platform and implementation.

Credential issuance Credentials can be provisioned to the workload through different mechanisms which present different complexity and security risks. The following section highlights the pros and cons of most widespread solutions.

Environment variable Injecting the credentials into the environmental variables allows for simple and fast deployments. Applications can directly access them through system-level mechanism, e.g., through the env command in linux. This flexibility, however, comes with security drawbacks.

• 1) environmental variables are static in nature and more dynamic solutions require to introduces higher complexity.
• 2) performing access control to environmental variable is not trivial and it might also not reach the same security results.
• 3) environmental 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 send to components outside of the workload.

Leveraging environmental variables to provide credentials presents many security limitations. This approach should be limited to cases where simplicity of the application is required, e.g., during PoCs, and the provided secrets should have a short-term validity, i.e., an initial secret during the set-up of the application.

Files Files allow to inject credentials into a container through the file-system and access them through primitives, e.g., Open, Close, etc. Such solutions enable secret rotation, and access control on the injected secret with standard operating system measure for files.

• 1) access control to the mounted file should be configure to limit access from unauthorized applications. E.g., on Linux solutions such as DAC (uid and guid) or MAC (SELinux,AppArmor) are available.
• 2) isolating the mounted shared memory from critical host OS paths and processes is required. E.g, on Linux this is achieved by utilising namespaces.
• 3) credentials rotation requires a solution to detect near-to-expiration secrets and substitute them. Solutions should enable configuration such that the new secret is renewed before the old secret is invalidated. E.g., the solution can choose to update the secret 1h before the old secret is invalidated. This enables applications time to update their usage of the old secret to the new without downtime.

Volume solutions find their 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, which path can be provisioned through environmental variables, only when required.

Local APIs This set of solution rely on local APIs to communicate between the Host and the containerised application. Some implementations rely on UNIX Domain Sockets (SPIFFE), loopback interfaces or Magic (Link-Local) Addresses (AWS Metadata service) to provision credentials. Local APIs offer the capability to re-provision updated credentials. Communication between workload and API allows the workload to re-request a new credential (or a different one). Based on the technology it is even possible to pro-actively distribute new credentials to workloads (e.g. upon expiry, during a revocation event or a change in permissions). This group of solutions rely on network isolation for their security.

• 1) credentials are only issued when request, thus reducing unnecessary credential issuance and allowing for a narrowly-scoped and short-lived secrets. For instance one-time credentials or narrowly scoped ones such as JSON Web Tokens with specific audiences.
• 2) the benefit of a more structured delivery comes with less portability between different APIs.
• 3) additional latency may be introduced due to the request and additional operational overhead.

Local APIs offer the highest level of access control to protect the credential from un-legitimate access. They particularly thrive in environments of short-lived, narrowly scoped credentials, but come with operational overhead if the workload platform does not offer it already.

Credential format For the scope of this document we focus on JSON Web Token credential formats. Other formats such as X.509 certificates are possible but not as widely seen as JSON Web Tokens. The claims in the present assertion vary greatly based on use case and actual platform, but a minimum set of claims are seen across all of them. describes them in detail and according to it, all MUST be present. For the scope of this specification, the claims can be described the following. Everything from applies.

iss

The issuer of the workload platform. While this can have any format, it is important to highlight that many authorization servers leverage OpenID Connect Discovery and/or OAuth 2.0 Authorization Server Metadata to retrieve JSON Web Keys for validation purposes.

sub

Subject which identifies the workload within the domain/workload platform instance.

audience

One or many audiences the platform issued credential is eligible for. This is crucial when presenting the credential as an assertion towards the external authorization server which MUST identify itself as an audience present in the assertion.

Security Recommendations All security considerations in section 8 of apply.

Token typing Issuers SHOULD strongly type the issued tokens to workload via the JOSE typ header and authorization servers SHOULD validate the value of it according to policy. See Section 3.1 of for details on explicit typing. 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's important to highlight that a wide range of tokens, meant for all sorts of purposes, use these values and would be accepted.

Custom claims are important for context Some platform issued credentials have custom claims that are vital for context and are required to be validated. 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, other branches may not be and are not allowed to access protected resources. Authorization servers that validate assertions SHOULD make use of these claims. Platform issuers SHOULD allow differentiation based on the subject claim alone.

Token lifetime Tokens SHOULD NOT exceed the lifetime of the workloads they represent. For example, a workload that has an expected lifetime of an hour should not receive a token valid for 2 hours or more. For the scope of this specification, where a platform issued credential is used to authenticate to retrieve an access token for an external authorization domain, a short-lived credential is recommended.

Workload lifecycle and invalidation Platform issuers SHOULD invalidate those when the workload stops, pauses or ceases to exist. How these credentials are invalidated is not in scope of this specification.

Proof of possession Credentials SHOULD be bound to workloads and proof of possession SHOULD be performed when these credentials are used. This mitigates token theft. This proof of possession applies to 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. We RECOMMEND using URIs to specify audiences. See section 3 of 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 else than the Kubernetes API itself MUST NOT carry the Kubernetes server in the aud claim.

Other considerations

Relation to OpenID Connect and its ID Token The outlined pattern has been referred to as "OIDC" and respectively, the Workload Identity Token as "OIDC ID Token" defined in . The authors of this document want to highlight that this pattern is not related to OpenID Connect and the issued Workload Identity Tokens by the platforms are not "ID Tokens" in the sense of OIDC. However, it is common practice for the authorization server to leverage to retrieve the signing keys needed for token validation. The use of or any other key distribution remain valid.

IANA Considerations This document does not require actions by IANA.

Acknowledgements Add your name here.

References Normative References 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. 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. This specification defines the use of a JSON Web Token (JWT) Bearer Token as a means for requesting an OAuth 2.0 access token as well as for client authentication. 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] 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. This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities. 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. 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. 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. 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. 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 Self-Issued Consulting Ping Identity Disney This specification defines the use of a JSON Web Token (JWT) Bearer Token as a means for requesting an OAuth 2.0 access token as well as for client authentication. Venafi Zscaler University of Applied Sciences Bonn-Rhein-Sieg The increasing prevalence of cloud computing and micro service architectures has led to the rise of complex software functions being built and deployed as workloads, where a workload is defined as a running instance of software executing for a specific purpose. This document discusses an architecture for designing and standardizing protocols and payloads for conveying workload identity and security context information. Ping Identity Venafi SPIRL Intuit The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones up to complex multi-service, multi-cloud, multi- tenant deployments. This document defines the simplest, atomic unit of this architecture: the protocol between two workloads that need to verify each other's identity in order to communicate securely. The scope of this protocol is a single HTTP request-and-response pair. To address the needs of different setups, we propose two protocols, one at the application level and one that makes use of trusted TLS transport. These two protocols are compatible, in the sense that a single call chain can have some calls use one protocol and some use the other. Service A can call Service B with mutual TLS authentication, while the next call from Service B to Service C would be authenticated at the application level. Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore Sakimura, N., Bradley, J., Jones, M. and Jay, E.

Patterns

Kubernetes In Kubernetes, the primary concept of machine identity is implemented through "service accounts" . These accounts can be explicitly created or a default one is automatically assigned. Service accounts utilize JSON Web Tokens (JWTs) as their credential format, with these tokens being cryptographically signed by the Kubernetes Control Plane. 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 (which is particularly relevant to the scope of this document). To programatically use service accounts, workloads can:

• use the Token Request API of the control plane
• have the token projected into the file system of the workload. This is commonly referred to as "projected service accout token".

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, when a Kubernetes Deployment is removed from the server. It is important to highlight, that invalidation is only in effect if the Token Review API of Kubernetes is used to validate the token.

To validate service account tokens, Kubernetes offers workloads to:

• make us 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 decentrally validate the tokens signature.
• Optionally, a JSON Web Key Set is exposed via a webserver. This allows the Service Account Token to be validated outside of the cluster and without line of sight towards the actual Kubernetes Control Plane API.

OAuth2 Assertion Flow in a Kubernetes Workload Environment

The steps shown in are:

• 1) The Kubernetes Control Plane schedules the workload. This is much simplified and technically happens asynchronously.
• 2) The Kubernetes Control Plane projects the service account token into the workload. This step is also much simplified and technically happens alongside the scheduling with step 1.
• 3) Workloads present the projected service account token as a client assertion towards an external authorization server according to .
• 4) On success, an access token is returned to the workload to access the protected resource.
• 5) The access token is used to access the protected resource in the external authorization domain.

As an example, the following JSON showcases the claims a Kubernetes Service Account token carries.

Example Kubernetes Service Account Token claims

Secure Production Identity Framework For Everyone (SPIFFE) Secure Production Identity Framework For Everyone, also known as SPIFFE, is a cloud native compute foundation (CNCF) adopted project which defines an API defined called "Workload API" to delivery machine identity to workloads. Workloads can retrieve either X509 based or JWT credentials without the need to authenticate making it very easy to use. How workloads authenticate on the API is not part of the specification. It is common to use platform metadata from the operating system and the workload platform for authentication on the Workload API. For the scope of this document, the JWT formatted credential is the most relevant one. SPIFFE referres to it as "JWT-SVID" (JWT - SPIFFE Verifiable Identity Document). Workloads are required to specify at least one audience when requesting a JWT-SVID from the Workload API. To allow validation, SPIFFE offers

• to download a set JWK encoded public keys that can be used to validate JWT signatures. In SPIFFE this is referred to as the "JWT trust bundle".
• invoke a validation method on the Workload API to validate JWT-SVIDs

Additionally, many SPIFFE deployments choose to separately publish the signing keys as a JSON Web Key Set on a web server to allow validation where the Workload API is not available. The following figure illustrates how a workload can use its JWT-SVID to access a protected resource outside of SPIFFE.

OAuth2 Assertion Flow in a SPIFFE Environment

The steps shown in are:

• 1) The workload request a JWT-SVID from the SPIFFE Workload API with an audience that identifies the external authorization server.
• 2) The workload presents the JWT-SVID as a client assertion in the assertion flow based on .
• 3) On success, an access token is returned to the workload to access the protected resource.
• 4) The access token is used to access the protected resource in the external authorization domain.

The claims of a JWT-SVID for example look like this: TODO: write about "iss" in JWT-SVID.

Cloud Providers Workload in cloud platforms can have any shape or form. Historically, virtual machines were the most common, with the introduction of containerization, hosted container environment or Kubernetes clusters were introduced, and lately, serverless functions are offered. Regardless of the actual workload packaging, distribution and runtime platform, all are in need of identity. To create a common identity interface across cloud services and offerings, the pattern of an Instance Metadata Endpoint has been established by the biggest cloud providers. Next to the option for workloads to get metadata about themselves, it also allows them to receive identity. The credential types offered can vary. JWT, however, is the one that is common across all of them. The issued credential allows 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 easy and credential less. While the term is technically misleading, from a user perspective, no credential needs to be issued, provisioned, rotated or revoked, as everything is handled internally by the platform. Resources outside of the platform, for example resources or workloads in other clouds, generic web servers or on-premise resources, are most of the time, however, protected by different domains and authorization servers and deny the platform issued credential. In this scenario, the pattern of using the platform issued credential as an assertion in the context of , for JWT particularly towards the authorization server that protected the resource to get an access token.

OAuth2 Assertion Flow in a cloud environment Instance | | | | | | | | | +-----------+------------+ | Metadata | | | | | | | | A1) access | Service/ | | | | | Endpoint | | | +-----------v------------+ | | | | | | +----------+ | | | Protected Resource | | | | | | | +------------------------+ | +--------------------------------------------------------+ ]]>

The steps shown in are:

• 1) The workload retrieves identity from the Instance Metadata Endpoint.

In case the workload needs to access a resource within the cloud (protected by the same authorization server that issued the workload identity)

• A1) The workload directly access the protected resource with the credential issued in step 1.

In case the workload needs to access a resource outside of the cloud (protected by a different authorization server). This can also be the same cloud but different context (tenant, account).

• B1) The workload presents cloud-issued credential as an assertion towards the external authorization server using .
• B2) On success, an access token is returned to the workload to access the protected resource.
• B3) Using the access token, the workload is able to access the protected resource in the external authorization domain.

Continuoues integration/deployment systems Continuous integration and deployment systems allow their pipelines/workflows to receive identity every time they run. Particularly in situations where build outputs need to be uploaded to resources protected by other authorization server, deployments need to be made, or more generally, protected resources to be accessed, is used to federate the pipeline/workflow identity to an identity of the other authorization server.

OAuth2 Assertion Flow in a continuous integration/deployment environment

The steps shown in are:

• 1) The continuous integration / deployment platform (CI-CD platform) schedules a task (considered a workload) to be performed.
• 2) The workload is able to retrieve identity from the CI-CD platform. This can differ based on the platform and potentially is already supplied during scheduling phase in step 1.
• 3) The workload presents the CI-CD issued credential as an assertion towards the authorization server in the external authorization domain based on . In case of JWT also .
• 4) On success, an access token is returned to the workload to access the protected resource.
• 5) Using the access token, the workload is able to access the protected resource in the external authorization domain.

Tokens of different providers look different, but all of them contain claims carrying the basic context of the executed tasks such as source code management data (e.g. git branch), initiation and more.

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 an existing platform identity credentials. These pattern are not recommended and prevent interoperability.

Document History [[ To be removed from the final specification ]] -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