Your Kubernetes cluster is running whatever images developers decide to pull. Some come from Docker Hub. Some from public ECR galleries. A few from an internal registry that was set up two years ago and hasn’t been updated since. Nobody knows where half the images in production actually came from.
An image policy is supposed to fix this. Maintain an approved list, enforce it at admission, done. But in practice, approved image lists become stale within weeks of publication. New versions release. Teams need images the security team hasn’t reviewed. The approved list creates friction without providing proportional security value.
There’s a better model.
Why Static Approved Lists Fail?
A static approved image list solves the wrong problem. It restricts which images can be deployed but says nothing about whether those images are secure. An image can be on the approved list and have hundreds of CVEs—it was approved when it was first reviewed, but base image CVEs have accumulated since.
Maintaining the list requires security team involvement every time a developer needs a new image version. That’s a bottleneck that creates pressure to bypass the process, grant broad exceptions, or simply stop enforcing the policy when it becomes too painful.
The list also doesn’t address the images teams build themselves. Restricting which base images are pulled from external registries doesn’t help if teams are building application images on top of unreviewed bases.
An approved list that requires manual security review for every new image version is a list that gets abandoned under pressure.
A Better Model: Policy on Hardened Image Properties
Instead of approving specific image tags, enforce properties that make images safe:
Signature verification
Container image security starts with knowing where an image came from. Enforce that all images have cryptographic signatures from your CI pipeline or from trusted sources. Unsigned images—including arbitrary Docker Hub pulls—fail automatically.
CVE threshold enforcement
Enforce a maximum CVE count or severity level at admission. Images that exceed the threshold are rejected, regardless of where they came from. This makes “approved” a function of current security posture, not a historical review decision.
Attestation from a hardening process
Require that images carry an attestation from a hardening pipeline. Container vulnerability scanning tool outputs should be attached to the image as a signed artifact. This shifts the model from “did we review this image” to “can this image prove it was hardened.”
Source registry restrictions
Rather than maintaining a list of specific approved images, restrict which registries images can be pulled from. Internal registry plus a curated set of external sources. This is a manageable list that doesn’t require per-image updates.
Practical Steps for Building a Scalable Image Policy
Start with registry source restrictions, not image name restrictions. Configure Kyverno or OPA to reject images from unapproved registries. This is a small list to maintain and eliminates arbitrary Docker Hub pulls without requiring per-image reviews.
Add signature verification as the next layer. Once registry restrictions are in place, add signature requirements. Work with your CI team to ensure all internally built images are signed as part of the build pipeline. Add a process for signing approved external images when they’re mirrored into your internal registry.
Build a curated catalog of pre-hardened base images. Instead of approving individual images, maintain a catalog of pre-hardened base images that teams can use as starting points. Catalog membership is based on CVE threshold compliance, not manual per-version review. When a new version of a base image is released, rebuild the hardened variant and update the catalog automatically.
Automate catalog updates through CI, not security team review. The catalog update workflow should be: upstream releases new version → CI pulls and hardens → hardened image meets CVE threshold → catalog is updated automatically. Security team defines the threshold and reviews exceptions. They don’t review each individual image update.
Use admission audit mode to understand the current state before enforcing. Run your image policies in audit mode for two to four weeks. Understand which images would have been rejected and why. Fix the systemic issues—unsigned images, registry source violations—before switching to enforcement mode.
Frequently Asked Questions
What is a Kubernetes image policy and why does it matter?
A Kubernetes image policy defines rules that control which container images are allowed to run in your cluster, enforced at admission time. Rather than manually maintaining an approved image list, a well-designed image policy enforces properties like cryptographic signatures, CVE thresholds, and source registry restrictions—ensuring that only images that meet your security requirements can be deployed.
How do you enforce an image policy in Kubernetes?
Image policies are enforced using admission controllers such as Kyverno or OPA Gatekeeper. These tools intercept deployment requests and verify that images meet defined requirements—such as being signed by your CI pipeline, coming from an approved registry, and carrying a hardening attestation—before allowing the workload to run in the cluster.
Why do static approved image lists fail to provide real Kubernetes image policy security?
Static approved lists become stale quickly because they approve images at a point in time, not based on current security posture. An image can be on the approved list while accumulating hundreds of CVEs after its initial review. Maintaining the list also requires security team involvement for every new image version, creating a bottleneck that pressures teams to bypass the process entirely.
How does a Kubernetes image policy help with compliance requirements like SOC 2 or FedRAMP?
Compliance frameworks such as SOC 2 Type II, FedRAMP, and PCI DSS require documented evidence that only approved software runs in production. An admission-enforced image policy—requiring signed images, CVE thresholds, and registry source restrictions—provides a defensible, automated control with verifiable evidence that satisfies software supply chain integrity requirements.
What Compliance Requires and What Policy Provides?
Compliance frameworks increasingly require documented evidence that only approved software runs in production environments. SOC 2 Type II, FedRAMP, and PCI DSS all have controls that touch software supply chain integrity.
An image policy enforced via admission control provides a defensible answer: “Only images that have been signed by our CI pipeline, meet our CVE threshold, and come from approved registries can run in our cluster.” That’s a concrete control with automated enforcement and verifiable evidence.
The teams that close compliance findings on image policy fastest are the ones that combine automated enforcement (admission control) with automated compliance (hardened image CI pipeline). The admission controller enforces what the CI pipeline produces. Both together satisfy the compliance control.
Without the automated compliance piece, image policies become an ongoing exception management exercise. With it, the default state is compliant.
