Sicherheit von Docker-Images

Ein Docker-Image besteht aus einer Reihe von Layern, bei denen es sich um unveränderliche, schreibgeschützte Sätze von Dateisystemänderungen handelt, die auf den darunterliegenden Layern aufgesetzt sind. Ganz unten befindet sich ein Basisbetriebssystem, darauf folgen die für den Betrieb erforderlichen Pakete und ganz oben Ihr eigener Code. Die Absicherung von Docker-Images bedeutet, zu kontrollieren, was in sie aufgenommen wird, und sie nach ihrer Bereitstellung auf dem neuesten Stand zu halten.

Die meisten Sicherheitslücken eines „ container “ stammen aus den Open-Source-Paketen und -Bibliotheken, die darin enthalten sind. Einige davon, wie beispielsweise cURL oder eine Shell, werden von Ihrer Anwendung möglicherweise nie aufgerufen, sobald der „ container “ läuft, und können daher aus dem Image entfernt werden. Andere, wie beispielsweise glibc, sind für die Funktionsfähigkeit Ihrer Anwendung unerlässlich und können nicht entfernt werden. Die übrigen Sicherheitslücken sind in der Regel auf menschliches Versagen zurückzuführen, wie beispielsweise ein in einer Layer eingebettetes Passwort oder ein „ container “, der mit Root-Rechten weiterläuft.

In diesem Beitrag wird erläutert, woher die Risiken in einem Docker-Image stammen, inwiefern die Absicherung von Images ein Problem der „ Schwachstellenmanagement “ darstellt, welche drei Möglichkeiten es gibt, ein Basis-Image mithilfe von Tools auf dem neuesten Stand zu halten, und wie „ Aikido “ die von Ihnen bereits ausgeführten Images absichert und aktualisiert.

{{cta}}

TL;DR

Zur Absicherung von Docker-Images gehört es, nicht verwendete Pakete zu entfernen und Schwachstellen in den verbleibenden Paketen zu beheben. Durch das Entfernen nicht verwendeter Pakete werden lediglich die Schwachstellen in den Komponenten beseitigt, die Sie nicht benötigen. Ein anfälliges Paket, von dem Ihre Anwendung tatsächlich abhängt, muss weiterhin gepatcht werden, und selbst ein minimiertes Image sammelt nach wie vor neue Schwachstellen an. Darüber hinaus ist die Verwendung von gehärteten Images oft mit einer Migration zu einer anderen Distribution und der Anpassung an den Aktualisierungsrhythmus eines anderen Anbieters verbunden. Aikido bietet neue, gepatchte Builds derselben Basis-Image-Versionen, die über PR bereitgestellt werden. Wenn Sie eine Version festgesetzt haben, können Sie so bei dieser Version bleiben, ohne dass es zu bruchbehafteten Änderungen kommt oder Sie auf ein neues Image umsteigen müssen.

Woher das Risiko in einem Docker-Image stammt 

Der FROM Diese Zeile ist die erste Anweisung in einer Dockerfile-Datei, in der das Basis-Image angegeben wird, auf dessen Grundlage Sie das Image erstellen. Ein VON Knoten:24 legt das offizielle Node.js-24-Image als Basis fest, das die Node.js-Laufzeitumgebung sowie ein vollständiges Debian-System als Grundlage enthält. Dazu gehören eine Shell, ein Paketmanager und Systembibliotheken, die jeweils Schwachstellen enthalten können, die Sie übernehmen, noch bevor Sie eine einzige Zeile eigenen Codes geschrieben haben.

Jede Anweisung im Dockerfile fügt eine neue Schicht über der vorherigen hinzu, und diese Schichten sind unveränderlich. Wenn etwas in einer späteren Schicht gelöscht wird, wird es lediglich ausgeblendet; daher verbleibt alles, was in der Basis enthalten ist, im Image, unabhängig davon, ob Ihre App es nutzt oder nicht. Ihre App ruft den Großteil dessen, was in der Basis enthalten ist, zwar nie auf, doch jedes darin enthaltene Paket stellt eine Angriffsfläche dar.

So handelte es sich bei CVE-2023-4911 („Looney Tunables“) beispielsweise um eine lokale Sicherheitslücke im dynamischen Loader von glibc, einer Komponente, die in der Basisschicht fast aller gängigen Linux-Images enthalten ist. glibc war Bestandteil der Distribution, und jedes auf einer betroffenen Basis erstellte „ container “ wies diese Schwachstelle auf. 

