]> SPIRL

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 other protocols, such as .

Introduction Just like people, the workloads inside container orchestration systems (e.g. Kubernetes) need identities 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 other identity providers, which in turn, issue credentials that grant access to resources. Traditionally, workloads were provisioned with client credentials and use for example the corresponding client credential flow (Section 1.3.4 ) to retrieve an OAuth 2.0 access token. This model presents a number of security and maintenance issues. Secret materials must be provisioned and rotated, which require either automation to be built, or periodic manual effort. Secret materials can be stolen and used by attackers to impersonate the workload. Other, non OAuth 2.0 flows, such as direct API keys or other secrets, 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 token (). 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 .

Generic workload identity pattern | Platform Issuer | | | | | 1) push/pull | | | | +-----+-+------+--+ +------------------+ | | | | | | | | | | | | | | | +--------------+ | | | | | A) access | | | | | | +--------------------->| Resource | | | | | | | | | | | +--------------+ | +-------+-+----------------------------------------------+ | | | | +--------------+ B1) federate | | B2) access | | | +---------------------------->| Resource | v | | +-------------------+ +--------------+ | | | Identity Provider | | | +-------------------+ ]]>

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

• 1) Platform issues credential to workload. The way this is achieved differs from the platform, for instance, it can be pushed to the workload or pulled by the workload.
• A) The credential can give the workload direct access to resources within the platform or the platform itself (e.g. to perform infrastructure operations)
• B1) The workload uses the credential to federate to an Identity Provider. This step is optional and only needed when accessing outside resources.
• B2) The workload accesses resources outside of the platform and uses the federated identity obtained in the previous step.

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 example in situations where the platform-issued credential is scoped to accessing a certain resource or federating to a specific Identity Provider.

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.

Delivery Patterns Credentials can be provisioned to the workload by different mechanisms, which each have their 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 .

Environment Variables Injecting the credentials into the environment variables allows for simple and fast deployments. Applications can directly access them through system-level mechanism, 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.

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.

Local APIs This pattern relies on local APIs to communicate between the workload and the credential issuer. Some implementations rely on UNIX Domain Sockets (e.g. SPIFFE), loopback interfaces or link-local "magic addresses" (e.g. Instance Metadata Service of cloud providers) to provision credentials. Local APIs offer the capability to re-provision updated credentials. Communication between workload and API allows the workload to refresh a credential or request a different one. This group of solutions relies on network isolation for their security. Local APIs allow for short-lived, narrowly-scoped credentials. Persistent connections allow the issuer to push credentials. This pattern also requires client code, which introduces portability challenges. The request-response paradigm and additional operational overhead adds latency.

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 (JWTs) 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 programatically 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.

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 webserver. This allows the Service Account Token to be validated outside of the cluster and access to the actual Kubernetes Control Plane API.

Kubernetes workload identity in practice | API Server | | | | | | | | | +--------------+ | | +----+----+ ^ 1) request token | | | | 2) schedule +----+----+ | | | Pod |<------------+ Kubelet | | | | | +---------+ | | +-+-+---+-+ | | | | | +--------------+ | | | | | B1) access | | | | | | +--------------------->| Resource | | | | | | | | | | | +--------------+ | | | | | +---+-+-------------------------------------------+ | | | | +--------------+ C1) federate | | C2) access | | | +------------------------->| Resource | v | | +---------------------+ +--------------+ | | | Identity Provider | | | +---------------------+ ]]>

The steps shown in are:

• 1) The kubelet is tasked to schedule a Pod. Based on configuration it requests a Service Account Token from the Kubernetes API server.
• 2) The kubelet starts the Pod and, based on the configuration of the Pod, deliveres the token to the containers within the Pod.

Now, the Pod can use the token to

