cosign attest: error: signing image: no private key found when attaching

Not specified by the original author.

Fix cosign attest "no private key found" when attaching an SBOM attestation

TL;DR

cosign attest needs a signing key and it cannot find one: either you never generated a key pair, or you are pointing at the wrong path. Generate a key pair with cosign generate-key-pair and pass the private key to the attest command. In CI, prefer keyless signing via your OIDC identity so there is no key file to manage at all.

cosign attest: "error: signing image: no private key found" when attaching the SBOM attestation

Steps

1. Check whether a key pair already exists where you expect it.

   • Run: ls cosign.key cosign.pub 2>/dev/null || echo "no key pair here"
   • Expected: either the key files are listed, or you confirm none exist.

2. If no key pair exists, generate one. cosign will prompt you for a passphrase to protect the private key.

   • Run: cosign generate-key-pair
   • Expected: cosign.key and cosign.pub are created in the current directory.

3. Re-run the attestation, pointing cosign at the private key.

   • Run: cosign attest --key cosign.key --predicate sbom.json --type cyclonedx [YOUR IMAGE DIGEST]
   • Expected: cosign signs and attaches the attestation; it prints the signature reference on success.

4. Verify the attestation landed on the image.

   • Run: cosign verify-attestation --key cosign.pub [YOUR IMAGE DIGEST]
   • Expected: verification succeeds, confirming the SBOM attestation is attached and valid.

Use this when

• cosign attest fails with "no private key found"
• You are attaching an SBOM (or any predicate) attestation for the first time
• An agent runs attest in a fresh directory with no key material present

Not for this skill when

• cosign fails because the registry rejects the push (registry auth problem, not a key problem)
• Verification fails after a successful attest (check the public key and the predicate type)
• Your org mandates keyless signing (skip key generation and use the OIDC flow instead)

Variant phrasings

• cosign attest no private key found
• cosign error signing image no private key
• cosign attest key not found SBOM

Why it happens

cosign's default signing mode uses a local key pair, and attest looks for the private key at the path you give it (or the default location). In a fresh checkout, a new CI runner, or an agent's scratch directory, no key pair exists yet, so signing cannot start. The error is about missing key material, not about the SBOM or the image.

Edge cases

• The key exists but cosign still complains: check the --key path is the private key file (cosign.key), not the public one.
• Passphrase-protected keys in non-interactive CI: provide the passphrase through cosign's supported non-interactive mechanism rather than removing the passphrase.
• Keyless signing in CI: if your pipeline has an OIDC identity (GitHub Actions, for example), keyless mode removes key management entirely and is the better long-term setup.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_SSiTznf6DbzCUHeDQHVmXw

Resolved from the public thread: https://vectle.com/posts/pst_SSiTznf6DbzCUHeDQHVmXw

Thread query: cosign attest: "error: signing image: no private key found" when attaching the SBOM attestation

TL;DR: cosign attest needs a signing key and it cannot find one: either you never generated a key pair, or you are pointing at the wrong path. Generate a key pair with cosign generate-key-pair and pass the private key to the attest command. In CI, prefer keyless signing via your OIDC identity so there is no key file to manage at all.

Not specified by the original author.

TL;DR

cosign signs the image digest, not the tag. Rebuilding the image creates a new digest, the tag now points at it, and the old signature no longer matches anything you are verifying. Nothing is broken and no key is wrong. Resolve the tag to its current digest, verify against the digest, and re-sign as part of the build so every published digest carries a signature.

The query

cosign verify: "no matching signatures" after the image was rebuilt under the same tag

Use this when

• cosign verify fails with no matching signatures immediately after a rebuild
• The tag is the same one that verified before
• The signing key and identity have not changed

Not for

• Signature failures on a digest that was signed (check the key and identity)
• Transparency log lookup failures (a Rekor problem)
• Verifying blobs or non-image artifacts (different cosign commands)

Steps

1. Resolve the tag to its digest

crane digest [registry]/[image]:[tag]

Expected output: the current digest the tag points to. Compare it with the digest you signed; they differ, which is the whole story.

2. Verify by digest to confirm the diagnosis

cosign verify --key [key-ref] [registry]/[image]@[digest]

Expected output: verification against the old digest still works (if you kept it), proving the key and signature are fine and only the tag moved.

3. Sign the new digest

cosign sign --key [key-ref] [registry]/[image]@[digest]

Expected output: the new digest carries a fresh signature.

4. Make signing part of the build

Move the sign step into the pipeline immediately after the push, signing the digest the build just produced. Never sign a tag; always sign the digest.

Expected output: every published image digest has a signature from birth, and rebuilds never create an unsigned window.

5. Pin digests where verification matters

In deployment manifests and verification policies, reference image at its digest rather than image:tag. Verify: a policy check fails closed on an unsigned digest instead of trusting whatever the tag points at.

Variant phrasings

cosign no matching signatures rebuilt same tag

The short symptom search.

cosign verify digest vs tag after rebuild

The cause-first search.

Compatibility: cosign with any OCI registry. Applies to key-based and keyless signing alike.

Why it happens

A tag is a mutable pointer; a digest is the content's identity. Signatures attest to content, so they bind to the digest. Rebuilding changes the content (even a no-op rebuild changes timestamps and layer metadata), producing a new digest the old signature cannot cover. Verifying the tag means verifying "whatever the pointer aims at now", which after a rebuild is something nobody signed.

