With CI/CD now standard, modern applications no longer need to be developed and shipped as monoliths. Gone are the days of “release days” and massive product updates with long run-up times and siloed development efforts. The rising popularity and prominence of containerized applications led to the growth of orchestration platforms like Kubernetes, whose security has become essential now that it’s mission-critical for many modern apps.
But how do you prove that what you run in Kubernetes is what you built and intended to deploy? Container orchestration platforms greatly benefit from code signing.
Code signing is an important security element in a shift-left development strategy, where security measures are built into the product as features before it ships.
Code signing enhances security and trust in software development pipelines, acting to bind software artifacts to identity and confirm their integrity with cryptographic signatures. Certificate and identity strategy is no longer a prerogative of TLS and device identities; extending it into developer and build identities in Kubernetes is a key opportunity to enrich digital trust in your organization.
Development with Kubernetes has many advantages, but also pitfalls that code signing can help address. Read on for a discussion of potential gaps in Kubernetes security, how code signing and PKI can help bridge these gaps, and the best practices for signed container security workflows.
Gaps in Kubernetes security
Public key infrastructure (PKI) is a necessary part of application development and delivery. Kubernetes certainly already relies on PKI for its many components. Control plane, kubelets, client certificates, and more all use X.509 certificates and certificate signing requests (CSRs) natively.
However, the scope of typical PKI implementation is often limited to infrastructure, leaving software artifacts running in pods and containers exposed and potentially at risk if their integrity isn’t verified in other ways. A Software Bill of Materials (SBOM) can fill part of that visibility gap by providing a complete inventory of components and dependencies within container images, while code signing verifies that these images come from trusted sources.
As teams adopt more fluid and automated CI/CD pipelines and make use of container registries and Kubernetes clusters, unsigned or compromised images can slip past scanning tools to run in production. Best-case scenario: an honest mistake. Worst-case scenario: compromised assets, broken processes, and expensive fallout from the damage. Mutable image tags deepen the risk, as someone could re-push to the same tag, bypassing native checks. This is why many architecture guides emphasize the necessity of cryptographic signing and signature verification in the cluster.
In practice, of course, developers may resist the friction that signing procedures introduce to the flow, or default to ad-hoc scripts outside of governance.
This leads to signing key sprawl and weak signing practices, where code signing scripts malfunction or the signing isn’t done at all. The challenges don’t stop there: smart key management in tune with scaling processes demands not only higher security for private key storage (ideally, in HSMs or key vaults), but also automated certificate lifecycle management for cross-cluster consistency.
Policy enforcement at runtime is also a requirement for more secure Kubernetes operations. Once an image is signed, admission controllers or policy engines should verify that the Kubernetes environment only runs images with valid and verifiable signatures. Moreover, the signing infrastructure in question must be agile enough to keep up with the rapidly evolving cybersecurity landscape and advancements in cryptography. Building an agile infrastructure that doesn’t introduce undue strain on the organization’s resources as it evolves is one of the key DevOps challenges.
How to bridge the Kubernetes security trust gap
Given the challenges of implementing code signing into Kubernetes, it’s no surprise that some environments still don’t make use of it despite its clear necessity.
The typical insecure workflow proceeds as follows: Developer commits code; CI/CD builds a container image; the image is pushed to a registry; Kubernetes pulls it into production. Problems? A few:
- There is no cryptographic proof that ties that image back to a verified build process.
- As such, anyone with registry access could replace or tamper with the image, and Kubernetes would still deploy it, as it trusts only the tag.
- The resulting pipeline is efficient, but is it trustworthy? It is definitely unverifiable.
There are numerous opportunities to secure this workflow that aren’t limited to code signing exclusively.
Step 1: Introduce verified identity into the build process
Code signing makes application workflows verifiable and tied to an auditable identity. With a certificate management tool like Keyfactor Command, a code signing certificate is issued to the build system through the same PKI framework that secures TLS and devices. Each build that automatically signs its container image and related binaries becomes part of the secure CI/CD workflow. This signature is tied to a governed, auditable identity, instead of an unmanaged key sitting on a build server. Keys can be stored in integrated HSMs or cloud key vaults, rotated automatically, and revoked if compromised, in line with PKI best practices.
Step 2: Extend trust across the delivery chain
Every signed image is pushed to the container registry together with its digital signature. Command maintains the trust anchor and certificate metadata, so any Kubernetes cluster can verify the image against the organization’s trusted root. Trust bundles are distributed automatically across environments, regardless of setup (on-premise, cloud, hybrid), so every cluster shares a consistent verification policy, removing the manual configuration drift that often undermines multi-cluster security.
Step 3: Turn Kubernetes into an enforcement point
With code signing in place, Kubernetes’s innate functionality can strengthen the security of the whole pipeline. When a developer deploys a new image, an admission controller or policy engine checks the signature before scheduling the pod. In a sense, Kubernetes no longer “hopes” that the image is legitimate, but verifies it to be true using the cryptographic proof issued under the enterprise PKI governance. If the image signature is missing, expired or untrusted, deployment is rejected automatically without slowing legitimate releases. Because such enforcement is policy-driven and doesn’t rely on ad hoc scripts, it is inherently scalable and consistent across clusters.
Step 4: Introduce total lifecycle management with Keyfactor Command
Employing PKI tools such as Keyfactor Command for container security workflows has the advantages of total lifecycle management, automation, and elimination of human error. Code signing keys and certificates follow defined, automatable lifecycles from certificate creation, rotation, and renewal to certificate revocation and retirement. Automated certificate lifecycle management solutions enable organizations to easily adapt to evolving cryptographic standards.
A mature Kubernetes security workflow checks the following boxes:
- Every artifact has a verifiable signature tied to an audible identity
- Security teams view signing activity, certificate status, and policy enforcement across clusters on a single unified dashboard
- Audit logs show exactly which key signed which build, when, and under whose authority, making compliance easier
- Expired or lost signing credentials are caught and rectified in time, resulting in zero outages or vulnerabilities
Code signing best practices for Kubernetes security workflows
Code signing in Kubernetes spans four integrated layers: building and signing, verification and enforcement, registry and storage, and trust distribution and lifecycle management.
The build and sign layer involves CI/CD pipelines that automatically request signing identities, using policy-based issuance tied to enterprise PKI. Kubernetes admission controllers validate signatures against managed trust anchors, so only verified workloads are allowed to run. Signed images and metadata are stored together, meaning that provenance travels with each artifact across registries. Successful automation synchronizes trust bundles, rotates keys, and updates cryptographic standards without breaking deployments.
Keeping these four layers of Kubernetes security in mind, some operational best practices to implement include:
- Deploying images by immutable digests rather than mutable tags to prevent substitution attacks
- Defining policies at the cluster level, so only workloads signed by authorized build systems are allowed
- Storing private signing keys in HSMs or integrated vaults, and automating their rotation
- Keeping complete audit trails of signing and verification events for compliance
- Planning for crypto-agility, as signing algorithms evolve much faster than infrastructure lifecycles
Conclusion
Kubernetes security now encompasses not only protecting infrastructure, but also securing software assets with code signing. Integrating code signing into the workflow is becoming a standard practice to bridge DevOps agility and PKI assurance, ensuring every workload is authenticated and authorized.
When your Kubernetes clusters only run software that’s cryptographically verified, security stops being an assumption and becomes an operational guarantee.
This process can start small: sign a single CI/CD pipeline, enforce signatures in one cluster, and expand organization-wide.
Keyfactor Command delivers the automation and visibility to make it scalable, from issuing and rotating certificates to managing trust bundles and integrating with CI/CD and Kubernetes tools.
The future of container security is verifiable trust. Get in touch with Keyfactor today to help build it. Have any questions? Our team is here to help!
