iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Verify the exact image digest you intend to run, require the signer identity and OpenID Connect issuer approved by your build system, and make the check fail the deployment when verification fails. A typical keyless check is cosign verify against an immutable registry.example/team/app@sha256:... reference. For Kubernetes, add admission enforcement so an image cannot enter the cluster through a path that bypasses your pipeline.
What Cosign verification proves
Cosign verifies a signature over a container image’s signed claims. By default, it also checks that the manifest digest in those claims matches the image reference being verified. When the digest and trust conditions match, you have evidence that the signed artifact is the exact image selected for deployment and that it was signed by an identity your policy accepts.
That result is narrower than a full security assessment. A valid signature does not prove that the image has no vulnerabilities, that its source code is safe, or that it satisfies every provenance requirement. Those questions require vulnerability scanning, build controls, and—when required—attestation verification with an explicit policy.
Prerequisites and decisions
- Cosign: install a release-pinned Cosign binary appropriate for your operating system. The command-line interface and bundle formats can change, so use the current installation guidance for the version you standardize.
- Registry access: the account running verification must be able to pull the image and read its signature objects. Signatures are normally stored in the same repository as the image.
- An immutable image reference: obtain the digest for the image that will actually run. A mutable tag such as
:latestis not sufficient for a deployment gate. - A trust model: decide whether your organization will trust a keyless identity and issuer or a public key controlled by the organization.
- Approved signer data: record the exact certificate identity and OIDC issuer expected from the trusted build workflow. Treat these values as policy, not as values copied from an arbitrary signature.
The deployment-safe verification workflow
1. Resolve the tag to a digest
Start with the tag your release process selected, then resolve it before verification. For example:
#1 Best Overall
- POWERFUL SECURITY KEY: The Security Key C NFC is the essential physical passkey for protecting your digital life from phishing attacks. It ensures only you can access your accounts.
- WORKS WITH 1000+ ACCOUNTS: Compatible with Google, Microsoft, and Apple. A single Security Key C NFC secures 100 of your favorite accounts, including email, password managers, and more.
- FAST & CONVENIENT LOGIN: Plug in your Security Key C NFC via USB-C and tap it, or tap it against your phone (NFC) to authenticate. No batteries, no internet connection, and no extra fees required.
- TRUSTED PASSKEY TECHNOLOGY: Uses the latest passkey standards (FIDO2/WebAuthn & FIDO U2F) but does not support One-Time Passwords. For complex needs, check out the YubiKey 5 Series.
- BUILT TO LAST: Made from tough, waterproof, and crush-resistant materials. Manufactured in Sweden and programmed in the USA with the highest security standards.
docker pull registry.example/team/app:prodThe pull output includes the registry digest. You can also inspect a remote image with Docker Buildx:
docker buildx imagetools inspect registry.example/team/app:prodCopy the manifest digest shown by the command and construct the immutable reference:
registry.example/team/app@sha256:IMAGE_DIGESTUse that same digest in verification, deployment manifests, and the record produced by your release system. If a later step changes the tag or resolves a different digest, verify the new reference again; do not assume that a prior tag check still applies.
2. Determine the expected signer and issuer
For keyless signing, the certificate identity represents the workload or user that signed the image, while the OIDC issuer identifies the identity provider that issued the certificate. Your build documentation should define both values. Depending on the CI system, the identity may be a workflow, repository, project, service account, or other URI-like value. Use the exact expected string and issuer URL supplied by that workflow.
Do not configure a deployment gate to accept any identity from a trusted issuer. A valid signature from an unrelated project is still the wrong signer for your application. If you use regular-expression options in a more complex policy, constrain them to the smallest intended set; an expression that matches an entire organization or provider without checking the project can admit an unauthorized build.
3. Verify a keyless signature
Replace all placeholders with your approved values and the digest selected in step 1:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Rank #2
- POWERFUL SECURITY KEY: The YubiKey 5C NFC is the most versatile physical passkey, protecting your digital life from phishing attacks. It ensures only you can access your accounts
- WORKS WITH 1000+ ACCOUNTS: Compatible with popular accounts like Google, Microsoft, and Apple. A single YubiKey 5C NFC secures 100+ of your favorite accounts, including email, password managers, and more
- FAST & CONVENIENT LOGIN: Plug in your YubiKey 5C NFC via USB and tap it, or tap it against your phone (NFC), to authenticate. No batteries, no internet connection, and no extra fees required
- MOST SECURE PASSKEY: Supports FIDO2/WebAuthn, FIDO U2F, Yubico OTP, OATH-TOTP/HOTP, Smart card (PIV), and OpenPGP. That means it’s versatile, working almost anywhere you need it
- PRIMARY & SPARE KEYS: Just like having a spare house key, we recommend buying two YubiKeys - one for daily use and one as a spare. That way you’ll never get locked out of your accounts
cosign verify
--certificate-identity='EXPECTED_IDENTITY'
--certificate-oidc-issuer='EXPECTED_OIDC_ISSUER'
'registry.example/team/app@sha256:IMAGE_DIGEST'Cosign retrieves the signature and certificate associated with the image, verifies the cryptographic signature, checks the certificate and transparency evidence, applies the identity and issuer constraints, and checks the signed image claims against the referenced digest. A successful command is a prerequisite for deployment, not a reason to skip other controls.
4. Treat a non-zero exit as a release failure
In a local shell, inspect the output to understand the failure. In automation, use Cosign’s exit status as the gate. Do not continue to deployment merely because a signature object exists in the repository.
Do not use --check-claims=false as a routine workaround. That option disables claim validation, so a signature could be valid while the signed payload does not answer whether it corresponds to the selected image. If claim checking fails, correct the image reference, signing process, or trust policy instead.
5. Deploy the verified digest
Pass the digest—not the original mutable tag—to the deployment system. This keeps the artifact tested by Cosign identical to the artifact fetched by the runtime. If your release tool accepts only tags, make the tag-to-digest resolution and verification an atomic part of that tool’s workflow, and ensure the runtime or admission layer resolves the same value.
Free tools Windows power users keep installed
One-click scans. No signup required.
How keyless Sigstore verification works
In a keyless workflow, the signer authenticates with an OpenID Connect identity provider. Sigstore issues a short-lived code-signing certificate containing an ephemeral public key. The signing operation produces an artifact signature, and transparency-log evidence records the signing event. The verification evidence can include the signed timestamp, the short-lived certificate, the signature, and proof that the event was included in the transparency log.
For container images, the signature and certificate are attached to the image in the registry, so the basic verification command does not require you to download a separate bundle blob manually. Cosign validates the certificate, signature, and transparency evidence before applying your identity and issuer constraints.
Rank #3
- POWERFUL SECURITY KEY: The YubiKey 5 NFC is the most versatile physical passkey, protecting your digital life from phishing attacks. It ensures only you can access your accounts
- WORKS WITH 1000+ ACCOUNTS: Compatible with popular accounts like Google, Microsoft, and Apple. A single YubiKey 5 NFC secures 100+ of your favorite accounts, including email, password managers, and more
- FAST & CONVENIENT LOGIN: Plug in your YubiKey 5 NFC via USB and tap it, or tap it against your phone (NFC), to authenticate. No batteries, no internet connection, and no extra fees required
- MOST SECURE PASSKEY: Supports FIDO2/WebAuthn, FIDO U2F, Yubico OTP, OATH-TOTP/HOTP, Smart card (PIV), and OpenPGP. That means it’s versatile, working almost anywhere you need it
- PRIMARY & SPARE KEYS: Just like having a spare house key, we recommend buying two YubiKeys - one for daily use and one as a spare. That way you’ll never get locked out of your accounts
Keyless trust reduces the need to distribute and rotate a long-lived signing key, but it makes identity policy central. A change to the build workflow, repository, service account, or identity provider can change who is able to satisfy a policy. Review those identity mappings as carefully as you would review access to a private key.
Verification with an organization-supplied key
Some organizations prefer a public key that they control and distribute through an internal trust system. The basic form is:
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutecosign verify
--key cosign.pub
'registry.example/team/app@sha256:IMAGE_DIGEST'The public key must come from a reliable organizational source and must be bound to the correct environment or application. Protect the corresponding private key, document rotation and revocation procedures, and make sure every verifier receives the intended public key rather than a file downloaded from an untrusted location.
Cosign also documents certificate-chain and custom-root approaches for organizations operating their own PKI. Those models can fit existing certificate governance, but they add trust-root lifecycle and chain-management responsibilities. A key by itself does not identify which team, workflow, or release produced an image unless your organization creates and enforces that association.
Keyless and key-based trust models compared
| Decision area | Keyless identity-based verification | Organization-supplied public key |
|---|---|---|
| Identity | Uses the certificate identity and its OIDC issuer; policies can distinguish workflows or service identities. | Usually identifies the signing authority through possession of the private key; application or team mapping is managed separately. |
| Key custody | Uses an ephemeral signing key and short-lived certificate, reducing long-lived key storage. | Requires secure storage, access control, backup, rotation, and possible revocation for the private key. |
| Rotation | Certificate and ephemeral key lifetimes are handled by the keyless flow; identity-provider and workflow changes still require policy review. | Every key rotation requires distributing and trusting the replacement public key without accidentally trusting an obsolete one. |
| Workload integration | Works naturally with CI workload identity and OIDC authentication. | Works with existing internal key-management or PKI processes, provided the signing service can access the private key. |
| Operational complexity | Less key distribution, but careful identity and issuer constraints are mandatory. | More direct control of trust material, with greater lifecycle and custody overhead. |
Signatures, annotations, and attestations answer different questions
Signatures
A signature establishes that the image claims were signed by a key or certificate accepted by your policy and that the signed digest matches the image you selected. This is the minimum check for an authorized artifact identity.
Annotations
Annotations carry additional key/value claims. A policy can require expected annotation values, such as an environment or release channel, but the exact keys and accepted values must be defined by your organization. Configure annotation checks using the current Cosign command documentation and fail when a required claim is absent or different.
Recommended Free Tools
Rank #4
- POWERFUL SECURITY KEY: The Security Key NFC is the essential physical passkey for protecting your digital life from phishing attacks. It ensures only you can access your accounts.
- WORKS WITH 1000+ ACCOUNTS: Compatible with Google, Microsoft, and Apple. A single Security Key NFC secures 100 of your favorite accounts, including email, password managers, and more.
- FAST & CONVENIENT LOGIN: Plug in your Security Key NFC via USB-A and tap it, or tap it against your phone (NFC) to authenticate. No batteries, no internet connection, and no extra fees required.
- TRUSTED PASSKEY TECHNOLOGY: Uses the latest passkey standards (FIDO2/WebAuthn & FIDO U2F) but does not support One-Time Passwords. For complex needs, check out the YubiKey 5 Series.
- BUILT TO LAST: Made from tough, waterproof, and crush-resistant materials. Manufactured in Sweden and programmed in the USA with the highest security standards.
Attestations
Attestations carry predicates such as build provenance. Verify them with Cosign’s attestation verification command and evaluate the predicate against an explicit policy. For example, a provenance rule might require a particular repository, build workflow, source revision, or builder. Merely verifying that an attestation is signed does not establish that its contents meet your requirements.
cosign verify-attestation
--certificate-identity='EXPECTED_IDENTITY'
--certificate-oidc-issuer='EXPECTED_OIDC_ISSUER'
'registry.example/team/app@sha256:IMAGE_DIGEST'Use signature verification for artifact identity and attestation verification for claims about how the artifact was built. Keep vulnerability scanning, secret detection, license review, and runtime controls as separate gates unless your policy system explicitly combines them.
Automate the check in a build or deployment pipeline
A pipeline gate should verify the immutable reference immediately before deployment and should preserve the verified digest and signer information in its logs or release record. A minimal shell pattern is:
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →set -eu
IMAGE='registry.example/team/app@sha256:IMAGE_DIGEST'
cosign verify
--certificate-identity='EXPECTED_IDENTITY'
--certificate-oidc-issuer='EXPECTED_OIDC_ISSUER'
"$IMAGE"
# Deploy "$IMAGE" only after the command exits successfullyIn a real pipeline:
- Build the image and push it to the registry.
- Sign the pushed digest from the trusted build identity.
- Resolve the release tag to its digest and store that immutable reference as the deployment input.
- Run Cosign verification with exact identity and issuer values.
- Verify required annotations or attestations, if your policy needs them.
- Run vulnerability and other compliance checks.
- Deploy only the digest that passed every gate.
Keep signer values in reviewed configuration rather than accepting them from a pull request or an untrusted job input. Quote the image reference in shell commands, and ensure that logs do not expose private signing material or sensitive identity tokens. If verification fails, stop the job and retain the error context for remediation.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Enforce verification at Kubernetes admission
A pipeline check covers the path through that pipeline. It does not automatically cover a developer’s direct deployment, a second pipeline, a restored workload, or an image changed after approval. Sigstore’s Kubernetes policy controller can validate signatures and attestations at admission and can resolve tags so that the admitted image is the image evaluated by policy.
Installation prerequisites
- A Kubernetes cluster and credentials with the access required to install and configure admission components.
- Helm 3 for the installation path documented by the project.
- A reviewed policy describing accepted keys or keyless identities, issuers, signatures, attestations, and any required predicates.
Use the project’s official Helm chart and current installation instructions. The policy controller is described as under active development, so check its current release guidance, compatibility notes, and upgrade procedure before making it a critical production control.
Best Value
- The information below is per-pack only
- POWERFUL SECURITY KEY: The Security Key C NFC is the essential physical passkey for protecting your digital life from phishing attacks. It ensures only you can access your accounts.
- WORKS WITH 1000+ ACCOUNTS: Compatible with Google, Microsoft, and Apple. A single Security Key C NFC secures 100 of your favorite accounts, including email, password managers, and more.
- FAST & CONVENIENT LOGIN: Plug in your Security Key C NFC via USB-C and tap it, or tap it against your phone (NFC) to authenticate. No batteries, no internet connection, and no extra fees required.
- TRUSTED PASSKEY TECHNOLOGY: Uses the latest passkey standards (FIDO2/WebAuthn & FIDO U2F) but does not support One-Time Passwords. For complex needs, check out the YubiKey 5 Series.
Opt a namespace into enforcement
The documented namespace opt-in label is:
kubectl label namespace production policy.sigstore.dev/include="true"Apply the label only after the policy has been tested against the images and identities used by that namespace. Confirm that admission rejects an unsigned image, an image signed by the wrong identity, and an image whose digest does not match the signed claims. Also test the permitted path so a valid release remains deployable.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsAdmission policy should complement, not replace, pipeline verification. Pipeline checks give developers fast feedback and produce release records; admission enforcement protects every admission path into the selected cluster or namespace.
Registry behavior and compatibility
Cosign signatures use the OCI 1.1 referrers specification and, by default, are stored in the same repository as the image. Documentation lists Docker Hub, GitHub Container Registry, Amazon Elastic Container Registry, Google Artifact Registry, Azure Container Registry, GitLab, Harbor, Quay, and other registries as tested. Registry-specific behavior and access requirements can still vary.
- Verify that the registry supports the referrers behavior needed by your Cosign version.
- Give the verification identity permission to read both the image manifest and its signature or attestation objects.
- Check how the registry handles private repositories, replication, garbage collection, and cross-region mirrors.
- Test the exact registry and repository configuration used in production; a successful test against a public repository does not prove that private-repository permissions are correct.
If Cosign reports that no signature is available, first confirm that you are using the same repository and digest that was signed. A tag can point to a new manifest, and a mirror can have different referrer visibility even when the image content appears identical.
Common failures and fixes
| Symptom | Likely cause | Corrective action |
|---|---|---|
| No signatures or referrers found | The image was not signed, the repository is wrong, the digest changed, or the registry hides referrers. | Compare the exact repository and digest with the signing record, check registry permissions and OCI referrers support, then sign or replicate the correct artifact. |
| Certificate identity does not match | The policy expects a different workflow, repository, project, or service identity. | Inspect the signer’s documented identity and update the reviewed policy only if that identity is authorized. Do not broaden the check simply to make the deployment pass. |
| OIDC issuer does not match | The certificate came from a different identity provider or the configured issuer string is incorrect. | Use the exact issuer expected for the trusted workflow and verify that the workflow is authenticating with the intended provider. |
| Digest or claim mismatch | The tag moved, the wrong digest was copied, or the signed payload does not describe the selected manifest. | Resolve the release again, pin the resulting digest, and verify that exact reference. Investigate the signing job if the mismatch persists. |
| Verification works locally but fails in CI | Different Cosign versions, registry credentials, network access, or policy variables are in use. | Pin the Cosign version, compare environment and credentials, and print the non-secret image and policy inputs used by the job. |
| Attestation verification succeeds but policy still rejects | The predicate is signed but does not satisfy the required provenance or annotation rule. | Inspect the predicate and adjust the build metadata or the explicitly reviewed policy; signature validity alone is not enough. |
| An operator suggests disabling claim checks | --check-claims=false would hide a digest or claim problem. |
Keep claim checking enabled and repair the image reference or signing workflow. |
Operational checklist
- Is the deployment input an immutable digest rather than a mutable tag?
- Does the Cosign command specify the exact approved certificate identity and OIDC issuer?
- Does verification check the digest claim and return a successful exit status before deployment?
- Are required annotations or attestations verified separately with explicit predicates?
- Can the verification identity read image and signature objects in the production registry?
- Are Cosign, registry, and policy-controller versions pinned or otherwise governed?
- Does Kubernetes admission cover namespaces and deployment paths that the pipeline does not control?
- Have you tested unsigned images, wrong signers, changed digests, missing referrers, and valid releases?
- Are signer identities, issuer changes, key rotation, and emergency policy exceptions reviewed and auditable?
What to implement first
Begin with digest-pinned references and a failing pipeline gate using exact keyless identity and issuer constraints. Add attestation checks only for claims your release policy actually requires, then add Kubernetes admission enforcement for namespaces where bypassing the pipeline would be unacceptable. This sequence gives developers a clear verification result while extending the same trust decision to every deployment path.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
