How can teams tell whether code signing is actually working in Kubernetes?

What “working” means in a Kubernetes admission path

code signing only counts as working if Kubernetes treats signature verification as an enforceable gate, not a documentation step. That means the control is evaluated before scheduling or deployment proceeds, and the result is deterministic: trusted artifacts pass, untrusted ones fail closed, and the decision is tied to the exact image that would run in the cluster.

The practical test is whether the enforcement point is actually wired into the path that matters. If an image can still be deployed through a side route, a cached exception, or a manual override, the signing process may exist, but it is not yet protecting the cluster.

For container image controls, that distinction is the difference between provenance and policy enforcement. Teams should be able to show that the cluster refuses unsigned or otherwise invalid images automatically, rather than relying on humans to notice the problem after the fact. NIST SP 800-190 Container Security is a useful reference point because it frames image, registry, orchestrator, and runtime controls as one chain, not separate checks.

What evidence proves the control is real

The cleanest evidence is a failed deployment that is rejected for the right reason. Test an unsigned image, an image signed by an untrusted key, and an image signed by an expired or revoked certificate. If those cases are blocked before pods are created, the control is being enforced; if they merely generate warnings, the policy is advisory.

Auditability matters just as much as blocking. A working implementation should leave a trail that identifies which key or certificate signed the build, which policy evaluated it, and why the image was allowed or denied. Without that linkage, teams cannot distinguish a valid signature from an outdated key, a copied signature, or a policy that never actually checked trust.

This is also where key lifecycle becomes part of the proof. Teams need to verify that signature verification is using current trust anchors, that revocation or rotation is reflected in the admission decision, and that build provenance remains traceable after a key change. Machine Identity, PKI and Certificate Lifecycle Guide helps connect signing to certificate expiry, renewal, and trust anchor management, while Cryptographic Key Management Guide covers the key inventory and rotation discipline that makes audit evidence believable.

Where sign-and-verify breaks in practice

Most failures are not cryptographic failures, they are enforcement failures. The image may be signed correctly, but the cluster may not be checking the signature on every deployment path, or the signer may be trusted more broadly than intended. Another common failure is accepting images from the right registry but not binding the signature to the exact digest that is scheduled.

Teams should also watch for key compromise and stale trust. If a signing key is stolen, reused, or never revoked, attackers can produce images that look legitimate enough to pass routine checks. Supply-chain incidents show that once a trusted signing relationship is abused, the blast radius can move from a single build artifact to every cluster that still trusts the old material. NVIDIA code-signing certificates stolen 2022 and HashiCorp GPG key exposure 2021 both illustrate why revocation and re-signing are operational requirements, not cleanup tasks.

For broader supply-chain assurance, the signing check should be aligned with build provenance rather than treated as a standalone control. A signed image that came from an untrusted or tampered pipeline is still a risk, which is why provenance, registry integrity, and admission enforcement need to be assessed together. SolarWinds supply chain compromise is a reminder that trusted distribution channels can be turned into an attack path when build trust is broken upstream.

Practitioner Guidance

What to verify: Run negative tests in the live admission path, not just in a staging lab. The test should cover unsigned images, expired trust material, revoked keys, and signatures from an unexpected issuer; if any of those reach a running pod, the control is not actually functioning.

What good looks like: A deployment fails closed, the rejection reason is visible in logs, and the audit record ties the decision to the exact image digest and signing identity. That combination shows both enforcement and traceability, which are the two things practitioners usually need to prove.

Common mistake: Treating image signing as equivalent to image security. Signing proves origin or approval, but it does not prove that the image is safe, patched, or free of embedded secrets; it only helps if the cluster enforces the trust decision consistently.

Practitioner takeaway: If you cannot demonstrate a repeatable rejection of bad images plus an audit trail that names the signer, you do not yet have working code signing, you have an intended control with uncertain coverage.

Related resources from NHI Mgmt Group

• How can teams tell whether identity as code is actually working?
• How can teams tell whether code hygiene controls are actually working?
• How can teams tell whether front-channel logout is actually working across applications?
• How can teams tell whether data classification is actually working?