Signing via Identity, Not Secrets
Sigstore is an open-source project (backed by Google, Red Hat, and Purdue University) that makes signing software as easy as logging into a website. Its core innovation is "keyless" signing — a term that means "no long-lived keys you have to manage," not "no cryptography."
Instead of generating a key pair and storing the private key forever, Sigstore generates ephemeral (short-lived) keys on-the-fly, tied to your identity (a Google, GitHub, or Microsoft account via OIDC). The private key exists for about 10 minutes and is then discarded. The proof of signing is recorded in a public, tamper-evident log.
The Three Components of Sigstore
- Cosign: The CLI tool you use to sign and verify container images and other artifacts.
- Fulcio: Sigstore's Certificate Authority. It verifies your OIDC identity and issues a short-lived X.509 certificate binding your identity to a temporary public key.
- Rekor: A public, append-only transparency log (similar in concept to Certificate Transparency logs used for TLS certificates). Every signing event is recorded here permanently.
The Keyless Signing Workflow
- Cosign generates a temporary key pair that lives approximately 10 minutes.
- Cosign redirects to an OIDC provider (GitHub, Google, Microsoft). The developer logs in and receives an OIDC token proving identity.
- Cosign sends the OIDC token to Fulcio, which verifies it and issues a short-lived X.509 certificate binding the identity to the temporary public key.
- Cosign signs the image digest with the temporary private key. The private key is discarded immediately after signing.
- Signature and certificate are uploaded to Rekor (a permanent, append-only transparency log). The signature is also attached to the image in the registry.
Verifying a Signed Image
Verifying an image with Cosign means checking the Rekor log and confirming: (1) the image was signed, (2) the signer's identity matches an expected pattern you specify — for example, a specific GitHub Actions workflow and its OIDC issuer — and (3) the image digest hasn't changed since signing. If any check fails, the command exits non-zero.
Enforcing Signatures in Kubernetes
Signing is only valuable if you enforce verification at deployment time. Policy controllers like Sigstore's Policy Controller or Kyverno can be installed as Kubernetes admission webhooks. They intercept every pod creation request and reject any image that doesn't have a valid, verified signature from a trusted identity — a Kyverno ClusterPolicy, for instance, can require every image matching a given registry path to carry a keyless signature from a specific workflow identity and OIDC issuer before it's allowed to run.
A common interview question is: "What's the difference between signing an image and scanning it?" Signing proves who built it and that it hasn't been modified (integrity and authenticity). Scanning proves whether known vulnerabilities exist inside it (content safety). You need both: a perfectly signed image can still contain a critical CVE, and a clean image can be tampered with after scanning if you don't verify the signature at deploy time.