Image scanning evaluates a container image and reports what it finds, such as vulnerabilities, malware, or secrets. Kubernetes admission control uses policy to decide whether that image is allowed into the cluster. Scanning informs the decision, while admission control enforces it. Together they provide a prevention gate instead of a purely diagnostic workflow.
Scanning and admission control solve different security jobs
Image scanning is a detection activity. It inspects a container image and reports what it finds, such as known vulnerabilities, embedded secrets, malware indicators, or misconfigurations. kubernetes admission control is an enforcement activity. It evaluates policy at the point of workload admission and can block an image, so the distinction is between finding issues and preventing deployment of an image that fails policy.
That difference matters operationally. Scanning can happen in registries, CI pipelines, or developer workflows, and its output is only as useful as the process that consumes it. Admission control sits on the deployment path, so it is the control that turns scan results, policy checks, and attestations into an actual gate before the workload reaches the cluster.
When teams treat these as substitutes, they usually end up with a diagnostic-only posture. The image may be fully analysed, but if no admission rule consumes the result, the cluster still accepts it. Good practice is to view scanning as one input to a policy decision, not the decision itself.
Why the control boundary matters in container security
Scanning answers the question, “What is inside this image?” Admission control answers, “Should this image be allowed to run here?” That separation is important because an image can be static and unchanged while the runtime policy, cluster policy, or deployment context changes. A previously acceptable image may become non-compliant if the policy tightens, the namespace changes, or a release train requires stronger baselines.
Image scanning is strongest when used early, because it helps teams catch obvious risks before an artifact is promoted. But scanning has blind spots: it cannot stop a risky image from being used if the organisation ignores the findings, and it may miss issues that only become relevant in a specific cluster context. Admission control compensates for that by enforcing a current rule set at deployment time, which is why it is better understood as a prevention gate than a reporting tool. NIST’s Container Security guidance is a useful reference for how image, registry, orchestrator, and runtime controls fit together.
For teams managing secrets and credentials, the distinction is especially important. An image scan may reveal embedded secrets, but the real security outcome depends on whether the platform refuses to admit that image. In NHIMG’s Ultimate Guide to Non-Human Identities, 96% of organisations were found to store secrets outside secrets managers, which shows why detection without enforcement often leaves the underlying exposure intact.
Practitioner guidance for building a real prevention gate
What to prioritise: Use scanning for evidence collection and prioritisation, then decide which findings must block deployment. The decision threshold should usually be stricter for secrets, active vulnerabilities with known exploitability, unsigned or untrusted artifacts, and images that fail your baseline policy.
What to verify: Confirm that admission control is actually consuming a trustworthy signal, such as a scan result, signature, or attestation, rather than relying on a human to review a report after the fact. If the cluster can still admit a failing image through an alternate path, the control is incomplete.
What good looks like: A secure pipeline produces scan findings early, enforces policy at admission, and leaves an auditable trail showing why a workload was allowed or denied. In practice, the strongest posture comes from using both controls together, with scanning informing the policy and admission control enforcing it.
Practitioner takeaway: If you only scan, you detect risk; if you add admission control, you can actually stop it from reaching the cluster.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 — Access Control | Admission control enforces allowed use of artifacts at deployment time. |
| PR.DS-6 — Data is protected | Blocking images with embedded secrets supports protection of sensitive material. | |
| Recommendation — Apply PR.AC-4 to enforce policy-based admission of only approved container images. Use PR.DS-6 to prevent images containing secrets from being deployed. | ||
| CIS Controls v8 | 4 — Secure Configuration of Enterprise Assets and Software | Container admission policy helps prevent insecure software from being deployed. |
| Recommendation — Use CIS Control 4 to block noncompliant images before they enter production. | ||
Related resources from NHI Mgmt Group
- What is the difference between admission control and runtime security in Kubernetes?
- What is the difference between image signing and registry access control in container security?
- What is the difference between image scanning and runtime protection in Kubernetes security?
- What is the difference between image scanning and runtime drift prevention in container security?
