Cosign in Production: Keyless Signing and Admission Control That Works
Cybersecurity
Sigstore and Cosign moved container signing from a 2020 research project to a production-ready pattern. We walk through keyless signing with OIDC, the Rekor transparency log, and the admission control story that keeps unsigned images out of your cluster.
By Arjun Raghavan, Security & Systems Lead, BIPI · October 28, 2024 · 7 min read
We rolled Cosign into production at three clients across 2024 and 2025. Different scales, different cloud providers, similar surprises. The signing part is the easy half. The verification-at-admission-control part is where rollouts succeed or get rolled back.
Sigstore reached production maturity in 2023. The Rekor transparency log has been running stably. Fulcio issues certificates against OIDC identities. The toolchain is good. The deployment patterns are still being learned in most security teams.
Keyless signing in 60 seconds of explanation
Cosign without keyless signing required you to manage a long-lived key pair, store it in a KMS, give your CI access to it, and worry about rotation. Keyless signing replaces all that with OIDC. Your CI workflow proves its identity to Fulcio via an OIDC token (GitHub Actions, GitLab CI, Google Cloud Build all work). Fulcio issues a short-lived X.509 certificate. Cosign signs the image with the ephemeral private key. The signature, certificate and OIDC claim go to the Rekor transparency log.
No key management. The signing identity is the workflow identity. Verifiers check that an image was signed by the expected workflow on the expected branch, not that it was signed with a particular key. That maps cleanly to how teams actually think about CI trust.
What goes into the registry
Cosign stores the signature as a separate OCI artifact alongside the image. Your registry needs to support OCI 1.1 referrers or the cosign-tag signature pattern (sha256-deadbeef.sig). Most registries support this in 2026: Docker Hub, GHCR, ECR, Artifact Registry, Harbor, JFrog. Verify yours before scoping the project.
- Sign at build time, in the workflow that produces the image.
- Use the GitHub Actions or Cloud Build OIDC token. Do not manage keys.
- Push signature, attestations and SBOM as referrers to the same image digest.
- Make signing a required step in your CI pipeline. Unsigned image equals failed build.
Admission control: the part where it gets real
An image with no signature in the registry is a bug your CI should catch. An image with no signature getting deployed to production is a control failure your platform should catch. Admission control is that second layer.
Three options in 2026. Sigstore Policy Controller (Kyverno-adjacent, Sigstore-native). Kyverno itself with Cosign verification rules. OPA Gatekeeper with a Cosign-aware constraint template. We have used all three. Sigstore Policy Controller is the most direct fit, Kyverno is the most flexible if you have other policy needs.
The Rekor transparency log
Every Cosign keyless signature gets logged to Rekor, the public transparency log. The log entry binds the OIDC identity, the signature and the timestamp. Anyone can audit the log. If a signature is forged with a stolen identity, the entry exists for incident response to find later.
For high-assurance environments, you can run a private Rekor instance instead of using the public one. Most clients we work with use the public log. The privacy concern (your image digests appear in a public log) is real but rarely the deciding factor.
The rollout pattern that has worked
Three weeks, three phases. Week one: enable signing in CI for all production-bound images. Verify signatures land in the registry and Rekor. Week two: deploy admission controller in audit mode. Watch the violations. Tune the policy until the only violations are images you genuinely want to block. Week three: switch to enforce mode. Have a break-glass annotation ready for the inevitable emergency exception.
Cosign is not glamorous. It does not show up on the marketing slide deck. It does cut off the broad class of attacks where a compromised registry serves a tampered image, and the verification at admission control closes the loop on whether your cluster will actually run that image. For 2026 production environments, this is table stakes. Most teams have not finished implementing it. The window to be ahead of the curve is narrow but still open.
Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.