How Container Image Signing Works From Build to Kubernetes Deployment
TL;DR — Key Takeaways
- A successful build, clean vulnerability scan and trusted registry do not prove that the image running in production is the exact artifact the organization intended to deploy.
- Image signing ties cryptographic evidence to a specific artifact digest, allowing deployment systems to verify who signed it and whether that signer is authorized.
- Kubernetes admission is the critical enforcement point because it can reject unsigned or incorrectly signed workloads regardless of how they reach the cluster.
A container image can pass every test in a CI pipeline and still create a trust problem at the time of deployment.
The build may have completed successfully. Unit tests may have passed. Vulnerability scanning may have found nothing critical. The image may even have been pushed to the organization’s trusted registry. None of those events, by themselves, prove that the image running in production is the exact artifact the organization intended to deploy.
This is where container image signing becomes important. Image signing adds cryptographic evidence to the software artifact itself, allowing a deployment environment to verify that an image was signed by an authorized identity and the artifact corresponds to the signed content.
For DevOps teams, the question changes from whether the pipeline built an image to whether the deployment environment can verify where that image came from and whether it is the artifact that should run. That distinction matters as organizations adopt automated Kubernetes deployments, ephemeral CI runners, multiple registries, GitOps workflows and stronger software supply chain controls.
The Complete Workflow
Container image signing is not a single operation performed after Docker build. It is a chain connecting source code, the build environment, the image registry, cryptographic signing infrastructure, deployment policy and the Kubernetes cluster.
A typical flow looks like this: Source code enters the CI/CD pipeline, the image is built and tested, security checks are performed, the resulting image digest is identified, the artifact is signed, the image and signature are published and the deployment environment verifies the signature before Kubernetes accepts the workload.
The important part is that signing does not replace existing CI/CD security controls. It adds another trust signal to the artifact. That model fits the broader software delivery controls described in DevOps.com’s software development security blueprint, which includes validating artifact signatures and digests and keeping build environments ephemeral.
Image signing therefore works best when it is integrated into the delivery architecture rather than treated as a manual security step at the end of a release.
Why Container Image Signing Matters in DevOps
Container registries solve a distribution problem. They provide a centralized location from which Kubernetes clusters and other systems can retrieve images. However, registry access is not the same thing as artifact authenticity.
An authenticated user may be allowed to push an image. A compromised CI credential could potentially push an unauthorized artifact. A privileged account could move a mutable tag. A deployment configuration could also reference an unexpected image.
Cryptographic signing adds evidence about the artifact itself. Organizations can then create deployment policies such as:
- Only images signed by approved identities may run in production.
- Development and production signing identities must remain separate.
- Images must carry required attestations before deployment.
- Unsigned or incorrectly signed images must be rejected by the cluster.
The goal is not to trust one system more. It is to make the trust decision depend on evidence that can be verified at the point where software is released or deployed.
What Exactly is Being Signed
A container image is not simply a single file. Modern container images are represented through manifests, configuration data and filesystem layers. The manifest identifies the components that make up the image, while cryptographic digests provide content-addressed references to those components.
This matters because the signature needs to remain associated with a specific artifact identity. A deployment reference such as registry.example.com/payments:production is human-readable, but the tag can move. A digest identifies a particular content state.
A deployment can instead reference an immutable digest such as registry.example.com/payments@sha256:abc123…. If the underlying image changes, its digest changes, and a signature associated with the earlier digest no longer represents the new artifact.
That is why image signing works particularly well with immutable artifact references. The signature is not simply saying that a repository is trusted — it provides evidence about a specific artifact.
Why Image Tags Aren’t a Security Boundary
Tags remain useful for release management, but they should not be treated as cryptographic identities. Today’s latest and tomorrow’s latest can point to different manifests, and even version-oriented tags can be moved when registry permissions allow it.
Therefore, the security relationship is better understood as tag to digest, digest to signature and signature to deployment policy. Each layer answers a different question.
The deployment system needs to determine whether the requested artifact is the expected image, whether the digest matches, whether the signature is valid, who signed it and whether that signer is authorized for the target environment.
Where Signing Fits Into a CI/CD Pipeline
The signing operation normally occurs after the image has been built and the pipeline has established that the artifact is ready for distribution. The exact order varies. Some workflows push the image first and attach the signature to the registry artifact, while others integrate signing more tightly with publication.
The architectural requirement is more important than the exact command sequence: The signature must correspond to the artifact that will eventually be deployed. Signing an arbitrary local image and assuming that the registry contains the same artifact breaks that relationship.
Therefore, a typical pipeline can be understood as commit, build, tests, security checks, image build, image scan, digest identification, signing, publication and deployment. The important boundary is the point where the artifact becomes the release candidate that the organization intends to trust.
How the Cryptographic Signature Works
At a high level, the signing system takes an artifact identity and creates cryptographic evidence using a signing key or signing identity. The verifier later retrieves that evidence and uses the corresponding public verification information to determine whether the signature is valid.
The signature does not make the image secret. Container images remain distributable artifacts. Instead, the signature provides evidence about authenticity and integrity.
A valid signature can help answer whether an artifact was signed by an expected identity, whether the signed artifact has changed and whether the signing identity satisfies deployment policy. It does not prove that the application is free of vulnerabilities, the source code is trustworthy or the application is authorized to access production data.
Where Does the Signing Key Live
Traditional signing architectures often depend on a private key. This immediately creates an operational problem for CI/CD because every build runner that receives a reusable private key becomes part of the key’s security boundary.
If the key is stored in environment variables, repository secrets, configuration files or persistent runner storage, a compromised build environment could potentially produce artifacts that appear legitimate.
A stronger architecture separates the build environment from long-lived private key material. The CI runner can request a signing operation while the actual private key remains protected by a dedicated signing service, KMS or HSM.
This model is particularly important for ephemeral CI runners. A runner may exist for only a few minutes, execute a build, publish an artifact and disappear. There is little reason for that temporary environment to possess permanent production signing credentials.
The same operational principle appears in broader certificate lifecycle management, where cryptographic material is treated as an operational asset that requires ownership, protection, rotation and controlled use rather than as an ordinary configuration value.
Keyless Signing Changes the Model
Modern signing architectures can reduce or eliminate the need for developers and CI systems to maintain long-lived signing keys. With a keyless model, the signing system can associate the signature with an identity derived from the workload or CI environment.
The advantage is not simply convenience. It can reduce the number of long-lived secrets distributed throughout the delivery environment and make identity and provenance more closely connected to the build process.
That becomes increasingly relevant as CI/CD systems create large numbers of machine identities. DevOps.com recently examined this issue in CI/CD pipeline non-human identities, highlighting how automation can accumulate machine identities and access that are difficult to track over time.
What Gets Stored in the Registry
Signing does not replace the container image or modify the application’s filesystem layers. The application image remains the artifact Kubernetes ultimately retrieves, while signatures and other metadata provide evidence that can be evaluated before or during deployment.
Therefore, a registry may hold the application image alongside its manifest, layers, configuration, signature and additional attestations. This separation also allows organizations to add new evidence without rebuilding the application image.
How Signature Verification Works During Deployment
Signing only becomes useful when something actually verifies the signature. Verification can happen before deployment, during admission or through multiple controls across the delivery pipeline.
A simplified verification sequence is deployment request, image reference resolution, digest retrieval, signature retrieval, cryptographic verification, signer identity validation and policy evaluation.
The verification process has two distinct dimensions. First, does the signature mathematically correspond to the artifact? Second, even if the signature is valid, is the signer trusted for this deployment?
A valid signature from a development identity should not necessarily authorize production deployment. An organization may require production images to be signed by a specific CI workflow, project identity or release process.
Why Kubernetes Admission is the Critical Step
A deployment pipeline can verify signatures before submitting a workload to Kubernetes, but that does not necessarily guarantee that every path into the cluster follows the same control. Teams may deploy through different CI systems, operators may apply manifests manually and GitOps controllers may reconcile resources independently.
Kubernetes admission provides a mechanism for enforcing policy at the cluster boundary. The request reaches the Kubernetes API, an admission controller evaluates the image and policy and the workload is either accepted or rejected.
This turns image signing from a recommendation into an enforceable deployment requirement. A production cluster can require a valid signature from an approved production identity and reject the workload if the signature is missing or the signer is not authorized.
The model is consistent with earlier supply chain approaches described by DevOps.com, including real-time enforcement of container properties at deployment time using attestations and Kubernetes policy controls.
What Deployment Policy Actually Checks
A mature image-signing policy can evaluate more than the existence of a signature. A production policy might require a valid signature, an approved signer, an expected repository, an approved build identity, required provenance, required security attestations and an approved image digest.
Therefore, the policy becomes a formal definition of what the organization considers a trusted production artifact. The question is no longer simply whether an image is signed, it is whether the artifact satisfies the organization’s definition of a trusted release.
Image Signing Isn’t Vulnerability Scanning
Signing and vulnerability scanning solve different problems. A vulnerability scanner asks what is inside the image and whether known security weaknesses exist in its operating system packages, libraries or application dependencies.
A signature asks whether the artifact can be cryptographically associated with an expected signer and whether its contents correspond to the signed artifact.
Both can be true at the same time: A signed image can contain a critical vulnerability, while an unsigned image can contain no currently known vulnerability. Therefore, a mature DevSecOps pipeline treats testing, vulnerability scanning, SBOM generation, provenance and signing as related but distinct controls.
Signature vs. Attestation
A signature establishes cryptographic evidence about an artifact and its signer. An attestation can carry additional claims about how the artifact was produced or what was observed during the build.
An organization may want evidence about the source repository, commit, CI workflow, build environment, dependencies, test results, SBOM or security scans. Those claims can complement the signature without changing the application image itself.
This distinction matters because knowing who signed an artifact does not necessarily explain how that artifact was produced. A trusted production identity could still be associated with a compromised build process. That is why signing increasingly works alongside provenance, SBOMs and other forms of build evidence.
What Happens if the CI Pipeline is Compromised
Suppose an attacker compromises a CI workflow before the signing operation. The attacker modifies the source or build process, produces a malicious image and then causes the legitimate signing workflow to sign it. The resulting image may have a valid signature.
That does not automatically mean the signing architecture has failed. It means the trust boundary was placed too late in the process. Therefore, the security model must consider the complete build chain, from source repository and build configuration through the CI runner, build process, signing identity, registry and deployment.
This is one reason software supply chain security increasingly combines artifact signing with provenance and build integrity. The signature is evidence, but the quality of that evidence depends on the identities and processes that produced it.
Why Ephemeral CI Runners Matter
Ephemeral runners reduce the persistence of credentials and build state, but they do not automatically make a pipeline trustworthy. A temporary runner can still be compromised during execution.
Therefore, the important architectural question is what the runner is allowed to access. A production signing workflow should minimize long-lived credentials, broad registry permissions, persistent signing keys, interactive access, unrestricted network access and cross-environment identity reuse.
A stronger model gives the build only the permissions required for its specific task and uses short-lived identities wherever possible.
What Happens After the Image is Admitted
Successful signature verification does not end the security process. Once Kubernetes accepts the workload, the cluster still has to pull the image, start the container and enforce runtime policies.
Runtime security may involve network policies, workload identity, secrets management, runtime detection and resource restrictions. Image signing establishes trust in the artifact. It does not establish trust in everything the running application can subsequently do.
Building a Complete Trusted Delivery Architecture
The strongest architectures treat container signing as one layer in a larger chain of evidence. A production workflow can connect source controls, CI build checks, dependency analysis, SBOM generation, vulnerability scanning, provenance, container signing, registry distribution, deployment policy and Kubernetes admission.
Each control answers a different question. A vulnerability scanner does not establish provenance. A signature does not prove that the application is free of vulnerabilities. A registry does not establish that a particular CI workflow produced an artifact. Kubernetes admission does not determine whether the application’s dependencies are secure.
The objective is not to make one security mechanism responsible for everything. It is to create enough independent evidence so that the deployment system can make a meaningful trust decision.
The Operational Side of Container Signing
The cryptographic mechanism is only one part of the problem. Enterprises also need to decide who owns signing identities, which environments can sign production artifacts, how identities are rotated, what happens when a signing identity is compromised and how signatures are audited.
Ownership becomes particularly important when multiple teams share infrastructure. Development, staging and production should not automatically share the same signing identity.
Separating identities by environment allows deployment policy to become more precise. A production cluster can require a production signer without trusting every identity that exists elsewhere in the organization.
From Container Signing to Software Supply Chain Security
Container signing is often introduced as a way to prove that an image came from an expected source. Its larger value appears when signing becomes part of a broader software supply chain model.
The artifact can carry evidence about who produced it, how it was built, which source produced it, which dependencies were included, which security checks passed, whether the artifact was modified and whether the signer is authorized.
DevOps.com has also covered the broader challenge of securing software supply chains, including the relationship between artifact integrity, provenance, registries and Kubernetes environments. The important architectural idea is that trust must travel with the software rather than ending at the CI pipeline.
Final Thoughts
Container image signing solves a specific problem: Establishing cryptographic evidence about the identity and integrity of an artifact.
Its real value appears when that evidence is connected to the rest of the software delivery system. The build pipeline produces the artifact. The signing system establishes cryptographic evidence. The registry distributes the artifact and associated metadata. The deployment system retrieves that evidence. Kubernetes admission can enforce the organization’s policy before the workload enters the cluster.
This creates a stronger chain than simply trusting an image tag or assuming that an image stored in a trusted registry is automatically trustworthy.
The next evolution is to connect signatures with provenance, SBOMs, attestations and workload identity. At that point, the deployment decision is based on a collection of verifiable evidence about how the software was built, who produced it and whether the resulting artifact satisfies the organization’s deployment policy.
For DevOps teams, this is the architectural shift that matters. Container signing is not simply about putting a signature on an image. It is about giving the software delivery system enough cryptographic evidence to make a meaningful trust decision before software becomes a running workload.
Frequently Asked Questions
What does container image signing actually prove?
It provides cryptographic evidence that an artifact corresponds to a specific signed identity and has not changed relative to that signed content. It does not prove the software is vulnerability-free.
Why are image digests more important than tags?
Tags can move and point to different images over time. Digests identify a specific content state, so signing by digest creates a stronger link between the signature and the artifact actually being deployed.
Why verify signatures at Kubernetes admission?
Because workloads may enter a cluster through CI systems, GitOps controllers or manual deployment paths. Admission control provides a common enforcement point at the cluster boundary.
