Kubernetes v1.33 behebt Wiederverwendung privater Images über Pods hinweg

In einem Beitrag im Kubernetes Blog vom Mai 2025 beschrieben die Maintainer Ben Petersen und Stanislav Láznička eine wichtige Sicherheitsanpassung in Kubernetes v1.33. Das Update behebt ein seit zehn Jahren bestehendes Problem, bei dem Pods unbeabsichtigt auf private Container-Images zugreifen konnten, die von anderen Pods auf demselben Node gezogen wurden, ohne über die entsprechenden Berechtigungen zu verfügen.

Was passiert ist

Seit über zehn Jahren stoßen Kubernetes-Nutzer auf eine subtile, aber bedeutende Sicherheitslücke im Zusammenhang mit der Einstellung imagePullPolicy: IfNotPresent. Diese Richtlinie ist darauf ausgelegt, die Leistung zu optimieren, indem ein lokal zwischengespeichertes Image verwendet wird, wenn es existiert, anstatt es jedes Mal aus der Registry zu ziehen. Diese Optimierung ignorierte jedoch zuvor die Authentifizierungsgrenzen zwischen verschiedenen Pods, die auf demselben Node geplant waren.

Das Kernproblem entstand, wenn Pod A, autorisiert durch spezifische Anmeldedaten via imagePullSecret, ein privates Image auf einen Node zog. Wenn anschließend Pod B, das sich in einem anderen Namespace befand und keine gültigen Anmeldedaten für dieses private Repository besaß, mit der IfNotPresent-Richtlinie auf denselben Node geplant wurde, erlaubte der Kubelet ihm die Nutzung des zwischengespeicherten Images. Pod B war nie autorisiert worden, das Image zu ziehen, erhielt aber dennoch Zugriff, allein weil die Binär-Layer bereits auf der Festplatte vorhanden waren. Dieses Verhalten verletzte das Prinzip der geringsten Rechte (Least Privilege) und stellte ein potenzielles Risiko für die Lieferkettensicherheit innerhalb der Cluster dar.

Mit der Veröffentlichung von Kubernetes v1.33 haben SIG Auth und SIG Node eine Korrektur eingeführt, die auch bei zwischengespeicherten Images eine Überprüfung der Anmeldedaten erzwingt. Das neue Verhalten stellt sicher, dass ein Pod ein lokal vorhandenes privates Image nur dann nutzen kann, wenn er Anmeldedaten bereitstellt, die mit denen übereinstimmen, die beim ursprünglichen Pull-Vorgang verwendet wurden. Diese Änderung schließt die Sicherheitslücke, während die Leistungs-vorteile des lokalen Caching für autorisierte Workloads erhalten bleiben.

Wie es funktioniert

Die Lösung basiert auf persistenten, dateibasierten Caches, die der Kubelet auf jedem Node verwaltet. Wenn ein Pod ein Image anfordert, das sich derzeit nicht auf dem Node befindet, protokolliert der Kubelet die Absicht zum Pull. Anschließend extrahiert er die Anmeldedaten aus dem referenzierten Kubernetes Secret und führt den Pull aus der privaten Registry durch. Nach erfolgreichem Abschluss speichert der Kubelet einen Datensatz dieses Ereignisses, einschließlich eines Hashwerts der verwendeten Anmeldedaten und der Kennung des Quell-Secrets.

Wenn ein nachfolgender Pod dasselbe Image anfordert, prüft der Kubelet seinen lokalen Cache. Anstatt das zwischengespeicherte Image blind bereitzustellen, vergleicht er die vom neuen Pod bereitgestellten Anmeldedaten mit den gespeicherten Datensätzen. Wenn der Hashwert der Anmeldedaten oder das Quell-Secret mit einem vorherigen erfolgreichen Pull übereinstimmt, wird dem Pod der Zugriff auf das zwischengespeicherte Image gewährt, ohne Daten erneut herunterzuladen. Falls keine Übereinstimmung vorliegt, versucht der Kubelet, das Image unter Verwendung der neuen Anmeldedaten aus der Remote-Registry zu ziehen, was den Standard-Autorisierungsablauf auslöst. Dieser Mechanismus stellt sicher, dass nur Pods mit gültigen, übereinstimmenden Anmeldedaten private zwischengespeicherte Images wiederverwenden können.

