From 73f41b563a72b95192e8f00903653ffbb40d9603 Mon Sep 17 00:00:00 2001 From: ID Bot Date: Mon, 8 Jul 2024 14:09:50 +0000 Subject: [PATCH] Script updating gh-pages from ef4a18f. [ci skip] --- ...raft-ietf-wimse-workload-identity-bcp.html | 1540 +++++++++++++++++ ...draft-ietf-wimse-workload-identity-bcp.txt | 424 +++++ .../index.html | 45 + index.html | 8 + 4 files changed, 2017 insertions(+) create mode 100644 draft-ietf-wimse-workload-identity-bcp-01/draft-ietf-wimse-workload-identity-bcp.html create mode 100644 draft-ietf-wimse-workload-identity-bcp-01/draft-ietf-wimse-workload-identity-bcp.txt create mode 100644 draft-ietf-wimse-workload-identity-bcp-01/index.html diff --git a/draft-ietf-wimse-workload-identity-bcp-01/draft-ietf-wimse-workload-identity-bcp.html b/draft-ietf-wimse-workload-identity-bcp-01/draft-ietf-wimse-workload-identity-bcp.html new file mode 100644 index 0000000..9622fa2 --- /dev/null +++ b/draft-ietf-wimse-workload-identity-bcp-01/draft-ietf-wimse-workload-identity-bcp.html @@ -0,0 +1,1540 @@ + + + + + + +Best Current Practice for OAuth 2.0 Client Authentication in Workload Environments + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Internet-DraftWorkload IdentityJuly 2024
Hofmann, et al.Expires 9 January 2025[Page]
+
+
+
+
Workgroup:
+
WIMSE
+
Internet-Draft:
+
draft-ietf-wimse-workload-identity-bcp-latest
+
Published:
+
+ +
+
Intended Status:
+
Standards Track
+
Expires:
+
+
Authors:
+
+
+
B. Hofmann
+
Siemens
+
+
+
H. Tschofenig
+
Siemens
+
+
+
E. Giordano
+
Nokia
+
+
+
Y. Rosomakho
+
Zscaler
+
+
+
A. Schwenkschuster
+
Microsoft
+
+
+
+
+

Best Current Practice for OAuth 2.0 Client Authentication in Workload Environments

+
+

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.

+
+
+ +
+
+ ▲

+Table of Contents +

+ +
+
+
+
+

+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.

+

"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.

+
+
+
+
+                      +---------------+
+                      |               |
+                      | 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 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. +
  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. +
  3. +

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

    +
    4. +
  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.

    +
    5. +
+

The following fields are populated in the Service Account Token:

+
    +
  1. +

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

    +
    2. +
  2. +

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

    +
    3. +
  3. +

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

    +
    4. +
+

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, , <https://www.rfc-editor.org/rfc/rfc2119>.
+
+
[RFC6749]
+
+Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, , <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, , <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, , <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, , <https://www.rfc-editor.org/rfc/rfc8414>.
+
+
+
+
+
+
+

+7.2. Informative References +

+
+
[OIDC]
+
+Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0 incorporating errata set 1", , <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. +
  2. +

    the expiration of the token in seconds

    +
    3. +
  3. +

    the audience, which will be in the Service Account Token

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

The full configuration is shown below:

+
+
+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:

+
+
+{
+  "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. +
  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

    +
    3. +
+

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

+

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

+
    +
  1. +

    The 'jti' claim is mandated for client authentication.

    +
    2. +
  2. +

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

    +
    3. +
+

[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
+ +
+
+
Hannes Tschofenig
+
Siemens
+ +
+
+
Edoardo Giordano
+
Nokia
+ +
+
+
Yaroslav Rosomakho
+
Zscaler
+ +
+
+
Arndt Schwenkschuster
+
Microsoft
+ +
+
+
+ + + diff --git a/draft-ietf-wimse-workload-identity-bcp-01/draft-ietf-wimse-workload-identity-bcp.txt b/draft-ietf-wimse-workload-identity-bcp-01/draft-ietf-wimse-workload-identity-bcp.txt new file mode 100644 index 0000000..5a36e35 --- /dev/null +++ b/draft-ietf-wimse-workload-identity-bcp-01/draft-ietf-wimse-workload-identity-bcp.txt @@ -0,0 +1,424 @@ + + + + +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-latest + +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. + +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. Terminology + 3. Recommendations + 4. Security Considerations + 5. IANA Considerations + 6. Acknowledgements + 7. References + 7.1. Normative References + 7.2. Informative References + Appendix A. Example + Authors' Addresses + +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. + + "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. + + +---------------+ + | | + | 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 + 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]. + + 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, + . + + [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", + RFC 6749, DOI 10.17487/RFC6749, October 2012, + . + + [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, . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 + Authorization Server Metadata", RFC 8414, + DOI 10.17487/RFC8414, June 2018, + . + +7.2. Informative References + + [OIDC] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and + C. Mortimore, "OpenID Connect Core 1.0 incorporating + errata set 1", November 2014, + . + +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: + + 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: + + { + "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. + + 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 diff --git a/draft-ietf-wimse-workload-identity-bcp-01/index.html b/draft-ietf-wimse-workload-identity-bcp-01/index.html new file mode 100644 index 0000000..7045d8f --- /dev/null +++ b/draft-ietf-wimse-workload-identity-bcp-01/index.html @@ -0,0 +1,45 @@ + + + + ietf-wg-wimse/draft-ietf-wimse-workload-identity-bcp draft-ietf-wimse-workload-identity-bcp-01 preview + + + + +

Editor's drafts for draft-ietf-wimse-workload-identity-bcp-01 branch of ietf-wg-wimse/draft-ietf-wimse-workload-identity-bcp

+ + + + + + +
Workload Identityplain textsame as main
+ + + diff --git a/index.html b/index.html index 19e2b1a..75c2254 100644 --- a/index.html +++ b/index.html @@ -24,6 +24,14 @@

Editor's drafts for main branch of draft-ietf-wimse-workload-identity-bcp-01

+ + + + + + +
Workload Identityplain textsame as main

Preview for branch draft-ietf-wimse-workload-identity-bcp-00