Run cosign verify against each registry.k8s.io image with the krel-trust identity and the Google OIDC issuer, and verify the SBOM at sbom.k8s.io with checksums and a signature. Then pin images by digest in your manifests and let an admission controller check non control plane images.
What the Kubernetes project signs
According to the Kubernetes documentation, container images for the control plane are signed with keyless cosign signatures, and the release SBOM is published and can be verified the same way. The page is marked beta since v1.26.
Verify one image
cosign verify registry.k8s.io/kube-apiserver-amd64:v1.37.0 \
--certificate-identity krel-trust@k8s-releng-prod.iam.gserviceaccount.com \
--certificate-oidc-issuer https://accounts.google.com
The docs also provide a script that reads the image list from the release SBOM and verifies each image. The version in the example is the one the docs use. Substitute your own.
Verify the SBOM
The docs show a sequence: download the SPDX file for a version from sbom.k8s.io, check its SHA-512 and SHA-256 sums against the published values, download the .sig and .cert files, and run cosign verify-blob with the krel-staging identity.
Why bother
If you build clusters yourself with kubeadm or an installer, the control plane images are the most privileged workloads you run. A swapped image there is a full cluster compromise. A signature check at install or upgrade time turns that risk into a visible failure.
| Artifact | Identity to expect |
|---|---|
| Binaries and the SBOM | krel-staging at k8s-releng-prod |
| Container images | krel-trust at k8s-releng-prod |
Pin by digest
The docs recommend pinning images by digest in pod manifests, using the form registry-url/image-name at sha256 followed by the digest, written with the at sign. A tag can move. A digest cannot. Verification is also strongest when it is done against the digest you will actually run.
Deploy time checks for everything else
The docs point to the sigstore policy-controller admission controller for verifying other images, such as the conformance image, at deploy time. See Sigstore keyless verification: what to check.
When verification fails
Do not retry until it passes. First confirm you used the image identity and not the binary one. Then confirm the registry host is the one in the docs. If both are right and the check still fails, stop the rollout and ask the Kubernetes release channels before proceeding.
Try it yourself
Try it yourself
Click through it at your own pace, or open it full screen. Open the findings view and note that a valid signature and a clean vulnerability picture are two separate facts.
Quick check
Does a signed control plane image mean it has no vulnerabilities?
No. Signing shows origin and integrity. Scan the image and track Kubernetes release notes separately.
Can I verify images in an air gapped cluster?
Verification needs access to the signing infrastructure data, or an approach prepared for offline use. Check the sigstore documentation for your setup, since this post did not confirm an offline procedure.
Safeguard scans container images and builds SBOMs, and a free scan is at https://gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
