Signing an image

For sake of completeness, we can generate a public/private key pair with cosign - that would be part of the "trust root" certificate chain. Additionally, when signing, we can record the signing event in the Rekor Transparency database - but we would lose the association with an identity, as we can just prove that the image was signed by a key, not who signed it.

For generating a key pair (and all the automation options) see:

and for signing with a private key (and recording the signing event to rekor) see

We would sign using this parameter --key='': path to the private key file, KMS URI or Kubernetes Secret (with the key on file or in a secret or vault) like so

(the --tlog-upload=true is the default, but just to make it explicit).

The verification could still be without the need for a physical public key (by using the transparency log).

For using keyless signing (without the need for a physical private key accessible) we can use whatever means our OIDC system allows to generate an access token. Remember, fulcio (the Certificate Issuer) doesn’t care how you authenticate with your OIDC system, as long as you do.

So, we can pass an access token we have obtained from our OIDC system. This can be done with a "Confidential OIDC Client" - in other words, a client that works with a "Client Secret" and gives anyone access that has this client secret. Basically, a centrally managed "technical user".

Alternatively, (and much more flexible) we can use regular front-end authentication OIDC clients with any user from our OIDC system. So we could define different users for different CI chains or environments.

The crucial security consideration is - to obtain an access token, we need user credentials to pass to the OIDC system. These should be considered critical from a security perspective (same as the client secret above would be - or a physical private key, for that matter).

So, as a good practice, these should be stored in a vault or some other secure password management system.

Some CIs (such as Gitlab or Github) have a built-in authentication/access token that we can use.

If you have configured Trusted Artifact Signer with this OIDC system (if you followed the Setup Trusted Artifact Signer exercise, you will remember that you can configure more than one OIDC system), cosign can directly use it.

In the examples below, you might wonder why we’re not setting the SIGSTORE_OIDC_ISSUER environment variable (compare the output of the help statement in our terminal): .

When using the CI’s built-in identity token, you should NOT set SIGSTORE_OIDC_ISSUER - that would tell Cosign to do its own OIDC flow instead of using the CI token. The issuer is already embedded in the CI’s OIDC token:

The CI platform automatically embeds its issuer URL in the token claims, and Fulcio validates this against its trusted issuer list. So the workflow is:

You only use SIGSTORE_OIDC_ISSUER when you want Cosign to perform its own OIDC flow (like interactive browser login or own access tokens from a non-CI OIDC system), not when using CI identity tokens.

To verify a signature online (meaning, cosign has access to the Rekor database), we will use cosign verify:

With cosign verify we can verify that

(we add a | jq for better readability of the output)

(if you signed interactively with the admin user, you will get an error - use admin@demo.redhat.com instead)

But we just signed with our pipeline user, didn’t we? YES, but signatures are accumulative - we haven’t verified that this was the only signature - we have verified that it has at least one signature from user1@demo.redhat.com. If there are more than one, you can see the details in the cosign verify result.

But we have verified that this image has been signed by user1@demo.redhat.com

So, we can do the same for our pipeline user:

If we want to explicitly verify that the identity user1@demo.redhat.com was verified against our OIDC server and realm https://sso.{openshift_cluster_ingress_domain}/realms/trusted-artifact-signer, we can add the --certificate-oidc-issuer parameter:

and

We can also use regular expressions, using --certificate-identity-regexp and --certificate-oidc-issuer-regexp if we want to e.g. verify that the image was signed by a Red Hatter that authenticated against any OIDC system running on the redhatworkshops.io domain:

This regular expression "search pattern" will give us all signatures that it can validate and match. Since the output is JSON, we can also work with that to give us a table of signatures, their Rekor logIndex and the OIDC Issuer, since we could have multiple signatures from multiple identities from various OIDC systems…​

Some customers have asked how to verify keylessly signed artifacts in an offline scenario. One recent example is a customer using Trusted Artifact Signer throughout his CI and CD chains, up to pre-production.

The production systems however are completely isolated from the internal network and they transfer artifacts securely through what they call a "Diode". In other words, there is a secured way in - but nothing inside that environment can reach the outside.

Your customers may have similar challenges - or it could be as simple as:

In that case, there is only one major requirement: The current public trust root (what is stored under ~/.sigstore when we call cosign initialize and cosign requests the trust root from TUF) needs to be transported at least once during a root certificate lifecycle to the offline verification location.

As soon as the trust root is updated, this needs to be transported again - depending on the customer requirements for certificate management, between once a quarter and once a year (longer is not a good practice, the default TAS root certificate lifetime is one year).

With that said, we can verify without access to rekor via skipping the "tlog" == "transparency log" == Rekor verification.

Using a public key:

Using a keyless (certificate-based) signature:

The --insecure-ignore-tlog flag is the critical piece for offline verification, but this reduces the security guarantees that TAS/Sigstore normally provides.

Key compromise backdating is not really a concern with keyless/certificate-based signing (Sigstore/Fulcio) because of those short-lived certificates.

Let me clarify the difference:

For offline keyless verification, your main security checks are:

Without Rekor, you lose the independent timestamp proof and transparency, but the short certificate lifetime already prevents the backdating attack vector. Also, the signature contains a signed timestamp that will be verified against the timestamp authority’s public key included in the Trust Root.