Unterschiedliche Grundlagen, unterschiedliches Risiko

Nicht jedes Basis-Image enthält denselben Umfang. Ein vollständiges Distributions-Image enthält weit mehr, als Ihre App benötigt, darunter eine Shell und einen Paketmanager, die sie wahrscheinlich nie nutzen wird. Eine „Slim“-Variante reduziert diesen Umfang etwas. Ein „Distroless“-Image verzichtet gänzlich auf die Shell und den Paketmanager und behält nur das bei, was die Laufzeitumgebung benötigt. Alpine ist von Grund auf klein gehalten und war, da es auf musl statt auf glibc basiert, nicht einmal den „Looney Tunables“ ausgesetzt.

Die Aufrechterhaltung der Bildsicherheit ist ein Problem der „ Schwachstellenmanagement “

Ein gehärtetes Image ist am Tag seiner Erstellung sicher, weicht jedoch im Laufe der Zeit ab, da in den darin enthaltenen Paketen neue Schwachstellen entdeckt werden. Um die Sicherheit zu gewährleisten, muss das Image kontinuierlich auf neue Sicherheitslücken überprüft und entsprechend aktualisiert werden. Bei der manuellen Vorgehensweise müssen die Sicherheitslücken in jedem Paket jeder Basis verfolgt und die jeweiligen Korrekturen manuell zurückportiert oder aktualisiert werden.

Das Fixieren auf eine vertrauenswürdige Version ist sinnvoll, wenn Sie diese Version tatsächlich getestet haben und sie weiterhin ausführen möchten, aber dennoch auf neue Sicherheitslücken achten müssen. Ein Image, das fixiert und dann vergessen wird, sammelt neu entdeckte Schwachstellen an. Wenn dieses Image das Ende seines Lebenszyklus erreicht und keine Patches mehr vom Upstream erhält, wächst die Liste der bekannten, ungepatchten Schwachstellen. Beispielsweise erreicht Node.js 20 am 30. April 2026 das Ende der Lebensdauer (End-of-Life). Ein „ container “, das weiterhin auf „node:20“ festgesetzt ist, läuft zwar weiter, aber jede seit diesem Zeitpunkt für diese Version bekannt gewordene Sicherheitslücke bleibt ungepatcht, da keine Korrektur mehr bereitgestellt wird.

Der gegenteilige Instinkt, immer sofort auf die neueste Version umzusteigen, ist ebenso verfehlt. Die „xz-utils“-Backdoor beispielsweise ist eine Komprimierungsbibliothek, die in den meisten Linux-Basis-Images enthalten ist. Sie war in zwei bestimmten aktuellen Versionen, 5.6.0 und 5.6.1, vorhanden, während Teams, die noch die ältere 5.4-Reihe verwendeten, nie gefährdet waren. Die CISA empfahl im Nachhinein daher ein Downgrade und kein Upgrade. 

Was Ihnen Sicherheit bietet, ist eine sorgfältige Entscheidung hinsichtlich der von Ihnen verwendeten Versionen. Nehmen wir ein Team, das „debian:bookworm“ festlegt, dokumentiert, dass es diese Version gegenüber der neuesten Version bevorzugt hat, weil es sie getestet hat und sie stabil ist, und sie regelmäßig auf neue Sicherheitslücken überprüft, sobald diese bekannt werden. Wenn eine neue CVE für ein Paket in diesem Image veröffentlicht wird, weiß das Team bereits, dass es dieses Paket verwendet und warum. So kann es das tatsächliche Risiko gegen die Kosten einer Umstellung abwägen.

So sichern Sie Docker-Images

Die Angriffsfläche verkleinern

Beginnen Sie mit einem minimalen oder vorab gehärteten Basis-Image. Das Basis-Image bestimmt weitgehend, was Sie übernehmen, daher ist dies die Entscheidung mit der größten Wirkung. (Dies wird im nächsten Abschnitt ausführlicher behandelt.)

Verwenden Sie mehrstufige Builds, um Build-Tools aus dem endgültigen Image fernzuhalten. Beim Erstellen des Images werden in der Regel ein Compiler, Entwickler-Header und ein Paketmanager herangezogen, um Ihre App zu kompilieren und ihre Abhängigkeiten zu installieren. Bei einem einstufigen Build bleibt all das im endgültigen Image enthalten, obwohl die laufende App diese Komponenten nie nutzt. Ein mehrstufiger Build erzeugt das Artefakt in einer frühen Phase und kopiert nur dieses in eine saubere Endphase, sodass keine der Build-Tools mitgeliefert werden.

