From 43c0d6495f628b543aa3ed149b7634f6e1f835b1 Mon Sep 17 00:00:00 2001 From: ID Bot Date: Mon, 4 Nov 2024 16:16:27 +0000 Subject: [PATCH] Script updating gh-pages from 21facf2. [ci skip] --- ...nt-assertion-in-workload-environments.html | 156 ++++++++++++------ ...ent-assertion-in-workload-environments.txt | 24 +-- 2 files changed, 120 insertions(+), 60 deletions(-) diff --git a/arndt/move_to_informational/draft-ietf-wimse-client-assertion-in-workload-environments.html b/arndt/move_to_informational/draft-ietf-wimse-client-assertion-in-workload-environments.html index c731558..d35b6f3 100644 --- a/arndt/move_to_informational/draft-ietf-wimse-client-assertion-in-workload-environments.html +++ b/arndt/move_to_informational/draft-ietf-wimse-client-assertion-in-workload-environments.html @@ -14,17 +14,17 @@ 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. Instead of manual provisioning these credentials the industry has moved to a federation-based approach where credentials of the underlying workload platform are used as assertions towards an OAuth authorization server leveraging the Client Assertion Flow , in particular . This specifications describes a meta flow in , gives security recommendations in and outlines concrete patterns in . " name="description"> - + issued by | | - | | | 1) get | Platform | | - | +--------------------------+ +-------------+ | + | | Workload <-----------> issued by | | + | | | 1) pull/ | Platform | | + | +--------------------------+ push +-------------+ | +----------------------------------------------------------+ Figure 1: OAuth2 Assertion Flow in generic Workload Environment @@ -171,8 +171,8 @@ Table of Contents pattern. * 1) retrieve credential issued by platform. The way this is - achieved and whether this is workload or platform initiated - differs based on the platform. + 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 @@ -449,12 +449,12 @@ A.1. Kubernetes | +----^----------------^------+ | | | | | | | | | - | 1) schedule 2) projected service | + | 1) schedule 2) projected service | | | account token | | | | | | +-----+----------------+-------------------+ | | | | | - | | Kubernetes Control Plane | | + | | Kubernetes Control Plane / kubelet | | | | | | | +------------------------------------------+ | | | @@ -731,9 +731,9 @@ A.4. Continuoues integration/deployment systems | | | Task (Workload) | | | - +--------^---------------------------+---------------------+ + +--------^---------------------------^---------------------+ | | - 1)schedules 2)retrieve identity + 1) schedules 2) retrieve identity | | +--------+---------------------------v---------------------+ | |