Code signing and Kubernetes security workflows need stronger trust

At a glance

What this is: This is an analysis of how code signing and PKI close Kubernetes workload trust gaps by binding container artifacts to auditable identity and enforcing verification at deploy time.

Why it matters: It matters because platform, IAM, and security teams need a shared trust model for build identities, signing keys, and cluster enforcement across NHI, autonomous, and human-operated workflows.

👉 Read Keyfactor's analysis of code signing and Kubernetes security workflows

Context

Kubernetes security depends on more than cluster hardening. The real governance gap is whether the software running in a pod can be proven to be the same artifact that passed the build process, signed under a controlled identity.

When image tags are mutable or signing is absent, registry access can become a substitution path and deployment controls are left trusting names rather than cryptographic proof. That creates an identity problem for build systems, not just a platform problem for Kubernetes operations.

Key questions

Q: How should security teams implement code signing for Kubernetes workloads?

A: Start by issuing signing identities through governed PKI, then require every release artifact to carry a verifiable signature and an immutable digest. Enforce those proofs at admission time so the cluster rejects unsigned or untrusted images before scheduling. Treat the signing key as a privileged credential with rotation, revocation, and audit ownership.

Q: What breaks when Kubernetes trusts mutable image tags?

A: Mutable tags break provenance because the same reference can point to different content over time. That means a deployment can be approved against one image and later run another if registry access or tag replacement occurs. Digest pinning and signature verification are the controls that stop that substitution path.

Q: How do teams know whether container signature controls are actually working?

A: Look for three signals: every production image has a verifiable signature, admission logs show enforcement before scheduling, and certificate status is monitored continuously for expiry or revocation. If any unsigned or expired image can still run, the control is only advisory and not effective.

Q: What should organisations do when signing keys are exposed or lost?

A: Revoke the affected certificate immediately, rotate the signing material, and invalidate any trust assumptions tied to that key before more releases are made. Then review which build identities were authorised to use it, because key compromise often reveals a broader governance gap in build access and certificate ownership.

Technical breakdown

Why mutable image tags weaken Kubernetes trust

Mutable tags let a registry name point to different content over time, so the tag itself stops being a reliable identity for the artifact. In a CI/CD flow, that means a deployment reference can remain stable while the underlying image changes. Kubernetes will happily pull what the tag points to unless a stronger verification layer is present. This is why provenance has to travel with the image, not sit only in pipeline logs or release notes. Code signing and digest pinning give the cluster a cryptographic way to distinguish intended builds from substituted ones.

Practical implication: deploy by immutable digest and reject tag-based releases where provenance cannot be verified.

How code signing binds build identity to container provenance

Code signing turns the build system into a governed identity that can prove authorship of the artifact it produced. A signing certificate issued through enterprise PKI links the image to a trusted root, while the signature records that the artifact was created under controlled authority. That matters because the security question in Kubernetes is not only whether a container is scanned, but whether it is the exact build that should be running. If the signing key is unmanaged, the trust chain weakens; if the key is governed, provenance becomes auditable.

Practical implication: issue signing identities to build systems through governed PKI and protect private keys in HSMs or vaults.

Why admission control must verify signatures at runtime

Runtime enforcement is where Kubernetes turns provenance into policy. Admission controllers and policy engines evaluate whether the submitted image carries a valid signature, matches the trusted root, and still falls inside certificate validity and revocation rules. Without that step, signing is only evidence after the fact. With it, the cluster becomes an enforcement point that can block unsigned, expired, or untrusted workloads before scheduling. This is the control that makes code signing operational rather than symbolic, especially in multi-cluster environments where manual checks do not scale.

Practical implication: configure admission policies to block images that are unsigned, expired, or outside trusted roots.

Threat narrative

Attacker objective: The objective is to get untrusted or tampered code running inside Kubernetes as if it were a legitimate build.

1. Entry occurs when an attacker or rogue process can alter a container image in a registry, exploit mutable tags, or insert an unsigned artifact into a CI/CD path that trusts names instead of proof.
2. Escalation happens when Kubernetes pulls and schedules that artifact because no runtime signature verification, immutable digest control, or certificate enforcement blocks the substitution.
3. Impact is unauthorized code execution in production, which can lead to compromised workloads, broken release integrity, and downstream supply chain fallout.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Code signing has become a workload identity control, not just a release control. Kubernetes security depends on being able to prove that the artifact in the cluster is the same one produced by the build system under governed authority. That shifts the problem from scanning alone to identity-backed provenance, which is why build identity, certificate governance, and cluster policy now sit on the same control plane. Practitioners should treat signing as part of workload authentication, not as an optional add-on.

