Best Current Practice for OAuth 2.0 Client Authentication in Workload Environments
draft-ietf-wimse-workload-identity-bcp-01

WIMSE                                                         B. Hofmann
Internet-Draft                                             H. Tschofenig
Intended status: Standards Track                                 Siemens
Expires: 9 January 2025                                      E. Giordano
                                                                   Nokia
                                                            Y. Rosomakho
                                                                 Zscaler
                                                      A. Schwenkschuster
                                                               Microsoft
                                                             8 July 2024

 Best Current Practice for OAuth 2.0 Client Authentication in Workload
                              Environments
               draft-ietf-wimse-workload-identity-bcp-01

Abstract

   The use of the OAuth 2.0 framework for container orchestration
   systems poses a challenge as managing secrets, such as client_id and
   client_secret, can be complex and error-prone.  "Service account
   token volume projection", a term introduced by Kubernetes, provides a
   way of injecting JSON Web Tokens (JWTs) to workloads.

   This document describes the current best practices to avoid
   client_secret provisioning and leverage platform attestation to
   receive access tokens from an OAuth 2.0 authorization server via RFC
   7523.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 9 January 2025.

Hofmann, et al.          Expires 9 January 2025                 [Page 1]
Internet-Draft              Workload Identity                  July 2024

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Recommendations . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Appendix A.  Example  . . . . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   In workload scenarios dedicated management entities, also referred to
   as "control plane" entities, are used to start, monitor and stop
   workloads dynamically.  These workloads frequently interact with each
   other and other entities within the corporate network or online.
   When one workload, acting as an OAuth client, wants to gain access to
   a protected resource hosted on another workload or on the Internet
   (referred here generically as a resource server) then authorization
   is typically required.

   To authenticate workloads accessing resources, each workload instance
   requires unique credentials.  This poses challenges in environments
   where workloads start, stop, relocate, and scale dynamically.  Manual
   configuration, rotation, and management efforts can result in
   management overhead at best and security risks such as credential
   exposure at worst.

Hofmann, et al.          Expires 9 January 2025                 [Page 2]
Internet-Draft              Workload Identity                  July 2024

   "Service account token volume projection" is a feature in the
   Kubernetes container orchestration system that enables users to
   attach platform-attested tokens to their workloads.  Workloads use
   these tokens to authenticate themselves to APIs within the platform's
   control plane.  While this token is used for access, it functions
   more like an ID Token rather than an Access Token in the OAuth
   context.  Workloads do not receive a refresh token, and there is no
   involvement of authorization or consent; it simply serves as proof of
   the workload's identity.  Workloads have several methods to obtain
   such tokens from Kubernetes, including through the TokenRequest API
   invoked by business logic or Token volume projection, which mounts
   the token into the workload's file system and ensures it remains up-
   to-date.  Token volume projection offers the advantage of requiring
   no manual intervention by the application beyond reading a file.

   Initially designed to authenticate access to the control plane API,
   the industry has recognized the service account token for its low
   maintenance and platform attestation capabilities and has started
   using it as a JWT client assertion, as specified in [RFC7523].  This
   token is presented to an authorization server as a client assertion.
   The authorization server validates the assertion's signature using
   [OIDC] metadata or [RFC8414] and uses the claims within the token to
   authenticate the client.  Overall, the authorization server trusts
   the platform control plane for issuing and delivering these
   credentials.  The authorization server then responds with an Access
   Token that the workload can use to access an OAuth2-protected
   resource on a resource server.

   Figure 1 illustrates the interaction in the architecture graphically.