Entfernen Sie Pakete, die die laufende App nicht benötigt. Wahrscheinlich benötigen Sie keine Shell, da die meisten Apps ihren Prozess direkt starten und zur Laufzeit niemals eine aufrufen. Dienstprogramme wie cURL oder wget sind beim Erstellen nützlich, aber zur Laufzeit benötigen Sie sie wahrscheinlich nicht, da Ihre App ihre Netzwerkaufrufe über eigene Bibliotheken abwickelt. Und alles, was cURL während des Erstellvorgangs abgerufen hat, ist zum Zeitpunkt der Auslieferung bereits in das Image integriert, sodass nichts mehr heruntergeladen werden muss. 

Berechtigungen korrekt festlegen

Führen Sie den „ container “ als Nicht-Root-Benutzer aus. Wenn ein Angreifer Codeausführung in Ihrer App erlangt, erhält er genau die Berechtigungen, mit denen der „ container “ ausgeführt wird. Die Ausführung als Nicht-Root-Benutzer verringert den Schadenumfang eines Einbruchs.

Verwenden Sie ein schreibgeschütztes Root-Dateisystem. Dies verhindert, dass ein Angreifer, der sich bereits im System befindet, Dateien schreibt, Tools ablegt oder das „ container “ zur Laufzeit verändert. Alles, was tatsächlich Schreibzugriff benötigt, kann stattdessen über einen eigenen beschreibbaren Einhängepunkt bereitgestellt werden.

Deaktivieren Sie Linux-Funktionen, die Sie nicht nutzen. Container starten mit einer Reihe von Kernel-Funktionen, auf die die meisten Anwendungen nie zugreifen. CAP_NET_RAW… ermöglicht es beispielsweise einem Prozess, Netzwerkpakete zu fälschen, und ist standardmäßig aktiviert; eine typische Webanwendung benötigt diese Funktion jedoch niemals, während ein Angreifer, der sich Zugang verschafft hat, sie nutzen könnte, um Datenverkehr in Ihrem Netzwerk zu fälschen. Deaktivieren Sie die Funktionen, die Sie nicht benötigen, und aktivieren Sie nur diejenigen wieder, die Sie tatsächlich benötigen. Durch das Deaktivieren dieser Funktionen (und das erneute Aktivieren nur derjenigen, die Sie benötigen) werden privilegierte Vorgänge unterbunden, die einem Angreifer andernfalls zur Verfügung stünden.

secrets -Dateien und vereinzelte Dateien sollten aus dem Image ausgeschlossen werden

Vermeiden Sie „ secrets “ in Ebenen. Ein Geheimnis, das über ARG oder KOPIEREN bleibt im Bildverlauf erhalten, auch wenn eine spätere Ebene sie löscht, und jeder, der das Bild abruft, kann die Ebenen entpacken und lesen. Verwenden Sie geheime Reittiere oder SSH-Einbindungen um ein Geheimnis in einem einzelnen Build-Schritt offenzulegen, ohne es in eine Ebene zu schreiben.

Ein Geheimnis aus den Schichten herauszuhalten, ist nur die halbe Miete. Der laufende container benötigt den Wert weiterhin, daher sollte er zur Laufzeit über einen dedizierten secrets -Manager (Vault, einen Cloud- secrets -Manager oder Kubernetes secrets) bereitgestellt werden, der als Datei eingebunden oder in die Umgebung injiziert wird, und nach einem Zeitplan rotiert werden, anstatt langlebige Anmeldedaten irgendwo fest einzubetten.

Verwenden Sie ein .dockerignore Datei. Sie legt fest, was überhaupt in den Build-Kontext gelangt, daher .git, lokale Konfigurationen und vereinzelte Anmeldedaten werden durch eine pauschale Maßnahme niemals in das Image kopiert KOPIEREN -Anweisung.

Vorsichtig anheften

Befestige die Basis mit „Digest“, nicht mit „Tag“. VON Knoten:24 Da sich die Auflösung im Laufe der Zeit ändert, können zwei Builds, die im Abstand von einem Monat erstellt werden, unterschiedliche Images abrufen, und eine kompromittierte Basis kann unbemerkt eingeschleust werden. Fixierung nach Digest (@sha256:...) sorgt dafür, dass die Basis deterministisch ist, sodass Sie genau das Image erstellen, das Sie getestet haben. Beachten Sie jedoch: Wenn Ihr Patching-Modell Korrekturen als neue Images bereitstellt, werden diese Korrekturen durch einen festgelegten Digest ebenfalls zurückgehalten. Wenn Sie stattdessen einen gepatchten Build derselben Version erhalten können, die Sie festgelegt haben, vermeiden Sie dieses Problem und gewährleisten weiterhin die Sicherheit.

Verlassen Sie sich nicht auf „latest“. Manche gehen davon aus, dass damit die neueste und stabilste Version gemeint ist, aber bei Docker handelt es sich lediglich um das Standard-Label, das dem zuletzt hochgeladenen Image ohne explizites Versions-Tag zugewiesen wird. Es kann auf ein älteres Image verweisen, als Sie erwarten, und sich zwischen den einzelnen Builds ändern.

Überprüfen und pflegen

Erstellen Sie für SBOM für jedes Image. Ein „ Software-Stückliste “ ist eine vollständige Bestandsaufnahme des Inhalts des Images, einschließlich aller Pakete und Versionen. Damit können Sie sofort nach Bekanntwerden einer neuen Sicherheitslücke die Frage „Sind wir betroffen?“ beantworten. 

Signieren Sie jedes Image nach seiner Erstellung und überprüfen Sie diese Signatur vor der Ausführung mithilfe eines Zugangscontrollers, der alle nicht signierten Images zurückweist. Diese Kette verhindert, dass manipulierte oder nicht genehmigte Images in die Produktion gelangen, selbst wenn jemand Zugriff auf Ihr Registry-System erlangt.

Behandeln Sie laufende Container als unveränderlich. Sobald ein Image bereitgestellt wurde, sollten Sie die laufenden Container nicht mehr patchen oder neu konfigurieren container. Erstellen Sie ein neues Image, testen Sie es und stellen Sie es erneut bereit. Was dann läuft, entspricht immer genau dem, was Sie erstellt, getestet und signiert haben. Dadurch werden Konfigurationsabweichungen vermieden, und ein Rollback ist so einfach wie die erneute Bereitstellung des vorherigen Images.

Überprüfen Sie die Images kontinuierlich erneut. Ein Image, das letzte Woche noch einwandfrei gescannt wurde, kann heute bereits eine kritische Sicherheitslücke aufweisen, da täglich neue Sicherheitslücken in Paketen bekannt werden, die bereits darin enthalten sind. Eine Überprüfung zum Zeitpunkt der Erstellung reicht daher nicht aus. 

Drei Möglichkeiten, ein Basis-Image abgesichert zu halten

Die fortlaufende Absicherung eines Basis-Images, sobald neue Sicherheitslücken entdeckt werden, ist eine kontinuierliche Aufgabe, und es gibt drei Möglichkeiten, damit umzugehen.

Mach es selbst

Pflegen Sie Ihre eigene gehärtete Basis. Wählen Sie ein Minimal-Image aus, entfernen Sie alles, was Sie nicht benötigen, und erstellen Sie es jedes Mal neu, wenn ein darin enthaltenes Paket eine Sicherheitslücke aufweist. Sie behalten die volle Kontrolle, doch dies erfordert kontinuierliche Arbeit und Wartung. Sie verfolgen Sicherheitsmeldungen für jedes einzelne Paket in der Basis und portieren oder aktualisieren jede Korrektur manuell. Multiplizieren Sie das mit jeder Basis in jedem Dienst, und es zehrt an all dem anderen, was Sie sonst noch aufbauen könnten.

Wechseln Sie auf das überarbeitete Vertriebsmodell eines Anbieters

Einige Plattformen liefern gehärtete Images aus, die auf ihrer eigenen Distribution neu kompiliert wurden. Sie migrieren Ihre Dienste auf deren Basis, testen erneut auf Fehlfunktionen und richten sich anschließend nach deren Release-Rhythmus, wobei Sie bei jedem Fix auf einen neuen Digest umsteigen. Damit sind zwei Kostenfaktoren verbunden. Die Migration selbst kann alles lahmlegen, worauf sich Ihre App stützte und was der Anbieter entfernt hat. Und das Aufrechterhalten des Patch-Status bedeutet dieselbe Upgrade-Falle, in die jede Erhöhung der Abhängigkeitsversion gerät: Eine neue Hauptversion kann Paketpfade verschieben, Standardeinstellungen ändern und ein funktionierendes Dockerfile unbrauchbar machen. Wenn Sie einen Digest aus Stabilitätsgründen festlegen, erhalten Sie genau die Patches nicht, wegen derer Sie das Tool ursprünglich eingeführt haben.

