Admission Control & CVE-Scanning: Wie man unsichere Images blockiert bevor sie das Cluster erreiche

Die kontinuierliche Integration und Bereitstellung (CI/CD) hat die Softwareentwicklung revolutioniert. Code-Änderungen fließen vollautomatisch durch Pipelines, werden in Container–Images verpackt und landen binnen Minuten auf den Live-Systemen im Kubernetes-Cluster. Doch diese enorme Geschwindigkeit birgt eine inhärente Gefahr: Wer seine Pipeline nicht an den entscheidenden Stellen absichert, baut eine hocheffiziente Einflugschneise für Schadsoftware und Sicherheitslücken.

Ein wöchentlicher Report oder ein passiver Scanner, der einmal am Tag die Repositories überprüft, reicht im modernen Bedrohungsumfeld und unter den strengen Vorgaben von Regulierungen wie NIS-2 oder dem Cyber Resilience Act (CRA) längst nicht mehr aus. Sicherheit darf kein nachgelagerter Prüfschritt sein. Echte Resilienz in der Software-Lieferkette entsteht erst, wenn die Container Registry und das Kubernetes-Cluster über eine automatisierte Admission Control und integriertes CVE-Scanning als aktiver Gatekeeper zusammenarbeiten. Unsichere Images müssen blockiert werden, bevor sie auch nur einen einzigen Pod im Cluster starten.

Das Problem: Die Trägheit des passiven Scannens

In vielen traditionellen DevOps–Setups verhält sich das Schwachstellen-Management wie eine Alarmanlage, die erst anschlägt, wenn der Einbrecher das Haus bereits wieder verlassen hat. Die Images werden zwar beim Push in die Registry auf bekannte Schwachstellen (CVEs - Common Vulnerabilities and Expositions) analysiert, doch die Konsequenz aus dem Ergebnis fehlt.

Daraus ergeben sich im operativen Alltag drei kritische Vektoren:

1. Das „Good Intentions"-Szenario

Ein Entwickler pusht ein Image, das eine kritische Zero-Day-Schwachstelle in einer genutzten Open-Source-Bibliothek enthält. Der Scanner in der Registry erkennt den Fehler und markiert das Image mit dem Status Critical. Da es jedoch keine technische Barriere gibt, die das Deployment blockiert, zieht das Kubernetes-Cluster (containerd) das Image über die hinterlegten imagePullSecrets unverändert auf die Nodes. Das System ist kompromittiert, obwohl die Schwachstelle bekannt war.

2. Der Faktor Zeit (Day-Two-Vulnerabilities)

Ein Image wird im Januar fehlerfrei und ohne bekannte CVEs gescannt und deployed. Im März wird eine kritische Sicherheitslücke in der Laufzeitumgebung dieses Containers publik. Ein passiver Scanner bemerkt das zwar im Repository, aber das bereits laufende Cluster weiß nichts davon. Startet der Pod nun aufgrund eines automatischen Reschedulings oder einer Skalierung neu, zieht Kubernetes das unsichere Image erneut heran.

3. Fehlende Richtliniendurchsetzung (Policy Enforcement)

Ohne eine automatisierte Kontrollinstanz liegt die Verantwortung für die Einhaltung von Sicherheitsstandards vollständig beim Menschen. Es gibt keine Gewährleistung dafür, dass alle Teams dieselben Schwellenwerte für tolerierbare Risiken anlegen. Was für das eine Team als „Medium" noch durchgeht, bricht im offiziellen Compliance-Audit der Gesamtplattform das Genick.

Die Architektur des Gatekeepers: Harbor und Validating Admission Webhooks

Um die Kette zwischen Entdeckung und Blockierung sauber zu schließen, orchestriert eine souveräne Plattform das Zusammenspiel aus einer Enterprise-Registry (wie Harbor) und den nativen Sicherheitsmechanismen von Kubernetes.javascript [ CI/CD Pipeline ] —> [ git push Image ] —> [ Managed Harbor Registry ] | (Automatischer CVE-Scan) | v [ kubectl apply ] —> [ Kubernetes API Server ] <—> [ Validating Admission Controller ] | (Prüft Scan-Status & Policy) v [ Image freigegeben? ] /
(Ja) (Nein) /
[ Pod startet im Cluster ] [ Deployment hart blockiert & Alerting ]

1. Automatischer Scan-Trigger beim Push

Sobald ein Image in der Harbor-Registry landet, triggert das System sofort den integrierten Vulnerability-Scanner. Das Image wird tiefenanalysiert: Jede installierte Betriebssystem-Bibliothek und jede Software-Abhängigkeit (z. B. npm-, pip- oder Go-Pakete) wird mit den weltweiten CVE-Datenbanken abgeglichen. Das Ergebnis wird als strukturierter Metadatensatz direkt am Image hinterlegt.

2. Der Kubernetes API-Server als Kontrollinstanz

Möchte eine Pipeline oder ein GitOps-Werkzeug (wie ArgoCD) ein Deployment im Cluster starten, sendet es das Manifest an den Kubernetes API-Server. Hier greift die Admission Control. Bevor der API-Server den Befehl in die Etcd-Datenbank schreibt und an die Worker-Nodes weiterreicht, fängt ein Validating Admission Webhook die Anfrage ab.

3. Die Policy-Prüfung in Echtzeit

Der Admission Controller fragt die Harbor-API nach den Sicherheitsmetadaten des spezifischen Image-Tags ab. Nun greift das konfigurierte Regelwerk (die Policy):

• Regelbeispiel: „Blockiere jedes Image, das mindestens eine High- oder Critical-Schwachstelle aufweist oder dessen Scan älter als 7 Tage ist."
• Erfüllt das Image die Kriterien nicht, verweigert der Admission Controller die Freigabe. Der API-Server bricht das Deployment mit einer klaren Fehlermeldung ab. Das Image erreicht niemals die Nodes.

Strategischer Mehrwert: Compliance nach Maß

Die harte Kopplung von Registrierungs-Scanning und Cluster-Zulassung verändert die IT-Sicherheit von einer reinen Kontrollaufgabe zu einem automatisierten, unbestreitbaren Schutzmechanismus:

• Vollständige Umsetzung von Security by Design (CRA & NIS-2): Der Cyber Resilience Act fordert den Nachweis, dass nur sichere Software in den Verkehr gebracht und betrieben wird. Die automatisierte Blockierung liefert den technischen Beweis, dass keine bekannten kritischen Schwachstellen in die Produktion gelangen können.
• Schutz vor Konfigurations-Drift im laufenden Betrieb: Da die Prüfung bei jedem Startvorgang eines Pods stattfindet, fliegen auch Images aus dem System, die zum Zeitpunkt des ersten Deployments als sicher galten, inzwischen aber neue, kritische CVEs aufweisen.
• Entlastung der SecOps-Teams: Sicherheitsverantwortliche müssen nicht länger manuell Reports wälzen und Entwicklern hinterherlaufen. Das System setzt die Unternehmensrichtlinien unbestechlich und rund um die Uhr selbstständig durch.

Fazit: Keine Macht der Black-Box

Geschwindigkeit im Cloud-Native–Zeitalter ist wertlos, wenn sie auf Kosten der Kontrolle geht. Wer seine Container Registry als isolierten Speicherort betrachtet und sein Kubernetes-Cluster ungeprüft alles ausführen lässt, was ein gültiges Secret besitzt, handelt fahrlässig. Erst die logische Verschmelzung von tiefem CVE-Scanning in Harbor und harter Validierung an der Cluster-Grenze schafft eine vertrauenswürdige Lieferkette. Sie nimmt den Teams die Angst vor schnellen Deployments und baut ein digitales Schutzschild, an dem unsicherer Code konsequent abprallt.

FAQ: Admission Control & Scanning in der Praxis

Bremst die Echtzeit-Prüfung beim Admission Control den Start von Pods aus?

Nein, im normalen Betrieb ist die Verzögerung nicht spürbar. Der Admission Controller führt keine eigenen Scans durch, wenn ein Pod startet. Er fragt lediglich die bereits vorhandenen, gecashten Metatags der Harbor-Registry ab. Diese API-Abfrage erfolgt im einstelligen Millisekundenbereich.

Was passiert, wenn die Registry während eines Pod-Restarts temporär nicht erreichbar ist?

Das lässt sich im Admission Controller über die sogenannte Failure Policy definieren. Für hochkritische Umgebungen gilt die Einstellung Fail: Ist die Registry nicht erreichbar, um den Sicherheitsstatus zu verifizieren, wird das Deployment im Zweifel blockiert (Fail-Secure). In weniger kritischen Entwicklungsumgebungen kann auf Ignore gestellt werden, um den Betrieb bei Netzstörungen nicht zu blockieren (Fail-Open).

Wie gehen wir mit “False Positives” oder unvermeidbaren CVEs um?

In der Praxis gibt es oft Schwachstellen, für die vom Upstream-Entwickler noch gar kein Patch existiert, die aber für Ihre spezifische Anwendung irrelevant sind. Harbor bietet hierfür ein integriertes CVE-Cve-Annullierungs-Management (CVE Whitelisting / Allowlisting). Der Sicherheitsbeauftragte kann eine spezifische CVE-ID temporär oder dauerhaft für das Projekt freigeben. Der Admission Controller erkennt diese explizite Freigabe an und blockiert das Image trotz des Fundes nicht.