Hofmann, et al.          Expires 9 January 2025                 [Page 3]
Internet-Draft              Workload Identity                  July 2024

                         +---------------+
                         |               |
                         | Authorization |
                         | Server        |
                         |               |
                         +---------------+
                                ^ |
                                | |
     +--------------------------|-|--------------+
     |Cluster                   | | OAuth        |
     |                          | | Exchange     |
     | +---------------+        | | to obtain    |
     | |               |        | | access token |
     | | Control Plane |        | | using        |
     | |               |        | | Service      |
     | +---------------+        | | Account      |
     |         ^|               | | Token        |
     |         ||               | v        +-----+
     |         ||            +----------+  |
     |         ||            |          |+ |        +----------+
     |  Obtain ||            | Workload || |        |          |
     |  Service||            |          ||<-------->| Resource |
     |  Account||            +----------+| | Access | Server   |
     |  Token  ||             +----------+ | Token  |          |
     |         ||                  ^       |        +----------+
     |         ||    Start Workload:       |
     |         ||     with Service :       |
     |         ||    Account Token :       |
     |         ||                  v       |
     |         ||              +-------+   |
     |         |+------------->|       |   |
     |         +---------------| Agent |   |
     |                         |       |   |
     |                         +-------+   |
     |                                     |
     +-------------------------------------+

                      Figure 1: Protocol Interaction.

   This specification defines the utilization of Service Account Tokens
   within container orchestration systems, providing a secure and
   scalable method for creating and managing these tokens while ensuring
   interoperability with existing OAuth-based authorization systems.

   To distinguish between entities, we refer to the OAuth 2.0
   Authorization Server within the cluster's control plane as the
   "Control Plane."  Given the presence of two distinct access tokens,
   we specifically designate the token issued by the Control Plane as

Hofmann, et al.          Expires 9 January 2025                 [Page 4]
Internet-Draft              Workload Identity                  July 2024

   the "Service Account Token," thereby differentiating it from the
   access token issued to an OAuth 2.0 client operating within the
   workload by a separate authorization server.

   In Section 3, further details are provided regarding the token
   content and the associated security properties.

2.  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 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   The terms 'workload' and 'container' are used interchangeably.

3.  Recommendations

   This specification relies on the use of OAuth 2.0 [RFC6749] and
   [RFC7523] for client authentication using a JWT.

   Service Account Tokens used in container orchestration systems are
   vulnerable to various threats, as outlined below:

   1.  Token theft: Attackers who compromise a workload can steal tokens
       to impersonate it and gain unauthorized access to resources.

   2.  Token reuse: Stolen tokens may be reused within their expiration
       period to gain repeated unauthorized access.  However, the
       expiration time limits the token reuse time window.

   3.  Misconfigured service accounts: mproperly configured service
       accounts can grant applications excessive privileges.

   4.  Theft of token signing key: Attackers gaining control plane
       access can steal the token signing key, akin to compromising
       client_id and client_secret in OAuth, potentially accessing all
       secrets in the orchestration system.

   The following fields are populated in the Service Account Token:

   1.  The 'iss' claim MUST contain a string identifying the worklod
       orchestrator.

   2.  The 'sub' claim MUST contain a string identifying the workload,
       also serving as the client_id per [RFC7523].

Hofmann, et al.          Expires 9 January 2025                 [Page 5]
Internet-Draft              Workload Identity                  July 2024

   3.  The 'aud' claim MUST identify one or multiple authorization
       servers intended to receive and authorize the Service Account
       Token.

   Additional processing requirements are specified in [RFC7523].

4.  Security Considerations

   This entire document is about security.

5.  IANA Considerations

   This document does not require actions by IANA.

6.  Acknowledgements

   Add your name here.

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
              RFC 6749, DOI 10.17487/RFC6749, October 2012,
              <https://www.rfc-editor.org/rfc/rfc6749>.

   [RFC7523]  Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token
              (JWT) Profile for OAuth 2.0 Client Authentication and
              Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May
              2015, <https://www.rfc-editor.org/rfc/rfc7523>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC8414]  Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
              Authorization Server Metadata", RFC 8414,
              DOI 10.17487/RFC8414, June 2018,
              <https://www.rfc-editor.org/rfc/rfc8414>.

7.2.  Informative References

Hofmann, et al.          Expires 9 January 2025                 [Page 6]
Internet-Draft              Workload Identity                  July 2024

   [OIDC]     Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
              C. Mortimore, "OpenID Connect Core 1.0 incorporating
              errata set 1", November 2014,
              <https://openid.net/specs/openid-connect-core-1_0.html>.

