Spike: Investigate registry v2 options for authn / authz

[ericwyles]

Is your feature request related to a problem? Please describe.

Need to investigate what options we have for authn/authz for registry v2 (or v3, an RC is out for it now) if we use it as internal registry. Need to be able to have fine grained control over access to the published images, at least by organization if not by individual image.

Solution needs to integrate with keycloak for auth.

Describe alternatives you've considered

Other registry options are also being researched and aren't captured here.

Additional context

Add any other context or screenshots about the feature request here.

[ericwyles]

Latest update:

Got authn working with docker registry v3 release candidate and UDS Core's keycloak with the following modifications (manual steps so documenting here for now so I can repeat them later)

1. Had to enable the docker protocol in keycloak. UDS Core doesn't enable it out of the box, I manually edited the statefulset to set cli arg --features=preview,docker
2. registry needs to be given the jwks certs (contents of /realms/uds/protocol/openid-connect/certs endpoint) in a file. It can't fetch that from keycloak, this is a whole different protocol, not oidc. Docker registry be weird.
3. Number 2 above only works with registry:3.0.0-rc.1 right now (I don't know how this was working for people before registry v3, I'm probably still missing something)
4. The kid format that keycloak issues and registry expects in the JWT are different and it still doesn't work after doing Number 2, but I was able to hack a copy of the jwks file to the kid format docker expects and then it worked.

Going to test the native docker+keycloak authz and then move on to authservice.

The above steps are only manually repeatable, will have to make changes to allow this to be automated if we go forward with it. Authservice way might not require any of the manual steps.

[ericwyles]

I checked in the current state of where I got with registry v2 here: https://github.com/ericwyles/docker-registry-playground

You can get it up and running in it's current state with uds run dev

That will do the following:

1. Launch a test cluster and create the doug user.
2. Patch the keycloak statefulset to enable the docker feature. (If we go forward with registry v2, we'll need a better way to enable this as part of the uds core install)
3. Wait for keycloak to restart
4. Create a new client in keycloak. clientId=docker-registry, protocol=docker-v2
5. Fetch the uds realm certs and save a pem of the 'uds' realm signing public key
6. Launch docker registry using docker compose, mounting a volume that contains the pem and wiring it as the root cert bundle.
7. docker login as doug to the newly launched registry and push an image

This handles authentication but authorizaton is wide open.

If we want to implement fine grained authorization to specific images, we need to implement a Keycloak protocol mapper to properly set the scope claims on the JWT to restrict access to specific registries/actions. See https://distribution.github.io/distribution/spec/auth/token/ for a good description of the protocol. Out of the box keycloak only includes an "Allow All" mapper which grants the user every scope they attempt to access.

I found an example mapper based on group membership and roles here: https://github.com/alexanderwolz/keycloak-docker-group-role-mapper/blob/main/README.md. We would need to do something similar to get authz working.

[ericwyles]

I am testing with https://github.com/defenseunicorns/uds-package-zot now as another option

[ericwyles]

Also opened an issue here for a problem I ran into with the registry v3 release candidate wired to keycloak distribution/distribution-library-image#179