Wichtige Details

• Die Korrektur behebt Issue 18787, eine Sicherheitswarnung, die seit über zehn Jahren in Kubernetes bestand.
• Die Funktion ist als Alpha-Version in Kubernetes v1.33 verfügbar.
• Benutzer müssen das Feature-Gate KubeletEnsureSecretPulledImages auf ihren Kubelets aktivieren, um das neue Verhalten zu nutzen.
• Pods, die dieselben Anmeldedaten oder dasselbe Quell-Secret verwenden, müssen sich nicht erneut authentifizieren, was die Leistung erhält.
• Die Richtlinie imagePullPolicy: Never erfordert nun ebenfalls eine Überprüfung der Anmeldedaten für private Images, die bereits auf dem Node vorhanden sind.
• Zukünftige Pläne umfassen die Integration mit Projected Service Account Tokens und die Unterstützung für Ablaufzeiten von Anmeldedaten.

Warum das wichtig ist

Für Software-Ingenieure und Plattform-Teams stärkt diese Änderung die Cluster-Isolation, ohne drastische operative Umstellungen zu erfordern. Zuvor setzten viele Organisationen imagePullPolicy: Always als Workaround ein, um sicherzustellen, dass jeder Pod eine Authentifizierungsprüfung bei der Registry durchführt. Obwohl dies sicher war, legte dieser Ansatz die Image-Registry in den kritischen Pfad für jeden Pod-Start, jede Skalierung oder jeden Neustart, was die Latenz erhöhte und die Abhängigkeit von externen Diensten verstärkte. Der neue Verifizierungsmechanismus ermöglicht es Teams, IfNotPresent sicher zu verwenden, wodurch die Last auf der Registry reduziert und die Startzeiten verbessert werden, während strenge Sicherheitskontrollen beibehalten werden.

Dieses Update vereinfacht auch das Management von Multi-Tenant-Clustern. In Umgebungen, in denen mehrere Teams Nodes teilen, wird das Risiko, dass ein Team versehentlich auf private Images eines anderen Teams zugreift, nun auf Ebene des Kubelet gemindert. Plattform-Ingenieure können sich darauf verlassen, dass die Infrastruktur Zugriffsrichtlinien durchsetzt, anstatt sich ausschließlich auf Netzwerk-Richtlinien oder Admission Controller zu verlassen, um unbefugte Image-Nutzung zu verhindern. Diese Anpassung bringt das Verhalten von Kubernetes näher an die Nutzererwartungen hinsichtlich Sicherheit und Isolation heran.

Was Sie tun können

• Aktualisieren Sie Ihre Test-Cluster auf Kubernetes v1.33, um die neue Funktion zu evaluieren.
• Aktivieren Sie das Feature-Gate KubeletEnsureSecretPulledImages in Ihrer Kubelet-Konfiguration.
• Überprüfen Sie Ihre aktuellen imagePullPolicy-Einstellungen und erwägen Sie, wo angemessen, den Wechsel von Always zu IfNotPresent, um die Leistung zu verbessern.
• Stellen Sie sicher, dass alle Pods, die auf private Images zugreifen, korrekt die erforderlichen imagePullSecrets referenzieren.
• Überwachen Sie die Kubelet-Logs auf Authentifizierungsfehler während der ersten Einführung, um falsch konfigurierte Pods zu identifizieren.
• Lesen Sie KEP-2535 für detaillierte technische Spezifikationen und zukünftige Roadmap-Punkte bezüglich dieser Funktion.