Setup TPA on OpenShift

ODF is pre-installed in your environment. ODF is part of OPP (OpenShift Platform Plus), so we expect customers to use it for production-grade S3.

With ODF installed, all you need to do is create an ObjectBucketClaim CR. We have prepared that for you in the /prerequisites folder, so:

The resulting output should resemble the following sample:

Using the same realm as other applications, we share the same user base.

Applications might have different requirements for authentication, though. Therefore, it is a good practice to define one or more clients for each application that allows the users of a given realm to authenticate.

For the realm we’re about to use, we have a set of default clients (for typical OIDC and Keycloak use cases) as well as a client for Trusted Artifact Signer, one for Red Hat Developer Hub and one for OpenShift.

We will add new clients for TPA later on (we’ll name them tpa-frontend and tpa-cli). We need to do some setup first. Once the clients are added, it will look like this:

In addition to Clients, TPA uses Client Scopes for authorization. In other words, depending on the client scopes associated with a user, it determines what a user can and cannot do.

TPA uses the following custom OIDC client scopes:

We need to create and assign these scopes to individual users or groups of users. We do this by creating roles with a mapping of client scopes and then assign those roles to users or groups.

A typical mapping could be:

Adding Client Scopes & Roles

We should first add the roles, then the client scopes. After adding the client scopes, we also need to make them available to the clients. We have client files prepared for you. However, if you import the client files first (which has the client scopes assigned already), these assignments will be ignored, since the scopes are not yet available on the system (they’re not added automatically), so we need to add the client scopes first.

In your {openshift_console_url}/terminal[terminal^,window="terminal"], go to the prerequisites folder and run the get-keycloak-info.sh script, which will give you the admin login details for the Keycloak Management Console:

Roles

Using the credentials from the output of the get-keycloak-info.sh script, (1) visit the Keycloak Admin Console and login. Select the Trusted Artifact Signer realm (by clicking on the dropdown in the top left), then (2) click on Realm Roles, then (3) Create role:

Create the roles:

Client Scopes

In the same (1) Trusted Artifact Signer realm, (2) click on Client Scopes, then (3) Create client scope:

Create the scopes read:document create:document update:document delete:document and give them a description, if you want.

Now, open each scope you created, and assign a role under the Scope tab:

Assign your tpa-* roles to the read:document scope

Continue assigning the roles to the client scopes as follows:

Users

Now that we have the client scopes and assigned those to specific roles, we need to assign those roles to our users (or, in a production environment, more likely to groups of users).

In the same realm (1) go to users (2) and click on user1 (3):

Click on the Role Mapping tab (4) and then Assign Role (5) and assign the tpa-user role to user1:

You should see the assigned role now:

Now do the same for the admin user and assign the tpa-admin role to that user:

Clients

Now that we have the client scopes, have assigned these to new roles that we created and assigned those roles to users, we need the clients that provide us with the authentication endpoints for TPA:

In the same realm (1), go to Clients (2). Here, you could create the clients manually and configure them (especially the client scopes that we need associated with this client) - but we have created import files for you, so you can instead use Import Client (3).

We need a frontend client that will handle the authentication with the UI and a cli client that we will use as a technical user, or in Keycloak terminology, as a Service Account (not to be mistaken with a k8s ServiceAccount). Basically, it is a user with a set password to be used for service-to-service communication.

Please download the following files to your machine and inspect them:

Frontend

First import the client_tpa-frontend.json file (click Browse…​ and select the file you downloaded) - it will populate all the fields and options that we need, then click "save".

CLI ("Service Account")

Now, import the CLI client. When you do, you will notice that the Client Authentication is switched on (to access this client, the user will have to provide the client secret) and the service account roles box is ticked, meaning that this will generate a technical user that we can assign roles (remember, we need the roles for the client scopes that tell TPA what the user is allowed to do).

After saving, you can see in the Credentials tab, that the client has a client secret assigned.

Now, go to the Service Accounts Roles tab and assign the tpa-admin role to the service account (unless you want to restrict what can be done via the client).

Last, but not least, we need to create a k8s secret for the client secret that is referenced in the helm chart (and the operator-install).

If you haven’t changed the client secret from the imported client_tpa-cli.json file, you can go to the {openshift_console_url}/terminal[terminal^,window="terminal"] and use the secret-oidc-cli.yaml we have prepared for you:

After opening the route URL, logging in as {openshift_admin_user} / {openshift_admin_password}, you should see the TPA UI ✅:

To verify the CLI (REST API) connectivity, go to the {openshift_console_url}/terminal[terminal^,window="terminal"] and inspect the verify-sbom-upload.sh we prepared for you:

The verification is quite straightforward:

In the same way, you would use that in a CI Task, uploading an SBOM that has just been generated.

Now, let’s do this:

You should see this now in your TPA instance after a few moments, including the labels we assigned ✅.

So, you can open your helm-based install of TPA now from here, and logging in as {openshift_admin_user} / {openshift_admin_password}, you should see the TPA UI based off of the student-tpa-helm namespace ✅:

We have prepared the verification script in the tpa-helm directory as well:

So, we should see the uploaded SBOM now in the TPA SBOM View after a few moments, including the labels we assigned ✅.