Signing and Provenance

Set the environment variable required for this lab’s self-signed TLS certificate:

export COSIGN_INSECURE_SKIP_TLS_VERIFY=true

Initialize cosign with the lab’s private Trusted Artifact Signer root. By default cosign uses the public sigstore.dev infrastructure — this step points it at the lab’s self-hosted Rekor and Fulcio instances:

curl -sSLk https://tuf-tsf-tas.apps.cluster-%GUID%.example.com/root.json -o /tmp/tuf-root.json
cosign initialize --mirror https://tuf-tsf-tas.apps.cluster-%GUID%.example.com --root /tmp/tuf-root.json

Confirm your image digest is set from Module 3. If you are continuing in the same terminal session it will already be present. If not, paste the digest you copied from the build-container task results:

if [ -z "${IMAGE_DIGEST}" ]; then
  echo "IMAGE_DIGEST not set — enter the sha256 digest from Module 3:"
  read -r IMAGE_DIGEST
  export IMAGE_DIGEST
fi
echo "Digest: ${IMAGE_DIGEST}"

Retrieve the base image path and construct the full digest-pinned reference:

export IMAGE_BASE=$(oc get component \
  -n {openshift_username}-tenant \
  -o jsonpath='{.items[0].spec.containerImage}' | cut -d: -f1)
export IMAGE="${IMAGE_BASE}@${IMAGE_DIGEST}"
echo "Image: ${IMAGE}"

Run cosign verify using the build pipeline service account identity pattern and the cluster OIDC issuer:

cosign verify \
  --certificate-identity-regexp 'https://kubernetes.io/namespaces/.*/serviceaccounts/build-pipeline-.*' \
  --certificate-oidc-issuer https://kubernetes.default.svc \
  ${IMAGE}

Verification for <image> --
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - Existence of the claims in the transparency log was verified offline
  - The code-signing certificate was verified using trusted certificate authority certificates

[{"critical":{"identity":...},"optional":{"Issuer":"https://kubernetes.default.svc","Subject":"https://kubernetes.io/namespaces/..."}}]

Figure 1. cosign verify — successful signature verification

Confirm the subject shown contains your tenant namespace and component name. The format is https://kubernetes.io/namespaces/{openshift_username}-tenant/serviceaccounts/build-pipeline-<component>; — this is the Kubernetes service account identity the Tekton pipeline ran as when it signed the image.

Inspect what cosign verified by re-running with --output json and piping to jq:

cosign verify \
  --certificate-identity-regexp 'https://kubernetes.io/namespaces/.*/serviceaccounts/build-pipeline-.*' \
  --certificate-oidc-issuer https://kubernetes.default.svc \
  ${IMAGE} \
  --output json | jq '.[0] | {
    subject: .optional.Subject,
    issuer:  .optional.Issuer
  }'

Note that no --key flag was used. Keyless signing relies on the OIDC identity of the Tekton build service account rather than a static key pair. The Kubernetes API server (https://kubernetes.default.svc) acts as the OIDC issuer — it authenticates the service account at signing time and issues the short-lived certificate recorded in Rekor.

Count the attestations attached to your image. cosign download attestation outputs a stream of JSON objects — use the -s flag to slurp the stream into an array first:

cosign download attestation ${IMAGE} | jq -s 'length'

Identify the SLSA predicate version used by your cluster’s build pipeline. The predicateType field determines which field paths to use when extracting metadata:

cosign download attestation ${IMAGE} | jq -r '.payload | @base64d | fromjson | .predicateType'

Run the extraction command that matches the predicateType you saw in the previous step.

cosign download attestation ${IMAGE} | jq -s '
  map(select(.payload | @base64d | fromjson | .predicateType == "https://slsa.dev/provenance/v0.2")) |
  .[0].payload | @base64d | fromjson | {
    repo:        .predicate.invocation.environment.annotations["pipelinesascode.tekton.dev/repo-url"],
    commit:      .predicate.invocation.environment.annotations["build.appstudio.redhat.com/commit_sha"],
    builder:     .predicate.builder.id,
    pipelineRun: .predicate.invocation.environment.annotations["pipelinesascode.tekton.dev/log-url"]
  }'

cosign download attestation ${IMAGE} | jq -s '
  map(select(.payload | @base64d | fromjson | .predicateType == "https://slsa.dev/provenance/v1")) |
  if length == 0 then "No SLSA v1 attestations — your cluster uses v0.2 (run the command above)" else
  .[0].payload | @base64d | fromjson | {
    repo:        .predicate.buildDefinition.resolvedDependencies[0].uri,
    commit:      .predicate.buildDefinition.resolvedDependencies[0].digest.gitCommit,
    builder:     .predicate.runDetails.builder.id,
    pipelineRun: .predicate.runDetails.metadata.invocationId
  } end'

Confirm the repo field matches your GitLab repository URL from Module 2.

Confirm the commit field matches the commit SHA from your code push in Module 3. Open GitLab and navigate to the commit history for your repository to verify the SHA.

Figure 2. GitLab commit history showing the commit SHA that matches the provenance attestation

Note the builder field. This is the Konflux pipeline service account identity that performed the build. The attestation was signed by that identity — meaning it is as trustworthy as the signing certificate, which is backed by the OIDC issuer you verified in Section 1.

Retrieve the Rekor log entry for your image. The log entry is embedded in the cosign verification JSON output:

cosign verify \
  --certificate-identity-regexp 'https://kubernetes.io/namespaces/.*/serviceaccounts/build-pipeline-.*' \
  --certificate-oidc-issuer https://kubernetes.default.svc \
  ${IMAGE} \
  --output json | jq '.[0].optional.Bundle | {
    logIndex:        .Payload.logIndex,
    integratedTime:  .Payload.integratedTime,
    signedTimestamp: .SignedEntryTimestamp
  }'

Note the logIndex value. This is a monotonically increasing integer — each entry added to the log receives the next available integer. Any gap in the sequence would be detectable by independent log monitors.

Note the integratedTime value. This is a Unix timestamp for when the entry was added to the log. Confirm it is close to when your PipelineRun completed in Module 3.

Switch to the Rekor tab. Select the hash attribute, enter the digest portion of $IMAGE (the sha256:…​ value, without the registry prefix), and search.

Figure 3. Rekor Search UI showing transparency log entries for the signed image

Reflect on the tamper-evident property: if an attacker compromised the image registry and replaced the image bytes, the digest in the registry would change. Any consumer running cosign verify would see a signature mismatch — the signature covers the original digest, not the replacement. The Rekor entries remain, proving what the original image contained and when it was signed.

Cosign claims validated — the signature is mathematically valid for the image digest. Any change to the image bytes produces a different digest and invalidates the signature.

Existence in the transparency log verified offline — the signing event was recorded in Rekor and the log entry matches the signature. This step works without contacting Rekor directly, using the signed timestamp embedded in the cosign bundle.

Code-signing certificate verified — the short-lived certificate was issued by a trusted certificate authority (Fulcio) for the expected OIDC identity. This confirms the signer was the legitimate Tekton Chains service account, not an impostor.