For most production setups, yes, because they cover different paths. A CI gate stops bad images before they are published. Admission control stops anything that reaches the cluster without passing through that pipeline. If every deployment goes through one controlled path, a CI gate alone can be enough, but few teams can truthfully say that.
What each control sees
| Question | CI gate | Admission control |
|---|---|---|
| Can it block a build before publishing? | Yes | No |
| Does it know the source code and lockfile? | Yes | No |
| Does it see manifests applied by hand? | No | Yes |
| Does it see images pulled from other registries? | Only if configured | Yes |
| Does it see new findings published after the build? | No | Only with a lookup |
| Developer feedback speed | Fast, in pull request | Slow, at deploy |
The key difference is position. CI sits upstream and has context. Admission sits at the last door and has authority. Kubernetes describes admission as the step after authentication and authorization where requests are validated or changed, and the admission controller reference lists the built-in controllers, including ones that are disabled by default such as ImagePolicyWebhook.
When a CI gate alone is enough
- Only the pipeline holds credentials to deploy.
- Nobody can run kubectl apply against production.
- Images come from one registry only.
- You can show evidence that those facts hold.
That is a strong set of conditions. A small team with a single service can meet it. Many cannot, because incident responders, operators and tools often have direct access.
When you need admission as well
- Several teams or pipelines deploy to the cluster.
- Third party charts or operators bring their own images.
- You need to prove to an auditor that unapproved images cannot run.
- You want to enforce rules that depend on cluster context, such as namespace or labels.
The built-in validating policy engine is documented in the Kubernetes Validating Admission Policy page. It handles checks that use only the request, such as allowed registries or digest references, without a webhook.
Keep the rules in one place
The worst arrangement is two policies written separately, so CI allows what admission denies. Define the rules once, test them in CI, and enforce the same set in the cluster. See testing admission policies in CI before the cluster.
A sensible order
- Start with the CI gate. It gives the fastest feedback and teaches teams the rules.
- Add admission in audit mode to see what bypasses CI.
- Fix the bypasses.
- Switch admission to enforce for production, with a break-glass route. See emergency deploys past admission control.
What neither can do
Neither control inspects behaviour of running workloads. They check what is deployed, not what it does afterwards, so pair them with rescans of stored images for newly published advisories.
Where Safeguard fits
Safeguard supplies policies, gates and guardrails for the CI side, plus dependency and image findings that feed deployment decisions. Try a free scan.
Quick check
Which should I build first?
The CI gate. It is cheaper, faster for developers and gives you the policy you will later enforce at admission.
Can admission control replace scanning in CI?
No. It sees the deploy request, not your source or lockfile, and it gives feedback late.
Sources
Last reviewed: 19 October 2026.