Lassen Sie ein Tool die von Ihnen bereits ausgeführte Basisversion patchen

Einige Anbieter ermöglichen es Ihnen, Ihre Version beizubehalten, indem sie gepatchte Builds derselben Version bereitstellen, anstatt auf ein neues Image umzusteigen. Sie erhalten einen neuen Build derselben Version, in dem die CVE behoben ist, den Sie wie jede andere Änderung durch Überprüfen und Zusammenführen übernehmen, ohne das laufende Image zu bearbeiten. Auf diese Weise bleiben Sie bei der Version, die Sie bereits getestet haben, und beheben dennoch die Sicherheitslücke.

Wie „ Aikido “ Docker-Images sichert

Aikido Die Sicherheitsabteilung stellt neue, gepatchte Builds derselben Basis-Image-Versionen bereit, die Sie bereits verwenden.

Aikido „Images“ ist ein Verzeichnis mit über 2.000 sofort einsatzbereiten Ersatz-Images, bei denen die bekannten kritischen und hochgradigen Sicherheitslücken in der Basis-Distribution bereits behoben wurden. Jedes Image wird während des Build-Vorgangs neu erstellt, gepatcht, minimiert und abgesichert, sodass Sie eine kleinere Angriffsfläche und streng gesicherte Standardeinstellungen für die von Ihnen bereits genutzte Basis-Distribution erhalten.

Während ein Tool zur Neuerstellung der Distribution den Patch als neues Image bereitstellt, auf das Sie migrieren, portiert „ Aikido “ den Fix auf die von Ihnen festgelegte Version zurück. Dabei wird der Fix aus der neueren Version übernommen und auf die von Ihnen bereits verwendete Version angewendet, sodass der Umfang der Änderung gering bleibt und sich das Image wie gewohnt verhält. Wenn ein sauberes Backport nicht möglich ist, führt „ Aikido “ stattdessen ein Upgrade oder eine Neuerstellung der Komponente durch. Der Austausch erfolgt als „Drop-in“, den AutoFix als Pull-Request vorschlägt, und jeder Pull von docker.aikido.io wird mit einer Herkunftsangabe gemäß „ SBOM “, VEX und SLSA geliefert.

Es werden weiterhin Patches für Versionen bereitgestellt, deren Entwicklung vom Upstream-Projekt bereits eingestellt wurde, einschließlich Basisversionen, deren Lebensdauer abgelaufen ist. So können Sie eine ältere Version beibehalten, ohne deren bekannte Schwachstellen in Kauf nehmen zu müssen, und müssen kein Upgrade durchführen, nur um weiterhin geschützt zu sein.

Ein wachsender Anteil der tatsächlichen Korrekturen an Paketen erhält überhaupt keine CVE-Nummer. Wenn Sie oder Ihre Tools also nur die CVE-Datenbank abfragen, entgehen Ihnen Sicherheitslücken. Die Patches von Aikido stammen zum Teil von Aikido Intel, das die Changelogs und die Commit-Historie des Upstreams auswertet, um Sicherheitslücken zu erfassen, die im Upstream stillschweigend ohne CVE-Nummer behoben wurden. Die Abdeckung beschränkt sich also nicht auf das, was die öffentlichen Datenbanken bisher ergänzt haben.

Pakete auf Anwendungsebene aus npm, PyPI, Maven und Go werden direkt über „Aikido -Bibliotheken“ gepatcht, wobei derselbe Backporting-Ansatz zum Einsatz kommt wie bei Ihren Abhängigkeiten. Und „Aikido “Container Die Image-Prüfung sucht in Basis-Images, Dockerfile-Befehlen und Kubernetes-Workloads nach anfälligen Betriebssystempaketen, Abhängigkeiten, veralteten Laufzeitumgebungen, Malware und Lizenzrisiken, sodass ein Befund zusammen mit dem Code- und Cloud-Kontext angezeigt wird.

Das Team hinter diesen Images kam durch die Übernahme von Root zu „ Aikido “ – Root ist das Unternehmen hinter SlimToolkit (ehemals DockerSlim), einem der am häufigsten genutzten Open-Source-Tools zur Image-Absicherung. Mit der Image-Absicherung hat dieses Team seine Anfänge genommen, und das Tool ist nach wie vor kostenlos und für jedermann frei zugänglich.

{{walkthrough}}

FAQ