Sigstore Cosign for Container Images: Signing Without Long-Lived Keys
Digital Engineering
Long-lived signing keys rotate badly, leak quietly, and get stored in CI secrets that everyone has access to. Sigstore Cosign with keyless signing solves the key management problem by binding signatures to short-lived OIDC identities and a public transparency log. Here is how to wire it up.
By Arjun Raghavan, Security & Systems Lead, BIPI · August 8, 2023 · 9 min read
Signing container images sounds easy until you try to do it across thirty repositories with rotating CI runners and a security team that does not want to be the on-call for lost private keys. The traditional answer is to put a signing key in a secret manager and hope nobody copies it. The Sigstore answer is to not have a key at all.
What keyless actually means
Keyless signing in Cosign is a misleading name. There is still a key, but it lives for ten minutes. The flow is short, OIDC token in, short-lived certificate out, signature produced, certificate discarded, transparency log entry created. The verifier later checks the signature against the certificate, the certificate against Fulcio, and the timestamp against Rekor.
- Fulcio is the certificate authority, it issues short-lived signing certs bound to an OIDC identity
- Rekor is the transparency log, every signature is recorded there so revocation is observable
- Cosign is the CLI that orchestrates the flow
The GitHub Actions flow
On GitHub Actions, the OIDC token is automatically minted for the workflow run. Cosign uses it to ask Fulcio for a certificate, signs the image digest, and writes the Rekor entry. The signing identity is the workflow run URL, which is exactly what you want to verify against later.
- Add permissions: id-token: write to the workflow
- Install cosign with the sigstore/cosign-installer action
- Build and push the image, capture the digest
- cosign sign $IMAGE_DIGEST
- Done, the signature is in the registry and the Rekor entry is public
Verification at admission time
Signing without verification is theater. The verification step belongs in the admission controller, not in a nightly job. Sigstore policy-controller, Kyverno, and Connaissance all support cosign verify policies that check the signing identity matches an expected pattern, for example the workflow URL of your release pipeline.
If your cluster will pull an unsigned image because the verifier is in audit mode, you do not have signing, you have logging.
What about air-gapped environments
Keyless signing assumes you can reach Fulcio and Rekor at sign time and verify time. For air-gapped clusters, you have two options. Run a private Fulcio and Rekor, which the Sigstore community ships as the Sigstore stack, or fall back to traditional key-based signing with cosign generate-key-pair and store the public key in the verifier. We see both patterns in regulated environments.
Common operational mistakes
- Signing the tag instead of the digest, tags move, digests do not
- Verifying only the signature and not the identity, anyone with a Google account can sign anything
- Forgetting to set the certificate-identity and certificate-oidc-issuer flags in the verifier
- Not signing the SBOM and provenance attestations alongside the image
- Treating audit mode as enforcement
Verification policy template
A good cosign verify policy specifies the OIDC issuer, the expected identity pattern, and optionally a Rekor public key for the transparency log. For GitHub-hosted builds, the issuer is token.actions.githubusercontent.com and the identity is the full workflow URL. Pin both. Wildcards let a fork of your repo produce verifiable signatures, which is rarely what you want.
Closing
Cosign keyless signing eliminates the worst class of operational risk in image signing, which is leaked or lost long-lived keys. It replaces that risk with an OIDC trust problem you already have. For most teams, that trade is the right one. Wire it in, pin the verifier, and stop debating key rotation policy.
Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.