You’ve deployed OPA Gatekeeper. You’ve written policies that reject images that haven’t been scanned. Developers are getting blocked at deployment. They’re frustrated because the policy tells them the image failed but doesn’t tell them what to do about it.
The admission controller is working as designed. The experience is terrible. And the security team is getting pressure to loosen the policies.
This is the failure mode of admission control implemented without considering the developer experience. The technical control is correct. The implementation is adversarial.
Why Admission Control Without Context Breaks Trust?
Admission controllers are binary: admit or deny. When they deny, the feedback to the developer is a policy violation message. What the developer needs is: what specifically is wrong, what needs to change, and how do they unblock themselves.
A rejection that says “image doesn’t meet CVE threshold” leaves the developer with questions. Which CVEs? In which packages? What’s the remediation path? Without answers, the developer escalates to the security team, the security team spends cycles on triage, and eventually the team either fixes the image or gets an exception—with neither outcome building developer trust in the security program.
The second failure mode is admission control as the only security gate. If the admission controller is the first place a developer encounters security policy, it’s too late. The image was built, pushed to the registry, referenced in a deployment manifest, and is now being rejected at deploy time. The remediation cycle is long.
Admission control is a last line of defense. Treating it as the first makes everything downstream painful.
Building Admission Control That Works
Enforce policy on already-compliant images
Container image tool integrations that harden images before they reach the admission controller change the economics completely. If images arrive at the admission controller already hardened and already signing attestations, the rejection rate drops to near zero. The admission controller becomes a verification step, not a blocker.
This is the architectural difference between pre-deployment hardening and post-build scanning: hardening changes the artifact, scanning reports on it. Admission controllers that verify hardened images don’t interrupt developers because compliant images pass without friction.
Give developers actionable rejection messages
When an image does fail admission, the rejection message should include: the specific policy violated, the current metric (e.g., CVE count: 48, threshold: 10), and a pointer to the remediation workflow. Rejection messages that aren’t actionable generate support tickets, not remediation.
Use audit mode before enforcement mode
Deploy admission policies in audit mode first. Run them for two to four weeks and observe which images would have been rejected. Fix those images before switching to enforcement mode. Teams that switch directly to enforcement mode without audit period are surprised by the scope of non-compliant images.
Layer admission control with build-time gates
Hardened container images should pass build-time CVE threshold checks before the image is pushed to the registry. The admission controller then serves as a defense-in-depth check, not the primary gate. This distributes the security check to where it’s cheapest to fix: at build time, when the developer is already working on the image.
Practical Implementation Steps
Start with a single high-impact policy. Begin with image signature verification—the policy that requires all pod images to be signed by your CI pipeline. This is a binary check with clear remediation: use the CI pipeline, get the signature. It builds the foundation for more complex policies without immediately blocking all deployments.
Write policies that describe requirements, not rejections. Frame OPA and Kyverno policies as “images must have attribute X” rather than “images without X are rejected.” The policy language and the error message both reflect this framing, making the requirement clear.
Exempt system namespaces and establish an exception process. Not all workloads can be hardened immediately. Establish a documented exception process for workloads that have legitimate reasons to be temporarily non-compliant, with a remediation timeline. Without an exception process, teams bypass admission control rather than engage with it.
Monitor admission control metrics. Track how many deployments are rejected, by which policy, for which teams. High rejection rates for a specific team indicate an implementation problem—either the policy is miscalibrated or the team needs help with the hardening workflow.
Test admission control in the same environment you use for staging deployments. Don’t run admission control policies only in production. Engineers who discover policy violations for the first time in production are the most frustrated. Stage environments should enforce the same policies.
Frequently Asked Questions
What is Kubernetes admission control for image security?
Kubernetes admission control for image security uses admission webhook controllers—such as OPA Gatekeeper or Kyverno—to inspect incoming deployment requests and reject any that reference container images failing defined security policies. These policies can enforce image signature verification, CVE count thresholds, required hardening attestations, or allowed image registry origins. The admission controller acts as a cluster-level gate that enforces image security standards before any pod is scheduled.
Why does Kubernetes admission control frustrate developers if not implemented correctly?
Admission controllers become adversarial when they block deployments without providing actionable rejection feedback. A message that says “image fails CVE threshold” without specifying which CVEs, what the threshold is, or how to remediate leaves developers unable to self-serve a fix. They escalate to the security team, who spends time triaging rather than driving remediation. The result is pressure to loosen policies rather than fix images. Effective admission control requires rejection messages that include the specific violation, the current metric, and a pointer to the remediation workflow.
Should image scanning happen at admission control or earlier in the pipeline?
Both, but the primary gate should be earlier in the pipeline at build time. Admission control is most effective as defense-in-depth verification, not as the first point where a developer encounters security policy. Images that fail at admission control have already been built, tested, pushed to a registry, and referenced in deployment manifests—making the remediation cycle long and disruptive. Build-time hardening that produces compliant images before they reach the admission controller means the controller verifies rather than blocks.
How do you implement Kubernetes admission control policies without disrupting existing deployments?
Deploy admission policies in audit mode first and run them for two to four weeks before switching to enforcement. Audit mode logs which deployments would have been rejected without actually blocking them, giving your team time to identify and remediate non-compliant images. Establish a documented exception process for workloads with legitimate reasons to be temporarily non-compliant. Without an exception process, teams bypass admission control rather than engage with remediation.
The Investment Pays at Scale
For a small fleet, admission control is nice-to-have defense-in-depth. For a fleet of 100+ microservices with 20+ development teams, it’s the only way to maintain security standards without reviewing every deployment manually.
The teams that have built admission control that works—low rejection rates, clear developer experience, no bypass pressure—are the ones that moved hardening earlier in the pipeline. Their admission controllers rarely fire because their CI pipelines produce compliant images. The controller is a confidence check, not a blocker.
That configuration requires investment in the build pipeline, not just the admission controller. But it’s the configuration that scales. An admission controller that blocks 30% of deployments doesn’t survive contact with a large engineering organization.