Description

This is the first PR in a series of PRs for ROX-20100.

The goal of ROX-20100 is to provide users with the ability to exchange their identity tokens from third-party OIDC providers for a Central access token, without requiring to create an API token integration.

The most prevalent use-case we currently have in mind is for things like Continuous integration environments (e.g. GitHub actions). For more details on the overall feature, its envisioned use-cases and scope, see the ticket.

The first PR in the series establishes the proto API spec, as well as the service, datastore, and store layer. The name of the API is now /v1/auth/m2m, where m2m stands for machine to machine, as this is in theory the auth flow being used (since we envision this to be used primarily by non-interactive flows, machine to machine fits).

The configuration currently consists of:

• a specific type, defaulting to GitHub actions or providing a different issuer.
• a list of mappings, where each mapping is essentially the equivalent of auth provider groups, where a key value from the identity token's claims will be mapped to a specific role.

The reason why a dedicated type for GitHub actions was used is: simplicity. This somewhat mirrors what we have for the Image integrations, where there is Docker generic but also all different types of image integrations.
This makes it easier to later on create this configuration from the API, without knowning e.g. the issuer for GitHub actions by searching through the docs.

The current scope of the PR is limited to establishing the API, datastore, service layer without actually implementing the token exchange yet, this will be done in the follow-up PR.

Checklist

• Investigated and inspected CI test results
• Unit test and regression tests added
• Evaluated and added CHANGELOG entry if required
• Determined and documented upgrade steps
• Documented user facing changes (create PR based on openshift/openshift-docs and merge into rhacs-docs)

If any of these don't apply, please comment below.

Testing Performed

Here I tell how I validated my change

• see the added unit tests on the datastore layer to test basic functionality.

Reminder for reviewers

In addition to reviewing code here, reviewers must also review testing and request further testing in case the
performed one does not seem sufficient. As a reviewer, you must not approve the change until you understand the
performed testing and you are satisfied with it.