[Wimse] Re: WIMSE Document Work

[Andrii Deinega <[e-mail]>]

Thank you, Justin and Hannes.

So just to share some of my thoughts on
draft-ietf-wimse-workload-identity-bcp-00 in an almost random order.

This document is well-written, and has provided plenty of food for thought
for me (that would be the very first one).

One might not want to rely on Kubernetes (or any other executor for
workloads) as an issuer of tokens if he/she does not have full control over
it, or does not have full visibility of what happens in it (let's say a
Kubernetes cluster managed by one or another Cloud provider).  That makes a
big difference with any system that implements SPIFFE (or something
conceptually similar), in which your own service issues tokens based on
attestation of a workload itself + what "runs" the workload (these ATs
later serve as the credentials for OAuth clients), etc.

SA ATs from Kubernetes provide a few additional security related
properties. The first one is that each instance of a workload gets its own
ATs and that gives us a way better visibility from many angles

   1. an AS sees which particular instance "calls" it when a workload
   consists of many instances (visibility is a way better than what you
   normally get say with client_secret).  In addition to that, it's always
   possible to inject additional useful information as clams.
   2. when a token gets stolen or lost, you get better chances to see who
   actually lost or leaked it.

Then, moving forward, Kubernetes as many of its flavors have a concept of
so called pod bound tokens, what that means is that when a pod dies, an AT
associated with it gets invalidated immediately.  This functionality has
some limitations though, it's available for those who use its TokenReview
API
<https://kubernetes.io/docs/reference/kubernetes-api/authentication-resources/token-review-v1/>
but
that's still something nice to have in the security toolbox.

It's a bit hard to use SA ATs when a workload is spread among a number of
Kubernetes clusters, you'll need to end up with a quite sophisticated logic
to validate tokens from all the clusters, and you also need to ensure your
JOSE & JWT library can properly handle multiple JWKS URLs.

I dare to say that client_assertion alone wouldn't be the best fit due to
the all the differences between a SA AT from Kubernetes and regular
"client_assertion" per RFC 7523
<https://datatracker.ietf.org/doc/html/rfc7523> or
https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication,
and what we can is to call it as "workload_assertion" and/or define a new
dedicated type for "client_assertion_type" (I mean in additional to
existing urn:ietf:params:oauth:client-assertion-type:jwt-bearer").

I also believe that the audience claim for an SA AT from Kubernetes should
include both a URL to AS and client_id as a countermeasure from abuse and
any mistakes.  I tend to think it's impossible to have the same name for
client_id and the service account in Kubernetes in most cases. One of main
reasons for that is that "client_id" is public and visible for all when you
use the authorization_code flow (one might not want to expose this info),
and another reason is that all the differences we have to deal with the
name conventions & constraints (Kubernetes as a bright example, requires
you to provide a service name as lowercase RFC 1123 subdomain with lower
case alphanumeric characters).

All the best,
Andrii


On Mon, May 6, 2024 at 9:29 AM Justin Richer <[e-mail]> wrote:

> Hi Andrii,
>
> The repository has been initialized, and the editors are importing the
> existing text now. Importantly, the issue tracker is now available:
> https://github.com/ietf-wg-wimse/draft-ietf-wimse-workload-identity-bcp/issues
>
>
>
> — Justin
>
> On May 3, 2024, at 3:25 PM, Andrii Deinega <[e-mail]>
> wrote:
>
> Hi Justin,
>
> Where is the home for
> https://datatracker.ietf.org/doc/draft-ietf-wimse-workload-identity-bcp?
>
> It belongs to https://github.com/ietf-wg-wimse/, that is right?  If
> so... it should be
> https://github.com/ietf-wg-wimse/draft-ietf-wimse-workload-identity-bcp
> but it's still empty.
>
> I did quite an extensive research on this matter, and as an outcome of
> it, got some suggestions, concerns + questions, etc.
>
> Thank you.
>
> All the best,
> Andrii
>
> On Fri, May 3, 2024 at 10:30 AM Justin Richer <[e-mail]> wrote:
>
>
> Hi WIMSE WG,
>
> While the design teams are cranking away at their assignments, the chairs
> just wanted to remind everyone that we’ve also got a few other items
> floating around for your consideration and attention.
>
> First, the WIMSE Architecture draft has been imported into the group’s
> GitHub repository, and you can find the source and issue tracker for that
> here: https://github.com/ietf-wg-wimse/draft-ietf-wimse-arch
>
> Please read, comment, file issues, and all that. The current editors copy
> shows up here:
> https://ietf-wg-wimse.github.io/draft-ietf-wimse-arch/draft-ietf-wimse-arch.html
> and you can view all other branches for PRs and the like at the root page
> here: https://ietf-wg-wimse.github.io/draft-ietf-wimse-arch/
>
>
> Additionally, there’s been one I-D submitted in the last few weeks that we
> wanted to make sure everyone saw it. This is not a WG document but was sent
> to the list in another thread, so we wanted to make sure it wasn’t missed
> by those who might want to read it and comment on it:
> https://datatracker.ietf.org/doc/draft-liu-wimse-secure-service-to-service-traffic/
>
> Thanks everyone, and looking forward to seeing you all in a few weeks at
> the interim!
>
> — Justin
>
> --
> Wimse mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/wimse
>
>
>