Your organization has multiple development teams, each building and deploying container images. Some of those images go through security scanning. Some bypass the scanner. Some are pulled directly from Docker Hub without any internal verification. A new developer pushes an image to the production registry because they have write access and the deployment script references that registry path.
This is the registry governance problem: without policy enforcement at the registry layer, security controls that exist in principle do not enforce in practice.
Why Registry Governance Matters?
Container registries are the distribution mechanism for your production software. Every container that runs in Kubernetes was pulled from a registry. The registry is where supply chain control is possible.
Consider what registry governance enforcement can achieve:
Block unscanned images: Images that have not been through your security pipeline cannot be promoted to the production registry. Developers cannot deploy unscanned images by accident or by urgency.
Enforce CVE thresholds: Images with CVE counts above your organization’s threshold are not admitted to the production registry regardless of who pushed them or when.
Require image signing: Only signed images from verified sources are pullable from production. Images from Docker Hub, CI builds that skipped signing, or unverified sources are blocked.
Enforce hardening status: Images that have not been through runtime profiling and component removal are blocked from promotion even if they pass a raw CVE threshold.
Without these controls at the registry layer, they are policies without enforcement.
The Two-Registry Pattern
The registry governance model that works for most organizations uses two distinct registries with different access controls and promotion criteria:
Staging registry: Open for writes by build systems and developers. This is where images land after being built. Unscanned, unhardened images can be pushed here. No production system pulls from this registry.
Production registry: Write access is granted only to the security pipeline, not to individual developers or CI builds directly. An image enters the production registry only after passing all required security gates: scanning, CVE threshold, hardening, and signing.
This separation makes the governance model structurally enforced rather than policy-enforced. A developer cannot push a vulnerable image to production not because they are forbidden by policy but because they do not have write access to the production registry. The only path to the production registry runs through the security pipeline.
“The registry structure itself is a security control. When the production registry is write-accessible only to the security pipeline, the security pipeline becomes the mandatory path for every image that runs in production.”
The Hardened Image as the Registry Artifact
A container image tool that produces a hardened image artifact changes what the registry stores. Instead of the build artifact (the original developer-built image), the registry stores the security-verified artifact (the hardened image produced by the pipeline).
This matters because:
The hardened image is the production image: What runs in Kubernetes is the hardened artifact, not the build artifact. The security properties are built into the image that is deployed.
Hardening evidence travels with the image: Image signing can include attestations about the security process: this image was scanned on this date with these results, this image was hardened using this runtime profile, this image passed these CVE thresholds.
Rollback uses verified images: When an incident requires rollback, the previous version in the production registry is also a hardened, verified artifact. You are not rolling back to an unverified build.
Admission Control as the Runtime Enforcement Layer
Registry governance controls what enters the registry. Kubernetes admission control is the companion control that enforces at the deployment layer.
Admission controllers configured to verify image signing ensure that images admitted to the cluster were signed by a trusted key — which means they passed through the security pipeline that does the signing. An image pushed directly to a registry without going through the pipeline would have no valid signature and would be rejected at admission.
The combined model:
- Developers push to the staging registry
- The security pipeline scans, hardens, and signs the image
- The signed, hardened image is promoted to the production registry
- Kubernetes admission controllers verify signing before admitting pods
- Only pipeline-processed images run in production
Each step in this chain requires the previous step to have completed. The controls are structurally linked.
Continuous Attestation in Running Containers
Registry governance and admission control verify images at admission time. But what about images that were admitted when they were clean and have since accumulated CVEs?
Container vulnerability scanning tool capabilities that continuously scan running containers address this temporal gap. When a new CVE is disclosed against a package in a running image:
- The continuous scan identifies the affected running containers
- An alert fires with the affected containers, CVE details, and severity
- The security team can prioritize response based on severity and the running container’s criticality
- The pipeline rebuilds and hardens the updated base image
- Rolling deployment replaces running containers with the updated image
This continuous loop maintains the security posture established at initial deployment. Registry governance creates the initial standard; continuous scanning maintains it.
Frequently Asked Questions
What is container registry governance and why does it matter?
Container registry governance is the set of policies and access controls that determine which images are permitted to enter and be pulled from a container registry. It matters because the registry is the distribution point for all production software — without governance, developers can push unscanned or unhardened images directly to production registries, bypassing the security controls that exist in principle. Effective container registry governance makes those security controls structurally enforced rather than advisory.
How do you enforce container image security policies at scale across multiple teams?
The most scalable approach combines a two-registry pattern with policy-as-code tools like OPA/Gatekeeper or Kyverno. Developers push to a staging registry; images only reach the production registry after passing scanning, CVE threshold checks, hardening, and signing through an automated security pipeline. Admission controller policies that require verified image signatures and hardening attestations are then defined once centrally and enforced across all clusters and namespaces, ensuring every team operates under the same security baseline.
What is the two-registry pattern for container security?
The two-registry pattern separates staging and production registries with different access controls. The staging registry accepts writes from developers and CI builds, but no production workloads pull from it. The production registry is write-accessible only to the security pipeline, which means the only path to production runs through scanning, hardening, and signing. This structural separation ensures security controls cannot be bypassed — not because policy prohibits it, but because the access model physically prevents it.
How does container registry governance prevent vulnerable images from reaching production?
Registry governance prevents vulnerable images from reaching production by making the security pipeline the only write path to the production registry. Images that do not pass CVE thresholds, have not been hardened, or lack a valid image signature cannot be promoted to the production registry regardless of who requests it. Kubernetes admission controllers then provide a second enforcement layer, rejecting pods that reference images without valid signatures from the expected build pipeline key.
Policy Operationalization Across Multiple Teams
Large organizations with multiple development teams deploying to shared Kubernetes clusters need governance policies that are operationally consistent across all teams.
Policy-as-code tools like OPA/Gatekeeper or Kyverno enforce admission policies across all clusters and namespaces from a central policy definition. Security teams define the policy once; it is enforced everywhere.
For registry governance specifically, the policies that matter:
Pull policy enforcement: Kubernetes pods should reference images from the production registry by digest, not by tag. Tags are mutable; digests are immutable. Policy that enforces digest-based image references prevents tag confusion attacks and ensures running containers always use verified versions.
Registry allowlisting: Admission control that only allows image pulls from specific trusted registries prevents developers from referencing Docker Hub images directly in production manifests.
Hardening attestation requirement: Policy that requires images to have a hardening attestation (produced by the security pipeline and included in the image signature) before admission creates a direct enforcement connection between registry governance and Kubernetes admission.
Registry governance is the organizational scale control that makes individual image security practices consistent across all teams and all clusters. Without it, security is only as good as the least disciplined team. With it, security is the baseline that all teams must meet to deploy.