1. Open the Terminal

2. Terminal Setup

Since the default terminal doesn’t come with the binaries (cosign, gitsign) and a git without any configuration, we have prepared a script that

Feel free to inspect the script on GitHub before executing it in the terminal session you just opened:

Before we continue to clone a repository, modify code and sign our commits, let’s take a quick look at what the script has done:

Aside from downloading the cosign and gitsign binaries that are needed (more below), we have configured our git environment to sign each commit via gitsign:

This section tells git to use gpg-style signing (similar to the "traditional" private key based signing), the format (x509) and which program should provide the key/certificate. In our case, this is gitsign (that we just downloaded and put into the path).

This section tells gitsign where the various endpoints are, so it can request a signing certificate and where it can store the signing event metadata.

The last command the script issued was cosign initialize - this downloads the current root certificate from the "TUF" (The Update Framework) endpoint and displays what it downloaded and validity / expiration information. This is the so-called "Trust Root" that is needed to e.g. verify that a valid signature’s certificate is also part of the trusted certificate chain, that the signed timestamp’s signature (and thus the timestamp itself) is valid, etc. This is all managed through "TUF" - in other words, you don’t have to worry about all that.

Since we want to sign code commits, we need some code to work on.

As Developers, let’s go back to the parasol-store app, clone it and create a branch to work on. If you like, you can go back to parasol-store on GitLab, create a branch and copy the https URL manually - but we can also do it quickly via commandline:

The result should look like this:

Now we make a small modification so that we have something that we can commit. Feel free to modify any file (as long as it doesn’t break the build later) using vim or nano.

For sake of simplicity, we’ll just add an empty file and then use git add . to stage any modification for commit:

Now we can commit our change with an appropriate commit message (you can of course modify the commit message if the one below is too bland):

And here something unexpected happens (if you have used git on the commandline before) - you’re asked to copy a URL to a browser…​

This is because here in the workshop the gitsign binary is running in a shell that doesn’t have a browser installed (error opening browser: exec: "xdg-open": executable file not found in $PATH).

If you ran this on your machine, it would directly open your favourite browser.

But either way - the point is that you need to prove who you are - by simply logging into e.g. your company SSO. Depending on your SSO (OIDC) system, this could be username and password, as in our example - or a hardware key or whatever you are using on a daily basis to prove that you are who you say you are.

So, copy the full URL into a browser window (depending on your browser, you might see "open in new tab" after selecting the full URL in the terminal).

Use dev1 and {common_password} to authenticate.

Now copy the full code (best to use <ctrl><a> since the code is longer than the field) and paste it back into your terminal session (and remember, developers don’t have to do that unless they are working on a remote ssh session).

WE HAVE SIGNED OUR COMMIT 😃👏

Now we just need to push it (including the new branch) to our repository:

Before we augment our pipelines to block unsigned commits, let’s look at some manual way to look at the authenticity and metadata associated with a signed code commit.

1) via GitLab UI

You will notice that

2) via git log --show-signature

git log --show-signatures shows us all git commits, including signature metadata.

3) via gitsign verify

As the output above tells us, git verify-commit or the git log command verify that the signature is valid - but they don’t validate the claims embedded in the certificate for additional security. In our case, the signer identity and the OIDC system that verified the identity:

4) via the Transparency Log (rekor)

While mostly being used by the various CLI tools for storing and verifying signing events, you can open the Rekor UI and search for signer’s emails, uuids - or the index (you have seen entries like tlog index: 1 during signing and verification. tlog is the Transparency Log a.k.a. Rekor)

Ok, now that we have seen how developers would sign their commits - it’s time to think about to leverage that as a security guardrail:

1.) In Chapter 4.4, we imported a software template that creates a dev environment for developers so that they can start working on a parasol-store feature branch. This template includes a pipeline that builds the feature branch code and patches the ArgoCD deployment to immediately deploy what the developer has just built (see Chapter 4.5):

How about we added a check if the commit had been signed?

We don’t want to break the build necessarily, but here’s the thing:

So, let’s add that task:

As mentioned above, the pipeline is provisioned by the "Parasol Store Development" template - since it is our responsibility as Platform Engineers to continuously evolve those templates based on developer requirements and company policies - we’ll do the following:

1) We have prepared a template that adds the commit verification - as Platform Engineers, you could also evolve the existing template and add functionality to it. For this workshop, we’ll take the easy path (instead of modifying an existing template).

2) We’ll use the branch with our signed commits that we created earlier and instantiate a new development environment with that new template

3) We’ll add another signed commit and see what happens.

We’ll follow the same steps we did in Chapter 4.5 (working on a feature branch) - but this time, our pipeline will have git commit verification built in!

Since we already created a parasol-store branch (new-feature-with-signed-commits) above via commandline - we’ll simply use that.

1) Go to the "Self-service" section of Red Hat Developer Hub here - or click the (+) icon in the Red Hat Developer Hub top navigation header.

2) Use the template:

3) Click "Open Component in Catalog" (or click here)

After a few moments, the ArgoCD job will kick off the first pipeline run (-init-) in your new environment. However, the first run after instantiating template will look exactly like the pipeline runs with the other template. Why is that?

At this point in time, we’re not using a trigger (like a trigger on a git push), but just doing the bare minimum, so a developer has a running deployment in his development environment. Good for quick tests.

However, once we actually push our commits, something different happens.

Ok, now let’s go back to our terminal and again sign a commit, then push it.

As a result, we will now see our pipeline run and succeed:

When you click on the verify-commit task to see its log, you can see that we checked if it had been signed by the person pushing it.

Lastly, let’s see what happens with an unsigned commit - for that, we’ll quickly edit the this-is-an-empty-file.txt in GitLab here and commit the change with a meaningful message, such as adding "unsigned commit" to the default message:

As expected, the pipeline has been triggered by the commit - and fails, as it should: