Absicherung von Docker-Images

Ein Docker-Image besteht aus einem Stapel von Schichten (Layers), bei denen es sich um unveränderliche, schreibgeschützte Dateisystemänderungen handelt, die auf den darunterliegenden aufbauen. Ganz unten befindet sich das Basis-Betriebssystem, darauf folgen die für den Betrieb erforderlichen Pakete und schließlich ganz oben Ihr eigener Code. Die Absicherung von Docker-Images bedeutet zu kontrollieren, was in sie hineinfließt, und sie nach der Bereitstellung auf dem neuesten Stand zu halten.

Die meisten Schwachstellen eines Containers stammen von Open-Source-Paketen und -Bibliotheken, die mitgeliefert werden. Einige davon, wie cURL oder eine Shell, ruft Ihre App nach dem Start des Containers möglicherweise nie wieder auf und können daher aus dem Image entfernt werden. Andere, wie glibc, sind für die Funktion Ihrer App unerlässlich und können nicht entfernt werden. Die übrigen Schwachstellen sind meist das Resultat menschlicher Fehler, wie etwa ein in einer Schicht hinterlegtes Secret oder ein Container, der mit Root-Rechten läuft.

Dieser Beitrag behandelt, woher die Risiken in einem Docker-Image stammen, wie die Aufrechterhaltung härteter Images (Hardened Images) ein Problem des Schwachstellenmanagements ist, die drei Methoden, mit denen Tools ein Basis-Image gepatcht halten, und wie Aikido die Images, die Sie bereits ausführen, härtet und patcht.

{{cta}}

TL;DR

Die Absicherung von Docker-Images umfasst das Entfernen ungenutzter Pakete und das Patchen von Schwachstellen im verbleibenden Code. Das Herauszuscheiden nicht genutzter Pakete beseitigt lediglich Schwachstellen in Dingen, die Sie nicht benötigen. Ein anfälliges Paket, auf das Ihre App tatsächlich angewiesen ist, muss dennoch gepatcht werden, und selbst ein minimiertes Image häuft kontinuierlich neue Schwachstellen an. Darüber hinaus erfordert die Annahme gehärteter Images oft die Migration zu einer anderen Distribution und die Aktualisierung im Takt eines anderen Anbieters. Aikido stellt neue, gepatchte Builds derselben Basis-Image-Versionen bereit, die über PR ausgeliefert werden. Wenn Sie eine Version fixiert (gepinnt) haben, können Sie auf dieser Version bleiben, ohne dass es zu Breaking Changes kommt oder auf ein neues Image gewechselt werden muss.

Woher die Risiken in einem Docker-Image stammen 

Der FROM -Zeile ist die erste Anweisung in einem Dockerfile, die das Basis-Image angibt, auf dem Sie aufbauen. Ein FROM node:24 legt das offizielle Node.js-24-Image als Ihre Basis fest, welches zusammen mit der Node.js-Laufzeitumgebung und einem vollständigen Debian-System im Hintergrund ausgeliefert wird. Dazu gehören eine Shell, ein Paketmanager und Systembibliotheken, von denen jede Schwachstellen enthalten kann, die Sie erben, bevor Sie auch nur eine Zeile Ihres eigenen Codes geschrieben haben.

Jede Dockerfile-Anweisung fügt eine Schicht auf die vorherige hinzu, und Schichten sind unveränderlich. Das Löschen von etwas in einer späteren Schicht versteckt es lediglich, sodass alles, was das Basis-Image mitgeliefert hat, im Image verbleibt, unabhängig davon, ob Ihre App es nutzt oder nicht. Ihre App ruft das Meiste von dem, was in der Basis enthalten ist, niemals auf, aber jedes Paket darin stellt eine Angriffsfläche dar.

Beispielsweise war CVE-2023-4911 („Looney Tunables“) eine lokale Schwachstelle zur Privilegienerweiterung im dynamischen Lader von glibc, einer Komponente, die sich in der Basisschicht nahezu jedes gängigen Linux-Images befindet. glibc wurde mit der Distribution geliefert, und jeder Container, der auf einer betroffenen Basis aufgebaut war, enthielt sie. 

Verschiedene Basen, unterschiedliche Risiken

Nicht jedes Basis-Image liefert dieselbe Menge an Daten aus. Ein vollständiges Distributions-Image liefert weit mehr mit, als Ihre App benötigt, einschließlich einer Shell und eines Paketmanagers, die sie wahrscheinlich niemals verwenden wird. Eine Slim-Variante reduziert einen Teil davon. Ein distroloses Image lässt die Shell und den Paketmanager komplett weg und behält nur das bei, was eine Laufzeitumgebung benötigt. Alpine ist von Haus aus klein und war aufgrund der Tatsache, dass es auf musl statt auf glibc basiert, nicht einmal Looney Tunables ausgesetzt.

Die Absicherung von Images ist eine Herausforderung beim Schwachstellenmanagement

Ein gehärtetes Image ist an dem Tag, an dem Sie es erstellen, sauber, driftet jedoch mit der Zeit ab, während in bereits darin enthaltenen Paketen neue Schwachstellen entdeckt werden. Es sicher zu halten bedeutet, das Image so zu behandeln, dass es kontinuierlich gegen neue Offenlegungen abgeglichen und erneut gepatcht wird. Die manuelle Variante umfasst die Verfolgung von Offenlegungen über jedes Paket in jeder Basis sowie das manuelle Backporting oder Aktualisieren der einzelnen Fixes.

Das Festlegen auf eine vertrauenswürdige Version (Pinning) ist sinnvoll, wenn Sie diese Version tatsächlich getestet haben und weiterführen möchten, Sie müssen jedoch dennoch neue Offenlegungen überwachen. Ein festgeschriebenes und vergessenes Image häuft neu entdeckte Schwachstellen an. Wenn dieses Image das Ende seines Lebenszyklus (End-of-Life) erreicht und keine Patches mehr vom Upstream erhält, wächst seine Liste bekannter, ungesampelter Mängel. Beispielsweise hat Node.js 20 am 30. April 2026 sein End-of-Life erreicht, sodass ein Container, der weiterhin an node:20 gebunden ist, zwar läuft, aber jede seitdem gegen diesen Zweig veröffentlichte Schwachstelle ungepatcht bleibt und kein Fix mehr folgt.

Der entgegengesetzte Instinkt, immer sofort zur neuesten Version zu springen, ist genauso fehleranfällig. Beispielsweise ist das xz-utils-Backdoor eine Komprimierungsbibliothek, die in den meisten Linux-Basis-Images enthalten ist. Sie befand sich in zwei spezifischen aktuellen Versionen, 5.6.0 und 5.6.1, und Teams, die noch die ältere 5.4-Linie verwendeten, waren niemals betroffen. Die CISA-Empfehlung lautete danach, ein Downgrade durchzuführen, kein Upgrade. 

Was Sie tatsächlich schützt, sind sorgfältige Entscheidungen bezüglich der von Ihnen verwendeten Versionen. Nehmen wir ein Team, das debian:bookworm festlegt, dokumentiert, dass es sich gegenüber der neuesten Version dafür entschieden hat, weil es sie getestet hat und sie stabil ist, und sie bei neuen Offenlegungen überprüft. Wenn eine neue CVE für ein Paket in diesem Image bekannt wird, wissen sie bereits, dass sie es verwenden und warum. Das ermöglicht ihnen, die tatsächliche Gefährdung gegen die Kosten einer Änderung abzuwägen.

So sichern Sie Docker-Images ab

Angriffsfläche verkleinern

Beginnen Sie mit einem minimalen oder vorab gehärteten Basis-Image. Das Basis-Image bestimmt den Großteil dessen, was Sie erben, weshalb dies die wirkungsvollste Entscheidung ist, die Sie treffen können. (Wird im nächsten Abschnitt näher erläutert)

Verwenden Sie Multi-Stage-Builds, um Build-Tools aus dem finalen Image herauszuhalten. Der Image-Build zieht in der Regel einen Compiler, Entwicklungs-Header und einen Paketmanager heran, um Ihre App zu kompilieren und deren Abhängigkeiten zu installieren. Bei einem Single-Stage-Build verbleibt all dies im finalen Image, obwohl die laufende App es niemals verwendet. Ein Multi-Stage-Build erstellt das Artefakt in einer frühen Phase und kopiert nur dieses in eine saubere finale Phase, sodass keines der Build-Tools mit ausgeliefert wird.

Entfernen Sie Pakete, die die laufende App nicht benötigt. Sie benötigen höchstwahrscheinlich keine Shell, da die meisten Apps ihren Prozess direkt starten und zur Laufzeit niemals eine aufrufen. Hilfsprogramme wie cURL oder wget sind beim Bauen nützlich, aber Sie benötigen sie wahrscheinlich nicht zur Laufzeit, da Ihre App ihre Netzwerkaufrufe über eigene Bibliotheken abwickelt. Und alles, was cURL während des Builds abgerufen hat, ist zum Zeitpunkt der Auslieferung bereits im Image enthalten, sodass nichts mehr übrig ist, was es herunterladen müsste. 

Berechtigungen korrekt konfigurieren

Führen Sie den Container als Non-Root-User aus. Wenn ein Angreifer Code in Ihrer Anwendung ausführt, erhält er genau die Berechtigungen, mit denen der Container läuft. Ein Non-Root-User verringert den potenziellen Schaden eines Einbruchs.

Verwenden Sie ein schreibgeschütztes Root-Dateisystem. Dies hindert einen Angreifer, der bereits eingedrungen ist, daran, Dateien zu schreiben, Tools zu platzieren oder den Container zur Laufzeit zu modifizieren. Alles, was zwingend Schreibrechte benötigt, kann stattdessen einen spezifischen beschreibbaren Mount erhalten.

Entfernen Sie Linux-Capabilities, die Sie nicht nutzen. Container starten mit einer Reihe von Kernel-Capabilities, die die meisten Anwendungen niemals benötigen. CAP_NET_RAWermöglicht es einem Prozess beispielsweise, Netzwerkpakete zu fälschen, und ist standardmäßig aktiviert. Eine typische Webanwendung benötigt dies jedoch nie, während ein eingedrungener Angreifer es nutzen könnte, um Datenverkehr in Ihrem Netzwerk zu spoofing. Entfernen Sie die Capabilities, die Sie nicht brauchen, und fügen Sie nur das hinzu, was erforderlich ist. Das Entziehen dieser Capabilities (und das gezielte Hinzufügen von dem, was Sie benötigen) schließt privilegierte Operationen aus, die einem Angreifer andernfalls zur Verfügung stünden.

Halten Sie Secrets und verirrte Dateien aus dem Image fern

Halten Sie Secrets aus Layern heraus. Ein Secret, das über ARG oder COPY eingebunden wird, verbleibt in der Image-Historie, selbst wenn ein späterer Layer es löscht. Jeder, der das Image abruft, kann die Layer entpacken und das Secret lesen. Nutzen Sie stattdessen Secret-Mounts oder SSH-Mounts um einem einzelnen Build-Schritt ein Secret zur Verfügung zu stellen, ohne es in einen Layer zu schreiben.

Ein Secret aus den Layern herauszuhalten ist nur die halbe Miete. Der laufende Container benötigt den Wert nach wie vor. Injizieren Sie ihn daher zur Laufzeit aus einem dedizierten Secrets-Manager (Vault, einem Cloud-Secrets-Manager oder Kubernetes-Secrets), der als Datei gemountet oder in die Umgebung injiziert wird, und rotieren Sie ihn regelmäßig, anstatt langlebige Anmeldedaten irgendwo fest einzubauen.

Verwenden Sie eine .dockerignore Datei. Sie steuert, was überhaupt erst in den Build-Kontext gelangt, sodass .gitlokale Konfigurationen und verirrte Anmeldedaten niemals durch einen zu breit gefassten COPY -Anweisung.

Gezielt pinnen

