OpenShift Pipelines — the Tekton-based pipelines built into the Red Hat OpenShift platform — has been a reasonable build orchestrator for years. Pairing it with Sigstore for keyless artifact signing is what turns it into a defensible supply chain backbone for regulated workloads. The integration is genuinely good, but the patterns that survive a real audit and the patterns that survive a real attacker are not the patterns most teams start with. Sigstore's keyless model is unfamiliar to anyone who learned signing with GPG or with a single durable key in a Key Vault, and the temptation to "translate" the new model into the old patterns produces deployments that have the signing ceremony without the security properties. This is the integration guide for doing it in a way that actually pays off.
Why keyless signing in the first place?
The durable problem with traditional signing keys is that the key has to live somewhere, and wherever it lives is a target. HSMs reduce the attack surface but introduce operational overhead and cost. Storing the key in Vault reduces overhead but adds Vault to the trust base. Storing the key on the build agent is the path of least resistance and the worst posture. Sigstore's insight is that the key need not be durable at all. A short-lived signing certificate is issued to a workload identity (a Kubernetes service account, a CI runner's OIDC token) for the moment it needs to sign, used immediately, and discarded. The transparency log (Rekor) records the signing event so that anyone can later verify what was signed, by whom, when. The trust base becomes the certificate authority (Fulcio) and the transparency log, both of which can be replicated, audited, and operated by parties other than the signing organization.
How does the OpenShift Pipelines integration actually work?
A Tekton TaskRun running on OpenShift can authenticate to a Sigstore Fulcio instance using its service account's projected token. Fulcio validates the token against the cluster's OIDC discovery endpoint, confirms the workload identity, and issues a short-lived X.509 certificate whose subject encodes the workload identity (spiffe://cluster.local/ns/builds/sa/payments-builder, for example). The TaskRun uses that certificate to sign an artifact — a container image, an SBOM, an attestation — and uploads the signature, the certificate, and the signed payload to Rekor. Cosign or Notation tooling on the verifier side then validates the signature against the certificate, checks Fulcio's chain to its root, verifies the Rekor entry, and accepts or rejects based on the trust policy. The OpenShift-specific work is configuring the cluster as a recognized OIDC issuer to your Fulcio instance, configuring the projected token in the Task definition, and writing the Tekton step that invokes the signing tool.
apiVersion: tekton.dev/v1
kind: Task
metadata:
name: sign-image-sigstore
spec:
params:
- name: image
type: string
steps:
- name: cosign-sign
image: gcr.io/projectsigstore/cosign:latest
env:
- name: COSIGN_EXPERIMENTAL
value: "1"
script: |
cosign sign --yes \
--identity-token $(cat /var/run/sigstore/token) \
$(params.image)
Where should Fulcio and Rekor actually live?
Three plausible models, each with tradeoffs. The first is the public Sigstore infrastructure operated by the Sigstore project: zero operational burden, depended on by millions of artifacts, but a shared dependency that is outside your control and may not satisfy a regulator's data-residency or change-control requirements. The second is a self-hosted private Sigstore stack: full control over the trust base and the transparency log, full ownership of the operational burden, suitable for regulated environments where the public infrastructure is out of scope. The third is a hybrid: public Sigstore for general artifacts, private Sigstore for tier-zero artifacts (signing keys, root certificates, anything where the transparency log might leak information you do not want to publish). Most large enterprises in 2026 land on the hybrid model, with the private stack deployed on the same OpenShift cluster that runs the pipelines but in a separate namespace with restricted access.
What does the trust policy look like on the verifier side?
The verifier — typically OpenShift's image-policy admission controller or a separate Notation/Cosign-based gate — needs to know which Fulcio identities are trusted for which artifacts. The naive policy is "any certificate from our Fulcio is accepted," which means any service account on the cluster can sign anything. The realistic policy is identity-scoped: production payments images must be signed by spiffe://cluster.local/ns/payments-prod/sa/builder, observability images by the observability namespace's builder identity, base images by the platform team's builder. The policy is stored in a ConfigMap or a Kyverno policy, versioned in source, and enforced at admission. When identities change (team reorganizations, namespace migrations) the policy must be updated, which is the kind of change that benefits from being in source rather than in console clicks.
How does Rekor change incident response?
Rekor's transparency log is publicly verifiable, append-only, and searchable. The incident response benefit is that signing events can be queried by identity, by artifact hash, or by time range, and the queries return cryptographically verifiable evidence. If an attacker compromises a Tekton workload and uses it to sign a malicious artifact, the signing event is in Rekor. If the attacker then tries to backdate or hide the event, the log's append-only property reveals the tampering. The defender's playbook becomes: when a suspicious artifact is found in production, query Rekor for its hash, verify the signing identity and timestamp, and if the identity is unexpected (a service account in the wrong namespace, a sign timestamp outside the normal build window) treat it as an incident. Without Rekor, this evidence reconstruction depends on whatever logs the build cluster kept, which may have been tampered with by the same attacker.
What goes wrong in production rollouts?
Three recurring failure modes. The first is token leakage from build pods: a TaskRun's projected token is briefly available in the pod, and a compromised build step can read it and use it to sign arbitrary artifacts. The mitigation is to scope tokens narrowly (audience-restricted to Fulcio only, short TTLs), to ensure build steps that handle user-controlled input run in separate Tasks from signing steps, and to monitor Rekor for signing events outside normal build windows. The second is verification gaps: the signing pipeline works perfectly but the verifier is not enabled, or is enabled in audit-only mode, so unsigned or wrongly-signed artifacts still deploy. The mitigation is to test the verifier with deliberately failing artifacts during rollout. The third is trust policy drift: the verifier's allowed-identity list falls out of sync with the actual builder identities as teams reorganize, leading to either signing failures (which slow deploys) or overly permissive policies that nobody updated.
What does an audit see?
An auditor in 2026 evaluating your OpenShift Pipelines plus Sigstore deployment will want to see: source-controlled policy for trust criteria, source-controlled Task definitions for signing operations, an inventory mapping running images to their Rekor entries, evidence of regular verification of signatures against the trust policy, runbooks for trust-anchor rotation and signing-identity changes, and a record of how exceptions are handled. The actual security properties — keyless signing, transparency log auditability, identity-scoped trust — are valuable but secondary to the auditor's lens, which is "are you operating this discipline consistently." The signing technology is the easy part. The operational discipline is what matters.
How Safeguard Helps
Safeguard inventories every signing event from your Sigstore-integrated OpenShift Pipelines, correlating Rekor entries with the Tekton TaskRuns that produced them, the workload identities that signed, and the artifacts that landed in production. Policy gates block changes that loosen verifier trust criteria, that add unmanaged signing identities, or that disable signing in pipeline Task definitions. Griffin AI surfaces signing anomalies — events outside normal build windows, identities producing more signatures than usual, artifacts signed by unexpected service accounts — as part of the daily monitoring view, turning Rekor's audit value into operational signal. Continuous monitoring of trust policies, Fulcio CA health, and Rekor uptime means that the controls remain effective as teams, identities, and infrastructure evolve.