No. A new Kubernetes admission policy is evaluated when someone creates, updates or deletes an object, so pods that are already running keep running. The policy bites later, when a Deployment is edited or a pod is recreated. That gap is why a freshly enforced policy can look like it does nothing.
What admission control actually sees
Admission is a step in the API request path. The Kubernetes documentation says admission controllers apply to requests that create, delete or modify objects, and that they cannot block reads such as get, watch or list. Nothing in that description reaches into the node and stops a container that is already up.
So the question to ask is not "which pods break" but "which requests will now be refused". A policy that rejects images from an unapproved registry will refuse the next create or update that names one. A pod that has been running for months from that registry is untouched until something changes it.
When old workloads meet the new rule
A running workload meets the policy at the next event that sends a request to the API server. Common triggers:
| Event | Does the policy run? |
|---|---|
| Pod is recreated by a controller after a node drain or crash | Yes, the new pod is admitted fresh |
| Deployment pod template edited, new rollout | Yes, new pods are created |
| Deployment scaled up or down | New pods are admitted, but scaling alone does not change the template |
| Existing pod keeps running | No new request, no evaluation |
| Someone reads the object with kubectl get | No, reads bypass admission |
The Deployment documentation adds a useful detail: a rollout is triggered if and only if the pod template changes, and scaling does not create a new revision. That means a Deployment can sit untouched for a long time and never be evaluated, then fail on the first routine edit. Teams call this a surprise outage. It is really a deferred finding.
How to find the workloads that would fail
You do not have to wait for the surprise. The ValidatingAdmissionPolicy binding supports validation actions, and the documentation lists Deny, Warn and Audit. Audit puts the failure into the audit event for the API request, and Warn returns a warning to the client.
- Bind the new policy with Warn and Audit first, not Deny.
- Run a dry run of your existing manifests against the cluster so the policy evaluates them without changing anything.
- Read the warnings and the audit annotations, and list every workload that would be refused.
- Fix or deliberately except each one, with an owner and a date.
- Switch the binding to Deny once the list is empty.
If you use the built-in Pod Security admission, the same idea applies at namespace level through the audit and warn modes, which the documentation describes alongside enforce.
Retrofit what is already running
Admission is a gate for change, not an inventory. For what is already deployed, you need a separate sweep: list live objects, run the same rules against them, and track the gap until it closes. Some policy engines can report on existing resources in the background, but check the documentation for the tool you use before relying on that.
Where Safeguard fits
Safeguard's policies, gates and guardrails apply rules at the points where code and dependencies change, and its SBOM and dependency scanning gives you the inventory to check what is already shipped. You can try a free scan on a project to see what a first sweep looks like.
Quick check
Will enforcing a policy kill my running pods?
No. The policy runs on create, update and delete requests. Running pods are only evaluated when something recreates or changes them.
Why did a deploy fail months after we added the policy?
The Deployment was never evaluated until its pod template was edited. The first edit sent a new request through admission and exposed the old violation.
What is the safest way to roll out a new policy?
Bind it with Warn and Audit, collect the list of would-be failures, fix them, then switch to Deny.
Sources
- Kubernetes admission controllers reference
- Kubernetes Validating Admission Policy
- Kubernetes Deployments
- Kubernetes Pod Security Admission
Last reviewed: 19 October 2026.
