Notifications
Clear all
Topic starter
25/06/2026 2:44 pm
TL;DR: Kubernetes security gaps persist when unsigned or mutable images can still reach production, even as CI/CD and registry controls expand, according to Keyfactor. Code signing, immutable digests, and runtime signature verification shift trust from assumed pipeline integrity to governed, auditable identity.
NHIMG editorial — based on content published by Keyfactor: Code Signing and Kubernetes Security Workflows: What You Need to Know
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- Enforce signature checks at admission time Configure cluster admission controllers or policy engines to block unsigned, expired, or untrusted images before scheduling.
What's in the full article
Keyfactor's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step signing workflow examples for CI/CD pipelines and Kubernetes admission control
- Specific guidance on storing signing keys in HSMs or cloud key vaults
- Certificate lifecycle management details for rotation, renewal, revocation, and retirement
- Operational best practices for immutable digests, trust bundle distribution, and audit logging
👉 Read Keyfactor's analysis of code signing and Kubernetes security workflows →
Kubernetes code signing: what IAM and platform teams need to know?
Explore further
25/06/2026 3:50 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Code signing and Kubernetes security workflows need stronger trust