Appendix A.  Example

   The functionality described in this specification can be verified
   using Kubernetes.  Modern version of Kubernetes implement service
   account token volume projection, which enables the ability to inject
   the Service Account Token with a specific issuer and audience into
   the workload.

   A most important parts of the configuration are (which can be found
   at the end of the full configuration):

   1.  the path, where the application can find the token, as a file

   2.  the expiration of the token in seconds

   3.  the audience, which will be in the Service Account Token

   serviceAccountToken:
     path: token
     expirationSeconds: 7200
     audience: "https://localhost:5001/connect/token"

   The full configuration is shown below:

Hofmann, et al.          Expires 9 January 2025                 [Page 7]
Internet-Draft              Workload Identity                  July 2024

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: simpleapp
     labels:
       app: simpleapp
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: simpleapp
     template:
       metadata:
         labels:
           app: simpleapp
       spec:
         containers:
           - name: container1
             image: curlimages/curl:8.2.1
             imagePullPolicy: Always
             command:
               - sleep
               - "3600"
             env:
               - name: TOKEN_PATH
                 value: '/var/run/secrets/other_token/token/token'
             volumeMounts:
               - mountPath: '/var/run/secrets/other_token/token'
                 name: other-token-path
         volumes:
           - name: other-token-path
             projected:
               sources:
               - serviceAccountToken:
                   path: token
                   expirationSeconds: 7200
                   audience: "https://localhost:5001/connect/token"

   The most important parts of the token, which the workload will
   obtain, looks as follows:

Hofmann, et al.          Expires 9 January 2025                 [Page 8]
Internet-Draft              Workload Identity                  July 2024

   {
     "aud": [
       "https://localhost:5001/connect/token"
     ],
     "exp": 1691752299,
     "iss": "https://kubernetes.default.svc.cluster.local",
     "sub": "system:serviceaccount:test:default"
   }

   A complete token example obtained by the workload is shown below.

   {
     "aud": [
       "https://localhost:5001/connect/token"
     ],
     "exp": 1691752299,
     "iat": 1691745099,
     "iss": "https://kubernetes.default.svc.cluster.local",
     "kubernetes.io": {
       "namespace": "test",
       "pod": {
         "name": "simpleapp-5d7dcf96df-n7csk",
         "uid": "9fc443d7-5c7a-48d5-9679-0ee03b17d4c5"
       },
       "serviceaccount": {
         "name": "default",
         "uid": "0bea3006-fb60-49a3-bc80-7e6884d378ae"
       }
     },
     "nbf": 1691745099,
     "sub": "system:serviceaccount:test:default"
   }

   To enable the authorization server to use the Service Account Token
   for client authentication the following configuration is needed:

   1.  the client id is set to system:serviceaccount:test:default.  In
       our case we are using the default service account in the test
       namespace.

   2.  the public key of the token signing key.  This can be either
       configured manually, or dynamically by referencing the JWK
       endpoint Kubernetes exposes, which is
       https://kubernetes.default.svc.cluster.local/openid/v1/jwks

   Note: Authorization servers that follow the OpenID Connect Core
   specification, which profiles RFC 7523, will unfortunately run into
   problem.  Here is the why.

Hofmann, et al.          Expires 9 January 2025                 [Page 9]
Internet-Draft              Workload Identity                  July 2024

   For JWT-based client authentication [OIDC] specifies the following:

   1.  The 'jti' claim is mandated for client authentication.

   2.  The 'iss' claim must match the 'sub' claim.  Since Kubernetes
       issues the tokens, and not the workload, the two do not match.

   [RFC7523], on the other hand, does not mandate the use of a 'jti'
   claim and does not mandate that the 'iss' claim equals the 'sub'
   claim.

Authors' Addresses

   Benedikt Hofmann
   Siemens
   Email: hofmann.benedikt@siemens.com

   Hannes Tschofenig
   Siemens
   Email: hannes.tschofenig@gmx.net

   Edoardo Giordano
   Nokia
   Email: edoardo.giordano@nokia.com

   Yaroslav Rosomakho
   Zscaler
   Email: yrosomakho@zscaler.com

   Arndt Schwenkschuster
   Microsoft
   Email: arndts.ietf@gmail.com

Hofmann, et al.          Expires 9 January 2025                [Page 10]