Block at admission only when the rule is narrow, the data is fresh and an exception path exists. A blanket deny on every critical CVE will eventually stop an urgent fix. Start in warn and audit mode, then enforce for new images with fixable, exploited findings, and keep a time-limited override.
What admission control can and cannot do
The Kubernetes documentation describes an admission controller as code that intercepts requests to the API server after authentication and authorization but before the object is stored. Mutating controllers run first, then validating ones, and any rejection fails the whole request. Admission does not apply to reads.
This has two consequences. It can stop a new pod from being created with a bad image. It does not touch pods already running. Existing workloads need rescans and rebuilds, not admission.
Decision table
| Situation | Suggested action |
|---|---|
| New image, critical finding, fix available, known exploited | Deny |
| New image, critical finding, no fix available | Warn, require owner acknowledgment |
| Image has no scan result at all | Deny in production, warn elsewhere |
| Image from an unapproved registry | Deny |
| Emergency fix for an outage | Allow through a logged, expiring exception |
| Running pod restarts or reschedules | Evaluate the same rule, but test for surprises first |
The last row catches teams out. A pod that was fine when deployed can be rescheduled onto a new node, and the policy then evaluates it again. If your scan data changed since, the pod may be refused during an incident.
Rollout steps
- Write the rule and apply it with
AuditandWarnactions only. ValidatingAdmissionPolicy, stable since Kubernetes 1.30, lets you setvalidationActionsof Deny, Warn or Audit on the binding. - Watch the audit log for two weeks. Count how many deployments would have been refused.
- Fix the common causes or tune the rule.
- Enforce in a non-production namespace first.
- Enforce in production with a documented exception process and a named approver.
Do not make the gate depend on a live scanner call
If a webhook calls a scanner and the scanner is down, your failure policy decides whether the cluster stops deploying. Prefer checking a stored attestation or a scan result keyed by image digest. See webhook timeouts and failure policy for the tradeoffs.
Try it yourself
Click through it at your own pace, or open it full screen.
See how a gate decides pass or fail from a policy, and try to think of the exception it would need.
Safeguard lets you define policies and gates on scan results, including a free scan at gold.safeguard.sh/scan to see what your images would trigger.
Quick check
Does admission control fix running pods?
No. It evaluates create and update requests. Running pods need a rescan, rebuild and redeploy.
Is warn mode useful?
Yes. It shows developers the message at deploy time and lets you measure impact before you enforce.
Sources
Last reviewed: 19 October 2026.