• A) Access the Kubernetes Control Plane, considering it has access to it.
• B) Access other resources within the cluster, for instance other Pods.
• C) Access resources outside of the cluster.
  • C1) The application within the pod uses the Service Account Token to federate to an Identity Provider outside of the Kubernets Cluster.
  • C2) Using the federated identity 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 either X.509 certificates or JWTs. How workloads authenticate on the API is not part of the document. It is common to use platform metadata from the operating system and the workload platform for authentication to the Workload API. SPIFFE refers to the JWT-formatted credential as a "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. For validation, SPIFFE offers:

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

Additionally, many SPIFFE deployments choose to separately publish the signing keys as a JWK 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.

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 a JWT-SVID from the SPIFFE Workload API.
• A) The JWT-SVID can be used to directly access resources or other workloads within the same SPIFFE Trust Domain.
• B1) To access resource proctected by other Identity Providers the workload uses the SPIFFE JWT-SVID to federate to the Identity Provider.
• B2) Once federated, the workload can access resources outside of its trust domain.

• TODO: We should talk about native SPIFFE federation. Maybe a C) flow in the diagram or at least some text.

Here are example claims for a JWT-SVID: 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. The introduction of containerization brought hosted container environment 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. 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 "credentialless". 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. 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 firsts need to federate to the Secure Token Service (STS), which is effectively an Identity Provider, to receive an identity of the other cloud. Using this different identity the workoad can then access its 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.

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 an identity from the Instance Metadata Service or Endpoint. This endpoint exposes an well-known API and is available at well- known, but local, location.

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 access the protected resource with the credential 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 cloud-issued credential to federate to the Secure Token Service of the other cloud/account.
• B2) Using the federated identity the workload can access the resource outside, assuming the federated identity has the necessary permissions.

Continuous Integration and Deployment Systems Continuous integration and deployment (CI-CD) systems allow their pipelines (or workflows) to receive an identity every time they run. Build outputs and other artifacts are commonly uploaded to external resources. With federation to external Identity Providers the pipelines and tasks can access these resources.

OAuth2 Assertion Flow in a continuous integration/deployment environment | Resource | v | | +-------------------+ +--------------+ | | | Identity Provider | | | +-------------------+ ]]>

The steps shown in are:

• 1) The CI-CD platform schedules a workload (pipeline or task). Based on configuration a Workload Identity is made available by the platform.
• 2) The workload uses the identity to federate to a Identity Provider.
• 3) The workload uses the federated identity to access resources. For instance, a artifact store to upload compiled binaries, or to download libraries needed to resolve dependencies. It is also common to access other infrastructure as resources to make deployments or changes.

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

Security Considerations All security considerations in section 8 of apply.

Credential Delivery

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. This approach should be limited to non-production cases where convenience outweighs security considerations, and the provided secrets are limited in validity or utility. For example, an initial secret might be used during the setup of the application.

Filesystem

• 1) Access control to the mounted file should be configured to limit reads to authorized applications. Linux supports solutions such as DAC (uid and guid) or MAC (e.g. SELinux, AppArmor).
• 2) Mounted shared memory should be isolated from other host OS paths and processes. For example, on Linux this can be achieved by using namespaces.

Local APIs TODO Reference to attestation might be handy here

Token typing Issuers SHOULD strongly type the issued tokens to workload via the JOSE typ header and Identity Providers accepting these tokens 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 is 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. But other branches may not be 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 document, 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 tokens when the workload stops, pauses or ceases to exist. How these credentials are invalidated depends on platform authentication mechanisms and is not in scope of this document.

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.

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, Justin Richer, Pieter Kasselmann, Simon Canning, Evan Gilman and Joseph Salowey.

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. 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] 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. 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. 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. 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. 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. 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. Informative References Self-Issued Consulting Ping Identity Disney This specification updates the requirements for audience values for tokens whose audience is an OAuth 2.0 authorization server to address a security vulnerability identified in the previous requirements for those audience values in multiple OAuth 2.0 specifications. 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 CyberArk 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. Workload A can call Workload B with mutual TLS authentication, while the next call from Workload B to Workload 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.

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 ]] -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