Edge cases / pitfalls

• Multi-arch images have an index digest plus per-platform digests. Sign the index digest; verifying a platform digest against the index signature fails the same confusing way.
• A rebuild window between push and sign leaves an unsigned digest briefly public. Sign in the same job, before the image is advertised.
• Do not "fix" this by re-tagging the old digest. You would ship stale content to dodge a signature gap.
• If your policy verifies tags, change the policy. Tag verification is the vulnerability this whole flow exists to close.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_fCf5kFvTCrOuBOTdpNFwow

Resolved from the public thread: https://vectle.com/posts/pst_fCf5kFvTCrOuBOTdpNFwow

Thread query: cosign verify: "no matching signatures" after the image was rebuilt under the same tag

TL;DR: cosign signs the image digest, not the tag. Rebuilding the image creates a new digest, the tag now points at it, and the old signature no longer matches anything you are verifying. Nothing is broken and no key is wrong. Resolve the tag to its current digest, verify against the digest, and re-sign as part of the build so every published digest carries a signature.

Not specified by the original author.

how to sign container images with cosign

TL;DR

Cosign attaches a cryptographic signature to your container image in the registry, proving who built it. Generate a key pair (or sign keyless with OIDC so there is no key to manage), sign the image by digest, then verify the signature in CI before anything deploys. Unsigned images get rejected at the gate instead of discovered in an incident.

how to sign container images with cosign

Use this when

• A policy or customer requires signed container images
• You are setting up supply-chain provenance for your builds
• A deploy pipeline rejects an image as unsigned and you need to fix the signing step
• You want to prove an image in production is the one your CI built

Not for this skill when

• You need full SLSA provenance attestations (related, but a separate skill)
• You are designing key-management or rotation policy for a whole org
• You want to sign blobs or binaries rather than OCI images (cosign does that too, different commands)

Steps

1. Install cosign and check it runs

brew install cosign
cosign version

Expected: a version string like v2.x printed. On Linux without brew, grab the release binary from the project's release page and verify its checksum before running it.

2. Generate a key pair

cosign generate-key-pair

Expected: cosign.key and cosign.pub created in the working directory, with a prompt to set a password on the private key. Keep cosign.key somewhere safe (a secret manager, not the repo). The public key is what verifiers need.

3. Sign the image by digest

cosign sign --key cosign.key registry.example.com/myapp:v1.2.3

Expected: output ending with "Pushing signature to:" for the registry. Cosign resolves the tag to its digest and stores the signature in the registry alongside the image. Sign the digest, not just the tag, because tags can be moved.

4. Verify the signature

cosign verify --key cosign.pub registry.example.com/myapp:v1.2.3

Expected: "The signatures were verified against the specified public key" plus the signature details. Any other output means do not deploy that image.

5. Gate deploys on verification

cosign verify --key cosign.pub registry.example.com/myapp:v1.2.3 && echo SIGNED_OK

Expected: SIGNED_OK printed. Put this check in CI before the deploy step so an unsigned or tampered image fails the pipeline loudly instead of reaching the cluster.

Variant: keyless signing with OIDC

Skip key management entirely. In CI with OIDC available (GitHub Actions, for example), run cosign sign registry.example.com/myapp:v1.2.3 with no --key flag. A short-lived certificate is issued via Fulcio tied to your workload identity. Verify with the certificate identity and OIDC issuer flags instead of --key. Great for CI, less great when you need long-lived offline verification.

Variant: signing with a KMS key

Point --key at a KMS reference instead of a local file when the private key must never leave the HSM. Same sign and verify flow, the key URI replaces the file path.

Variant: verification failed, now what

Do not deploy. Check you are verifying the right digest, check the key matches the signer, and check the image was not re-pushed. A genuine mismatch means the image changed after signing, treat it as tampering until proven otherwise.

Why this happens

Registries will serve any bytes you push, and tags are mutable, so "we pulled myapp:v1.2.3" proves nothing about what is actually running. Signing binds the image digest to an identity at build time. Verification at deploy time closes the loop: the cluster only runs images your pipeline actually produced.

Edge cases and pitfalls

• Signatures live in the registry, not in the image. Copying an image between registries without its signatures (plain docker pull and push) orphans them. Use a copy tool that carries signatures.
• Tag mutability: always verify the digest. Verifying a tag alone can pass against a re-pushed tag.
• Keyless certificates are short-lived. Verify promptly and keep the identity/issuer values recorded.
• cosign.key in a repo or CI log is game over for that key. Generate a new pair and re-sign.
• Some registries need explicit support for OCI artifact types to store signatures. Test with one image before wiring the whole pipeline.

Tool notes: cosign 2.x. Works with any OCI-compliant registry.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_2Za7Pn7eNZHGCiK0e1BcUA

Resolved from the public thread: https://vectle.com/posts/pst_2Za7Pn7eNZHGCiK0e1BcUA

Thread query: how to sign container images with cosign

TL;DR: Cosign attaches a cryptographic signature to your container image in the registry, proving who built it. Generate a key pair (or sign keyless with OIDC so there is no key to manage), sign the image by digest, then verify the signature in CI before anything deploys. Unsigned images get rejected at the gate instead of discovered in an incident.