Pinnen Sie das Base-Image über den Digest und nicht über das Tag. FROM node:24 wird im Laufe der Zeit neu aufgelöst, sodass zwei Builds im Abstand von einem Monat unterschiedliche Images abrufen können und ein kompromittiertes Base-Image unbemerkt eingeschleust werden kann. Das Pinnen über den Digest (@sha256:...) macht das Base-Image deterministisch, sodass genau das Image gebaut wird, das Sie getestet haben. Beachten Sie jedoch, dass ein gepinnter Digest auch Korrekturen zurückhält, falls Ihr Patching-Modell Fixes als neue Images bereitstellt. Wenn Sie stattdessen einen gepatchten Build derselben Version erhalten können, die Sie gepinnt haben, umgehen Sie dieses Problem und bleiben sicher.

Verlassen Sie sich nicht auf latest. Manche gehen davon aus, dass dies das neueste und stabilste Release bedeutet, aber in Docker ist es lediglich das Standard-Label, das dem letzten Image zugewiesen wird, das ohne explizites Versions-Tag gepusht wurde. Es kann auf ein älteres Image verweisen als erwartet und sich zwischen Builds unbemerkt ändern.

Überprüfen und Warten

Generieren Sie für jedes Image eine SBOM. Eine Software-Stückliste ist das vollständige Inventar dessen, was sich im Image befindet, einschließlich jedes Pakets und jeder Version. Damit können Sie die Frage „Sind wir betroffen?“ in dem Moment beantworten, in dem eine neue Schwachstelle bekannt wird. 

Signieren Sie jedes Image bei der Erstellung und verifizieren Sie diese Signatur vor der Ausführung mit einem Admission Controller, der unsignierte Container abweist. Diese Kette verhindert, dass ein manipuliertes oder nicht genehmigtes Image in die Production gelangt, selbst wenn sich jemand Zugriff auf Ihre Registry verschafft.

Behandeln Sie laufende Container als unveränderlich (immutable). Sobald ein Image deployed ist, sollten Sie den laufenden Container weder patchen noch umkonfigurieren. Erstellen Sie stattdessen ein neues Image, testen Sie es und führen Sie ein erneutes Deployment durch. Was dann läuft, entspricht immer dem, was Sie erstellt, getestet und signiert haben. Das verhindert Konfigurationsdrift und macht Rollbacks so einfach wie das erneute Deployment des vorherigen Images.

Überprüfen Sie Images kontinuierlich. Ein Image, das letzte Woche noch sauber gescannt wurde, kann heute eine kritische Schwachstelle aufweisen, da täglich neue Schwachstellen für darin enthaltene Pakete bekannt werden. Eine Prüfung zum Zeitpunkt des Build reicht daher nicht aus. 

Drei Wege, um ein Basis-Image gehärtet zu halten

Ein Basis-Image beim Bekanntwerden neuer Schwachstellen gehärtet zu halten, ist eine fortlaufende Aufgabe, die auf drei verschiedene Arten gelöst werden kann.

In Eigenregie (Do it yourself)

Pflegen Sie Ihre eigene gehärtete Basis. Wählen Sie ein minimales Image, entfernen Sie alles, was Sie nicht benötigen, und bauen Sie es jedes Mal neu, wenn ein Paket darin eine Schwachstelle aufweist. Sie behalten die vollständige Kontrolle, aber dies erfordert kontinuierliche Arbeit und Wartung. Sie müssen Veröffentlichungen für jedes Paket in der Basis nachverfolgen und jeden Fix manuell backporten oder aktualisieren. Multiplizieren Sie das mit jeder Basis für jeden Service, und es zehrt an allem anderen, was Sie eigentlich entwickeln könnten.

Zu einer neu gebauten Distribution eines Anbieters wechseln

Einige Plattformen liefern gehärtete Images aus, die auf ihrer eigenen Distribution neu aufgebaut wurden. Sie migrieren Ihre Services auf deren Basis, testen sie erneut auf Fehler und richten sich dann nach deren Release-Zyklus, wobei Sie bei jedem Fix auf einen neuen Digest aktualisieren. Damit sind zwei Kostenfaktoren verbunden. Die Migration selbst kann Funktionen beschädigen, auf die sich Ihre App verlassen hat und die der Anbieter entfernt hat. Und das Patchen birgt dieselbe Upgrade-Falle, die auch bei Aktualisierungen von Abhängigkeiten auftritt, bei denen eine neue Major-Version Paketpfade verschieben, Standards ändern und ein funktionierendes Dockerfile beschädigen kann. Wenn Sie einen Digest für die Stabilität festlegen (pinnen), erhalten Sie nicht die Patches, wegen derer Sie das Tool überhaupt eingeführt haben.

