 Ada Shankar, Product Manager for Trusted Artifact Signer, also called TAS, which is a product-ized six-store service on-premise. It requires a minimum of OpenShift 4.13 and above. And in addition to that, you also need to provide an OIDC identity provider, and I'll be using a Google account for this demonstration. Now, you need to create a Google OAuth client ID if you don't have one, and make sure to set the application type to web application. The redirected path should also be set. And once you do that, you can... Yeah, there you go. And then you just create. Now, in my case, I already have an OAuth ID, as you can see. And I'm going to save the client ID and also download the JSON file which has the secret. Now, we'll then take the secret and put it in a file, and that will come handy during the cosine. Admin, go to Operator Hub and then type in Trusted. You should see a tile for Red Hat Trusted Artifact Signer. Click it, and then click on Install. You will accept the defaults. As you can see, it's going to be installed in all the namespaces, and then press Install. And now, let's wait for the operator installation to complete. As operator has installed, so now let's go and view it under Installed Operators. Now, let's click on All Instances, and you'll notice that there's no services that have been deployed. Now, before we go ahead, we'll create a namespace for the Trusted Artifact Signer. And I'm going to just call it task-test. So this will be the namespace where we are going to create the task services. So as you can see, I'm under Task-test. I'll go to the operator, and under the Secure Sign tab, we'll go and click the Create Secure Sign to create all the task services. Now, we will switch to the YAML view because we need to change one thing, which is our OIDC provider. The Google account OAuth ID that we created. So we are going to change the YAML and put our client ID that we saved. There you go. And then we will change the OIDC issuer. In this case, it's accounts.google.com. So we'll change that in the top and also in the issuer URL. And now we will go back to the form view. There is everything else. We'll take the defaults for now and then say Create. And now if you go to All Instances, we should see the different six-store services all coming up, like FullCO, CTL, CTLog, Recore, and all that. Now we can see all the services are up and running. If you go under the Workloads Pods, we should be able to see the pods corresponding to different services are also in a running state. TAS also provides all the six-store client binaries for download. So you can download it to your laptop, unzip it, and then also set the execute bit. In my case, I put it all under my bin directory. So it's going to be in my path. So there you go. Now we're going to log in to the OpenShift using OC Login, and then make sure that we are in the TAS-Test project. Now what we are going to do is going to configure the shell environment and set a bunch of variables to the six-store service endpoints, like FullCO, Recore, as you can see. And also the OIDC issuer, as you can see, is set to accounts.google.com. Now the next thing we'll do is cosine initialize. This is to make sure that you can provide a path to the initial trusted root.json. It creates a target directory. This will contain the tough targets for verification, like the Recore public key, the FullCO certificate, and the certificate transparency log key. We're going to use Quake Container Registry. The TAS-Test repository is initially empty. Let's first log in from our command line to Quake.io. Okay, that's good. And then I'm going to push the busybox container image from my laptop to the registry, and we'll tag it, and then we'll push the image. Okay, that's done. Now, what we're going to do is create a variable that has the full image name with its digest, because you should always sign images based on their digest, like the ACH 256, rather than a tag, like colon latest, because you might sign something that you did not intend to. Now, let's go check Quake and make sure that the pushed image is here. Let's reload the browser. Yes, and we see the latest image, and also we don't see any signatures, right? Now, we'll try to sign the container image that we pushed to Quake using cosine, and we'll pass the OAuth client ID secret that we saved in a file, and also the OIDC client ID. Now, the browser session will start, and it will ask you to log in to prove your identity. And as you can see, it's successfully been authenticated, and now that the verification has succeeded, it's going to create the signature, and at the same time, make an entry in the pre-core transparency log with the metadata for the signature and the timestamp. Now, let's check Quake to see if we have the signature, and if you can see there's a checkbox right on top of our image showing that it's been signed with cosine, and also let's do a show signatures, and we can see the signature file. And we can also checkbox cosine signature here. Yep. Now, let's go back and try to verify the signature, and we'll use cosine verify in this case. Let's clear the screen, cosine verify, and I use my redhat.com identity, which is a Google account, right? And to verify, so during the verification, basically it indicates that there is a signing record in pre-core, which basically that means there's been a validation of the root certificate, and also whether the signature was correct.