Mutable tags create identity ambiguity that Kubernetes cannot resolve on its own. A tag is only a pointer, and pointers do not preserve provenance when images are replaced or re-pushed. This is a software supply chain trust gap, but it is also an identity governance gap because the cluster is trusting a label instead of a cryptographically bound identity. The practical conclusion is that policy must be attached to immutable digests and verifiable signatures, not registry convenience.

Certificate lifecycle has become part of cluster resilience. Signing works only when keys are rotated, revoked, and audited with the same discipline applied to other privileged credentials. That maps directly to OWASP-NHI and NIST CSF thinking: every signing identity is a governed non-human identity with an exposure window, revocation requirement, and audit trail. Practitioners should manage signing material as production identity, not as static infrastructure plumbing.

Trust distribution across clusters is now a governance problem. Multi-cluster environments fail when trust bundles drift, policy differs by environment, or verification logic is implemented inconsistently. The named concept here is provenance enforcement drift: the gap between having signatures available and enforcing them consistently at runtime. That drift turns a sound cryptographic control into an optional signal. Practitioners should standardise verification policy across every cluster boundary.

The security model only holds when build authority and runtime authority are aligned. If the build system signs artifacts but the cluster does not enforce the signature, authority is split and the trust chain is incomplete. That is why code signing, admission control, and certificate governance have to be treated as one operational pattern. Teams should evaluate whether their release process produces proof, or merely generates metadata.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
• 8 of the top 10 fastest-growing types of leaked secrets year-over-year are tied directly to AI services, according to The State of Secrets Sprawl 2026.
• For a broader control model, read Ultimate Guide to NHIs , Standards for the standards stack that underpins workload identity governance.

What this signals

Provenance enforcement drift: the gap between having signatures available and enforcing them consistently at runtime is what will now decide whether Kubernetes trust controls work in practice. Teams should expect more pressure to align build identity, admission policy, and certificate governance into one operating model, especially as container estates span on-premise, cloud, and hybrid environments.

The operational signal is clear: signature verification will increasingly be treated as a release gate, not a documentation step. Organisations that still rely on registry naming, ad hoc scripts, or cluster-by-cluster exceptions will find their control surface fragmenting faster than their policy can keep up.

For teams formalising this control, the relevant standards conversation sits alongside NIST Cybersecurity Framework 2.0 and the NHI governance patterns captured in Ultimate Guide to NHIs , Why NHI Security Matters Now. The practical direction is to make signature enforcement measurable across every cluster, not merely available in architecture diagrams.

For practitioners

• Replace mutable deployment references with immutable digests Pin Kubernetes deployments to immutable image digests so the registry name cannot be repointed to a different artifact after approval. This reduces substitution risk and gives admission policies a stable target for verification.
• Treat signing keys as production credentials Store private signing keys in HSMs or cloud vaults, rotate them on a defined schedule, and revoke them immediately if compromise is suspected. Signing credentials should have owners, lifecycle rules, and audit trails like any other privileged identity.
• Enforce signature checks at admission time Configure cluster admission controllers or policy engines to block unsigned, expired, or untrusted images before scheduling. Verification has to happen at runtime, not only during build review, or attackers can bypass the control by changing the artifact later.
• Synchronise trust bundles across all clusters Distribute the same trusted roots, certificate metadata, and verification policy to every environment to avoid drift between on-premise, cloud, and hybrid clusters. Consistent trust distribution keeps one cluster from becoming the weak link.
• Audit which identities can issue signatures Map every system that can request or use a code-signing certificate and ensure it is explicitly authorised under enterprise PKI governance. If build identities are unmanaged, the signature itself becomes hard to trust.

Key takeaways

• Kubernetes image trust fails when the platform relies on mutable labels instead of cryptographic proof tied to build identity.
• Signature controls only reduce risk when signing keys, trust bundles, and admission policies are governed as a single lifecycle.
• Teams that cannot enforce provenance at runtime are not operating a signed-software model, only a documented one.

Key terms

• Code Signing: Code signing is the process of attaching a cryptographic signature to software so recipients can verify who produced it and whether it changed after signing. In Kubernetes workflows, it turns a container image into a verifiable artifact tied to a governed build identity.
• Mutable Image Tag: A mutable image tag is a registry reference that can point to different image contents over time. It is convenient for release workflows, but it is weak as a trust mechanism because it does not prove the artifact is the one that was approved.
• Admission Controller: An admission controller is a Kubernetes control point that evaluates requests before workloads are scheduled. When used for provenance enforcement, it can reject unsigned, expired, or untrusted images and turn signature verification into a runtime policy.
• Signing Key Lifecycle: Signing key lifecycle is the governed creation, storage, rotation, revocation, and retirement of the private keys used to sign software. For Kubernetes and CI/CD, it matters because the security of the signature depends on the security and recoverability of the key behind it.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Keyfactor: Code Signing and Kubernetes Security Workflows: What You Need to Know. Read the original.