How do you verify a kubectl binary signature with cosign?

Download kubectl with its .sig and .cert files, then run cosign verify-blob with the release identity and the Google OIDC issuer. A passing check shows the binary was signed by the Kubernetes release process and not altered. Cosign 2.0 requires both identity flags.

What is signed

The Kubernetes docs state that the release process signs all binary artifacts, meaning tarballs, SPDX files and standalone binaries, using cosign keyless signing. The verification page is marked beta since Kubernetes v1.26. You need cosign, curl and jq.

Steps

1. Pick the version and platform, for example a release URL under dl.k8s.io.
2. Download three files: the binary, the .sig file and the .cert file.
3. Run the verification.

URL=https://dl.k8s.io/release/v1.37.0/bin/linux/amd64
BINARY=kubectl
for FILE in "$BINARY" "$BINARY.sig" "$BINARY.cert"; do
  curl -sSfL --retry 3 --retry-delay 3 "$URL/$FILE" -o "$FILE"
done

cosign verify-blob "$BINARY" \
  --signature "$BINARY".sig \
  --certificate "$BINARY".cert \
  --certificate-identity krel-staging@k8s-releng-prod.iam.gserviceaccount.com \
  --certificate-oidc-issuer https://accounts.google.com

The version number above is the example used in the Kubernetes docs at the time of writing. Replace it with the release you need.

What the identity flags do

Keyless signing ties a signature to an identity, not a key you store. The two flags tell cosign which identity and which issuer to accept. If you omit them, verification cannot be meaningful, which is why cosign 2.0 made them mandatory. For binaries and the SBOM, the docs list the identity krel-staging at k8s-releng-prod, and for container images they list a different one, krel-trust. Using the wrong one is the most common reason a good download appears to fail.

What a pass means

A passing check says nothing about whether the Kubernetes version itself has open vulnerabilities. Check the release notes and your own scanner for that. For a wider view on what signatures prove, read what a container image signature proves and does not.

Put it in your build

If your CI image installs kubectl, add this verification to the image build and fail the build when it fails. Pin the version, so a change is a reviewed commit.

Quick check

Safeguard can scan the tools and images in your pipeline as part of dependency and SBOM scanning.

Sources

• Kubernetes: Verify Signed Kubernetes Artifacts

Last reviewed: 19 October 2026.