Ein Tool die bereits verwendete Basis patchen lassen

Einige Anbieter ermöglichen es Ihnen, Ihre Version beizubehalten, indem sie gepatchte Builds derselben Version bereitstellen, anstatt auf ein neues Image zu wechseln. Sie erhalten einen frischen Build derselben Version mit gepatchtem CVE, den Sie wie jede andere Änderung durch Überprüfung und Merging übernehmen, anstatt das laufende Image zu bearbeiten. Auf diese Weise bleiben Sie auf der bereits getesteten Version und beseitigen dennoch die Schwachstelle.

Wie Aikido Docker-Images absichert

Aikido Security stellt neue gepatchte Builds für genau die Basis-Image-Versionen bereit, die Sie bereits verwenden.

Aikido Images ist eine Registry mit über 2.000 Drop-In-Ersatz-Images, bei denen die bekannten kritischen und schwerwiegenden Schwachstellen in der Basis bereits gepatcht sind. Jedes einzelne wird während des Builds neu erstellt, gepatcht, minimiert und gehärtet, sodass Sie eine kleinere Angriffsfläche und abgesicherte Standardeinstellungen auf der Basis erhalten, die Sie bereits ausführen.

Während ein Tool mit neu aufgebauter Distribution den Patch als neues Image ausliefert, zu dem Sie migrieren müssen, backportet Aikido den Fix auf die von Ihnen festgelegte Version. Es übernimmt den Fix aus dem neueren Release und wendet ihn auf die von Ihnen verwendete Version an, sodass die Änderung klein bleibt und sich das Image wie gewohnt verhält. Wenn ein sauberer Backport nicht möglich ist, aktualisiert oder baut Aikido die Komponente stattdessen neu. Der Austausch erfolgt nahtlos als Drop-in, das AutoFix als Pull Request vorschlägt, und jeder Pull von docker.aikido.io enthält eine SBOM, VEX und SLSA-Provenienz.

Es patcht Versionen auch dann weiter, wenn Upstream-Entwickler diese bereits aufgegeben haben, einschließlich Bases, die das End-of-Life erreicht haben. So können Sie eine ältere Version beibehalten, ohne deren bekannte Mängel mitzuschleppen, und müssen kein Upgrade durchführen, nur um geschützt zu bleiben.

Ein wachsender Anteil realer Fixes für Pakete erhält überhaupt kein CVE. Wenn also Sie oder Ihre Tools nur die CVE-Datenbank lesen, entgehen Ihnen Schwachstellen. Das Patching von Aikido wird teilweise durch Aikido Intel gespeist, das Upstream-Changelogs und die Commit-Historie ausliest, um Schwachstellen aufzuspüren, die im Upstream ohne CVE leise gepatcht wurden. So ist die Abdeckung nicht auf das beschränkt, was öffentliche Datenbanken gerade aufbereitet haben.

Anwendungsspezifische Pakete über npm, PyPI, Maven und Go hinweg werden über Aikido Libraries direkt vor Ort gepatcht, wobei derselbe Backporting-Ansatz wie bei Ihren Abhängigkeiten verwendet wird. Und Aikido Container Image Scanning sucht nach anfälligen Betriebssystempaketen, Abhängigkeiten, veralteten Runtimes, Malware und Lizenzrisiken in Basis-Images, Dockerfile-Befehlen und Kubernetes-Workloads, sodass Fundstellen im Kontext von Code und Cloud angezeigt werden.

Das Team hinter diesen Images kam durch die Übernahme von Root zu Aikido – dem Unternehmen hinter SlimToolkit (ehemals DockerSlim), einem der am häufigsten verwendeten Open-Source-Tools zur Image-Härtung. Die Härtung von Images war der Ursprung dieses Teams, und das Tool ist nach wie vor für jeden frei und kostenlos nutzbar.

{{walkthrough}}

FAQ