Admission Control & CVE Scanning: How to Block Unsafe Images Before They Reach the Cluster

Continuous Integration and Delivery (CI/CD) has revolutionized software development. Code changes flow automatically through pipelines, are packaged into container images, and reach live systems in the Kubernetes cluster within minutes. However, this incredible speed carries an inherent risk: if you don’t secure your pipeline at critical points, you’re creating a highly efficient entry point for malware and security vulnerabilities.

A weekly report or a passive scanner that checks repositories once a day is no longer sufficient in the modern threat landscape and under the strict requirements of regulations like NIS-2 or the Cyber Resilience Act (CRA). Security cannot be a downstream check. True resilience in the software supply chain only emerges when the container registry and Kubernetes cluster work together through automated Admission Control and integrated CVE Scanning as active gatekeepers. Unsafe images must be blocked before they can start a single pod in the cluster.

The Problem: The Inertia of Passive Scanning

In many traditional DevOps setups, vulnerability management behaves like an alarm system that only goes off after the burglar has already left the house. Images are analyzed for known vulnerabilities (CVEs - Common Vulnerabilities and Exposures) when pushed to the registry, but the consequences of the results are lacking.

This results in three critical vectors in operational practice:

1. The “Good Intentions” Scenario

A developer pushes an image containing a critical zero-day vulnerability in a used open-source library. The scanner in the registry detects the flaw and marks the image with the status Critical. However, since there is no technical barrier to block the deployment, the Kubernetes cluster (containerd) pulls the image onto the nodes unchanged via the stored imagePullSecrets. The system is compromised, even though the vulnerability was known.

2. The Time Factor (Day-Two Vulnerabilities)

An image is scanned and deployed in January without any known CVEs. In March, a critical security flaw in the runtime environment of this container becomes public. A passive scanner notices this in the repository, but the already running cluster knows nothing about it. If the pod now restarts due to automatic rescheduling or scaling, Kubernetes pulls the unsafe image again.

3. Lack of Policy Enforcement

Without an automated control instance, the responsibility for adhering to security standards lies entirely with humans. There is no guarantee that all teams apply the same thresholds for acceptable risks. What one team considers “Medium” may break the neck of the entire platform in an official compliance audit.

The Architecture of the Gatekeeper: Harbor and Validating Admission Webhooks

To cleanly close the gap between discovery and blocking, a sovereign platform orchestrates the interaction between an enterprise registry (like Harbor) and the native security mechanisms of Kubernetes.

[ CI/CD Pipeline ] ---> [ git push Image ] ---> [ Managed Harbor Registry ]
                                                          |
                                                  (Automatic CVE Scan)
                                                          |
                                                          v
[ kubectl apply ]  ---> [ Kubernetes API Server ] <---> [ Validating Admission Controller ]
                                 |                        (Checks Scan Status & Policy)
                                 v
                      [ Image Approved? ]
                        /              \
                     (Yes)              (No)
                      /                  \
    [ Pod Starts in Cluster ]      [ Deployment Hard Blocked & Alerting ]

1. Automatic Scan Trigger on Push

As soon as an image lands in the Harbor registry, the system immediately triggers the integrated vulnerability scanner. The image undergoes deep analysis: every installed operating system library and every software dependency (e.g., npm, pip, or Go packages) is checked against global CVE databases. The result is stored as a structured metadata set directly on the image.

2. The Kubernetes API Server as Control Instance

When a pipeline or a GitOps tool (like ArgoCD) wants to start a deployment in the cluster, it sends the manifest to the Kubernetes API server. Here, Admission Control comes into play. Before the API server writes the command into the Etcd database and forwards it to the worker nodes, a Validating Admission Webhook intercepts the request.

3. Real-Time Policy Check

The Admission Controller queries the Harbor API for the security metadata of the specific image tag. The configured rule set (the policy) now applies:

• Example Rule: “Block any image that has at least one High or Critical vulnerability or whose scan is older than 7 days.”
• If the image does not meet the criteria, the Admission Controller denies approval. The API server aborts the deployment with a clear error message. The image never reaches the nodes.

Strategic Value: Tailored Compliance

The tight coupling of registry scanning and cluster admission transforms IT security from a mere control task into an automated, undeniable protection mechanism:

• Full Implementation of Security by Design (CRA & NIS-2): The Cyber Resilience Act requires proof that only secure software is marketed and operated. Automated blocking provides the technical proof that no known critical vulnerabilities can enter production.
• Protection Against Configuration Drift in Ongoing Operations: Since the check occurs at every pod start, images that were considered safe at the time of the first deployment but now have new, critical CVEs are also removed from the system.
• Relief for SecOps Teams: Security officers no longer have to manually sift through reports and chase after developers. The system enforces company policies unerringly and autonomously around the clock.

Conclusion: No Power to the Black Box

Speed in the Cloud-Native era is worthless if it comes at the expense of control. Viewing your container registry as an isolated storage location and allowing your Kubernetes cluster to execute anything with a valid secret unchecked is reckless. Only the logical fusion of deep CVE scanning in Harbor and strict validation at the cluster boundary creates a trustworthy supply chain. It alleviates teams’ fears of rapid deployments and builds a digital shield that consistently repels unsafe code.

FAQ: Admission Control & Scanning in Practice

Does Real-Time Checking with Admission Control Slow Down Pod Starts?

No, in normal operation, the delay is not noticeable. The Admission Controller does not perform its own scans when a pod starts. It merely queries the already existing, cached metatags of the Harbor registry. This API query occurs within single-digit milliseconds.

What Happens if the Registry is Temporarily Unreachable During a Pod Restart?

This can be defined in the Admission Controller via the so-called Failure Policy. For highly critical environments, the setting Fail applies: if the registry is unreachable to verify the security status, the deployment is blocked by default (Fail-Secure). In less critical development environments, it can be set to Ignore to avoid blocking operations during network disruptions (Fail-Open).

How Do We Handle “False Positives” or Unavoidable CVEs?

In practice, there are often vulnerabilities for which no patch exists from the upstream developer yet, but which are irrelevant for your specific application. Harbor offers integrated CVE Allowlisting. The security officer can temporarily or permanently approve a specific CVE ID for the project. The Admission Controller acknowledges this explicit approval and does not block the image despite the finding.