In this article
A matching digest establishes content identity, not trust in its publisher. For a signed image, verify the signature and expected identity or trusted key. An existing valid signature is not automatically sufficient authorization to deploy.
A matching digest establishes content identity, not trust in its publisher. For a signed image, verify the signature and expected identity or trusted key. An existing valid signature is not automatically sufficient authorization to deploy.
Define the trust policy
Record which publisher or build identity is permitted for the image. Keyless verification needs the expected certificate identity and OIDC issuer. Key-based verification requires a trusted source for the public key. Obtaining both signature and key from one unverified location does not establish the intended publisher. Define policy before examining the result, rather than accepting an arbitrary identity because cryptographic verification succeeded.
Bind signature to content
Cosign verifies signatures and, with the normal relevant claim checks, their relationship to image digest. Do not disable claim checking merely to obtain success without understanding the consequence. Preserve the exact reference, digest and expected identity/issuer or key source. Tags remain mutable, so a tag checked now and pulled later can resolve differently. Carry the verified content identity into deployment.
Examine a release example
Suppose two images have valid signatures from different build identities. Policy permits only project A. Project B’s signature can be cryptographically correct while failing that policy. After A passes, retain its digest and use it in the manifest. This does not assert that every third-party image publishes suitable signatures. If the publisher lacks the required mechanism, record the missing verification rather than inventing a trusted identity.
| Check | Question answered |
|---|---|
| Digest | Which bytes were selected? |
| Signature | Is the signature bound to the object? |
| Identity and issuer | Who is permitted by policy? |
| Manifest | What will actually run? |
Choose enforcement placement
Release-pipeline verification and admission policy solve different organizational problems. Admission requires a supported controller and explicit policy, not merely cosign installed on a laptop. Kubernetes documentation provides a concrete signed-artifact verification example. Do not copy its publisher identity onto an unrelated workload image. For offline verification, check bundle and trust-material support in the actual version rather than promising operation without network access.
Preserve the decision evidence
Retain digest, identity policy, tool version, result and manifest reference without credentials. Test an unsuitable identity in a controlled environment: it should fail policy even with a valid signature. Confirm that the running image uses the selected digest afterward. Signatures do not establish vulnerability absence, model suitability or license compliance. They protect a particular provenance and integrity boundary that should remain distinct from other deployment checks. This limited claim makes the artifact useful during later review without overstating what verification proved.
Keep negative and positive results together. Otherwise success can reflect an overly broad trust policy accepting several publishers instead of the intended release source.
Related operational reading: software stack reproducibility; hardware security.