Cosign and the Sigstack — what cosign does, the broader Sigstore ecosystem

cosign is the signing tool the Sigstore project ships. The Sigstore project is the broader ecosystem: cosign, Fulcio (the certificate authority), Rekor (the transparency log), policy- controller (the verifier side for Kubernetes), and gitsign (the Git-commit signing extension). Each of the components plays a distinct role in the chain of trust; each project has its own release cadence and its own failure mode.

The Sigstore component map

The Sigstore stack has three primary components and a set of adjacent projects. The map is the same shape whether the deployment uses the public-good instance or a self-hosted instance:

• cosign. The CLI. Signs OCI artifacts (images, SBOMs, attestations), verifies, attaches attestations, and bundles signatures into the registry alongside the artifact.
• Fulcio. The certificate authority. Issues short-lived X.509 certificates bound to an OIDC identity. The certificate says “this signing key was controlled by this OIDC subject during this time window”.
• Rekor. The transparency log. An append-only ledger of signed public statements. Every signature is recorded; the log is the tamper-evident record.
• policy-controller. The Kubernetes admission controller that rejects pods whose image signature does not verify against a configured policy. The verifier side.
• gitsign. A cosign extension that signs Git commits with a Sigstore-issued key, replacing GPG-signed commits with OIDC-bound signatures.

flowchart LR
    A["cosign"] --> B["OCI artifact"]
    A --> C["Fulcio"]
    A --> D["Rekor"]
    C --> E["Short-lived cert"]
    D --> F["Transparency log"]
    E --> G["Signature"]
    F --> G
    G --> H["Registry"]
    H --> I["policy-controller"]
    I --> J["Admit"]
    I --> K["Deny"]

The relationships are simpler than they look. cosign is the front-end; Fulcio and Rekor are the back-end the front-end talks to. The registry stores the result; the policy-controller inspects the result on every pull.

The simplest flow: keypair signing

The canonical starting point is keypair signing. The team generates a keypair, signs with the private key, publishes the public key, and the verifier checks against the public key:

cosign generate-key-pair
cosign sign --key $KEY_PATH image:$DIGEST
cosign verify --key $KEY_PATH image:$DIGEST

Three properties of the keypair flow:

• Complete control. The team holds the private key; no third party signs.
• Long-lived risk. A leaked private key is a key that must be rotated, and every verifier must be updated with the new public key.
• No identity binding. The key is opaque; the verifier knows the signer is the holder of the private key, not which CI workflow or which engineer.

The keypair flow is the right starting point for a lab or a PoC. The production flow is keyless, which the next lesson covers.

The keyless flow: cosign + Fulcio + Rekor

The keyless flow uses the OIDC token from CI as the signing authority. The flow is the same shape, but the components shift in role:

• cosign reads the OIDC token from the CI environment.
• Fulcio issues a short-lived certificate naming the OIDC subject.
• Rekor records the signature in the transparency log.
• cosign signs the digest with the per-run ephemeral key.

The verifier side inverts the process: pin the expected OIDC subject, fetch the certificate from the signature, check the cert against Rekor, accept if the cert is valid for the OIDC subject and the log includes the entry.

cosign sign --keyless image:$COMMIT_SHA
cosign verify --keyless --certificate-identity $CERT_IDENTITY \
    --certificate-oidc-issuer https://token.actions.githubusercontent.com \
    image:$DIGEST

The two commands are the same shape, but the verification inverts the trust: the verifier trusts Fulcio and Rekor, not a private key.

Adjacent projects: gitsign and policy-controller

The Sigstore project extends beyond containers:

• gitsign signs Git commits with a Sigstore-issued OIDC certificate. The Git commit is bound to the OIDC subject (the CI workflow), not to a GPG key. The replacement is drop-in for git’s commit-signing workflow.
• policy-controller is the Kubernetes admission controller that verifies Sigstore signatures on every image pull. The policy is ClusterImagePolicy resources; the cluster rejects pods whose images do not satisfy the policy.

The two projects are the verifier side of the cosign + Fulcio

• Rekor stack. The signing side is in the CI; the verification side is in the cluster.

Production discipline

1. Use cosign for OCI artifacts. The format is the same shape as the registry; there is no new storage to operate.
2. Default to keyless; fall back to keypair for self-hosted CI without OIDC. The keyless flow is the recommended path for any CI provider that issues OIDC tokens.
3. Pin either the public key or the OIDC subject in the verifier. A verification policy without a pin is no policy.
4. Deploy the verifier at the deployment boundary. The policy-controller, kyverno, or a CI gate.

Cross-course references

• Git, CI/CD & GitOps — Part LIII-06 (Image Signing in CI) is the predecessor; LXIX-02 extends the Sigstore-component map beyond cosign.
• Git, CI/CD & GitOps — Part LXVIII-04 (SBOM Distribution and Attestation) is the attestation half of the chain; LXIX-02 is the signature half.
• Container Security for Production Sysadmins — Part VII (Admission Control) is the verifier side; LXIX-06 deepens it.

Quiz