Skip to main content
Snyk Blog

In this article

Ergreifen Sie Maßnahmen, um die Sicherheit Ihrer Docker-Images zu verbessern

Artikel von
Headshot of Brian Vermeer

Brian Vermeer

William Henry

Docker report DARK

17. April 2019

0 Min. Lesezeit

Willkommen beim Bericht zur Docker-Sicherheit: Docker-Sicherheit nach links verschieben. Dieser Bericht ist in mehrere Beiträge unterteilt:

Oder laden Sie unseren liebevoll gestalteten PDF-Bericht herunter, der all diese Informationen und mehr an einem Ort enthält:

Oder laden Sie unseren liebevoll gestalteten PDF-Bericht herunter, der all diese Informationen und mehr an einem Ort enthält.

Das richtige Basis-Image auswählen

Ein beliebter Ansatz für diese Herausforderung sind zwei Arten von Basis-Images: eines für Entwicklung und Unit-Tests und ein weiteres für spätere Testphasen und den Produktionseinsatz. In späteren Testphasen und in der Produktion benötigt Ihr Image keine Build-Tools wie Compiler (zum Beispiel Javac), Build-Systeme (wie Maven) oder Debugging-Tools. In der Produktion benötigt Ihr Image möglicherweise nicht einmal Bash.

Zwischen den grundlegenden Betriebssystem-Images und ihren verschiedenen Varianten gibt es deutliche Unterschiede. Meist ist ein vollständiges Betriebssystem-Image nicht erforderlich. Mit Image-Build-Tools wie Buildah können Sie Images von Grund auf erstellen und nur die benötigten Pakete samt Abhängigkeiten installieren. Dadurch wird die Angriffsfläche von Images erheblich reduziert. Stellen Sie sich ein Python-Anwendungs-Image vor, das nur das Python-Paket, seine Abhängigkeiten und die Python-Anwendung enthält.

Ein weiterer Vorteil von Buildah ist, dass es keinen Docker-Daemon-Prozess benötigt. Das ist wichtig für Container-Bereitstellungsplattformen großen Maßstabs, die Ressourcen für das Erstellen von Container-Images gemeinsam nutzen. Der Docker-Daemon ist ein privilegierter Prozess mit einem offenen Socket für die Kommunikation. Wird der Docker-Daemon kompromittiert, ist der Node gefährdet – oft kann dadurch ein ganzer Cluster kompromittiert werden. Durch die explizite Isolierung von Build-Nodes oder den Einsatz eines Tools wie Buildah entfällt die Notwendigkeit eines Docker-Daemons.

Eine abgespeckte Version oder eine andere Implementierung einer Linux-Distribution kann dazu beitragen, die Anzahl der Schwachstellen zu verringern. Beim Scan des Alpine-Basis-Images – eines nur 5 MB großen Docker-Images auf Basis von Alpine Linux – finden wir keine bekannten Schwachstellen. Das liegt jedoch vor allem daran, dass das Alpine-Projekt kein Sicherheitsbulletin-Programm pflegt. Sind Schwachstellen vorhanden, gibt es daher ohnehin kein offizielles Bulletin, in dem sie veröffentlicht werden. Trotzdem eignet sich Alpine gut als besonders minimales und schlankes Basis-Image.

Auch wenn in der von uns getesteten Version des Alpine-Images keine Schwachstellen erkannt wurden, bedeutet das nicht zwangsläufig, dass sie frei von Sicherheitsproblemen ist. Alpine Linux geht anders mit Schwachstellen um als andere große Distributionen, die lieber eine Reihe von Patches zurückportieren. Alpine setzt auf schnelle Release-Zyklen für seine Images, wobei jedes Image-Release ein Upgrade der Systembibliotheken enthält.

Balkendiagramm mit dem Titel „Schwachstellen in Betriebssystem-Images“: Debian 55, Debian stretch-slim 42, Ubuntu 31, CentOS 1, Fedora 0 und Alpine 0.

Wie Sie der Grafik oben entnehmen können, kann ein Wechsel des Basis-Images in der Dockerfile oder einfach die Verwendung eines anderen Tags für ein Standard-Image einen großen Unterschied machen.

Wenn Sie ein eigenes Image aus einer Dockerfile erstellen, sollten Sie darauf achten, nicht von größeren Images als nötig abhängig zu sein. So verringern Sie die Größe Ihres Images und minimieren zugleich die Anzahl der Schwachstellen, die über Ihre Abhängigkeiten eingeführt werden.

Balkendiagramm mit dem Titel „Schwachstellen in Node.js-Images“: 567 für node:latest, 65 für node:10-slim und 0 für node:10-alpine.

Auf Grundlage der von Snyk-Nutzern durchgeführten Scans haben wir festgestellt, dass 44 % der Docker-Image-Scans bekannte Schwachstellen aufwiesen, für die neuere und sicherere Basis-Images verfügbar waren. Diese Behebungsempfehlung ist einzigartig bei Snyk. Entwickler können Maßnahmen ergreifen, um ihre Docker-Images zu aktualisieren. Es gilt als Best Practice, automatisiert nach neueren oder besseren Basis-Images zu suchen und entsprechende Benachrichtigungen zu versenden.

Multi-Stage-Builds verwenden

Multi-Stage-Builds sind ab Docker 17.05 verfügbar. Sie ermöglichen die Erstellung einer optimierten Dockerfile, die einfach zu lesen und zu pflegen ist.

Bei einem Multi-Stage-Build können Sie mehrere Images verwenden und gezielt nur die benötigten Artefakte aus einem bestimmten Image kopieren. In Ihrer Dockerfile können Sie mehrere FROM-Anweisungen verwenden und für jedes FROM ein anderes Basis-Image angeben. Dabei kopieren Sie die Artefakte von einem Schritt zum nächsten. Nicht benötigte Artefakte können Sie zurücklassen und erhalten dennoch ein kompaktes finales Image.

Mit dieser Methode zur Erstellung eines kleinen Images verringern Sie nicht nur die Komplexität erheblich, sondern auch das Risiko, anfällige Artefakte in Ihr Image aufzunehmen. Statt Images zu verwenden, die auf anderen Images aufbauen, können Sie mit Multi-Stage-Builds die benötigten Artefakte gezielt auswählen, ohne Schwachstellen der Basis-Images zu übernehmen, auf die Sie sich stützen. Weitere Informationen zum Erstellen von Multi-Stage-Builds finden Sie in der Docker-Dokumentation.

Wie bereits im Bericht erwähnt, können Sie auch Tools wie Buildah verwenden, um minimale Produktions-Images mit ausschließlich den Paketen zu erstellen, die für die Ausführung Ihrer Anwendung erforderlich sind. Weitere Informationen zu Buildah finden Sie unter Buildah.io und Podman and Buildah for Docker Users.

Images neu erstellen

Jedes Docker-Image wird anhand einer Dockerfile erstellt. Diese Dockerfiles für Docker-Images auf Docker Hub sind öffentlich auf GitHub verfügbar. Eine Dockerfile enthält eine Reihe von Anweisungen, mit denen sich die Schritte automatisieren lassen, die Sie normalerweise manuell ausführen würden, um ein Image zu erstellen. Außerdem können Bibliotheken importiert und benutzerdefinierte Software installiert werden. Auch dafür enthält die Dockerfile Anweisungen. Im Bericht „State of Open Source Security 2019“ haben wir festgestellt, dass sich 20 % der Docker-Images mit Schwachstellen durch einen einfachen Neuaufbau des Images hätten bereinigen lassen.

Beim Erstellen Ihres Images entsteht im Grunde eine Momentaufnahme des Images zu diesem Zeitpunkt. Wenn Sie von einem Basis-Image ohne festgelegten Tag abhängig sind, kann sich das Basis-Image bei jedem Neuaufbau ändern. Werden Pakete mit einem Paketmanager installiert, kann ein Neuaufbau das Image ebenfalls verändern.

Eine Dockerfile mit folgendem Inhalt kann bei jedem Neuaufbau zu einer anderen Binärdatei führen.FROM ubuntu:latestRUN apt-get -y update && apt-get install -y python

Jedes Docker-Image sollte regelmäßig neu erstellt werden, damit bekannte Schwachstellen, für die bereits eine Lösung verfügbar ist, nicht in Ihrem Image verbleiben. Verwenden Sie beim Neuaufbau die No-Cache-Option --no-cache, um Cache-Treffer zu vermeiden und einen neuen Download sicherzustellen.

Zum Beispiel:docker build --no-cache -t myImage:myTag myPath/

Zusammengefasst sollten Sie beim Neuaufbau Ihrer Images diese Best Practices beachten:

  • Jeder Container sollte nur eine Aufgabe erfüllen.

  • Container sollten unveränderlich, schlank und schnell sein.

  • Speichern Sie keine Daten in Ihrem Container (verwenden Sie einen gemeinsam genutzten Datenspeicher).

  • Container sollten sich einfach löschen und neu erstellen lassen.

  • Verwenden Sie ein kleines Basis-Image (zum Beispiel Linux Alpine). è Kleinere Images lassen sich einfacher verteilen.

  • Installieren Sie keine unnötigen Pakete.

  • So bleibt Ihr Image sauber und sicher.

  • Vermeiden Sie Cache-Treffer beim Erstellen.

  • Scannen Sie Ihr Image vor der Bereitstellung automatisch mit einem Tool wie dem Container-Scan von Snyk, um zu verhindern, dass anfällige Container in die Produktion gelangen.

  • Scannen Sie Ihre Images täglich während der Entwicklung und in der Produktion auf Schwachstellen. Automatisieren Sie auf dieser Grundlage bei Bedarf den Neuaufbau der Images.

Images während der Entwicklung scannen

Das Erstellen eines Images aus einer Dockerfile und sogar der Neuaufbau eines Images können neue Schwachstellen in Ihrem System verursachen. Wir haben bereits gesehen, dass 68 % der Nutzer der Meinung sind, Entwickler trügen eine erhebliche Verantwortung für die Container-Sicherheit. Das Scannen Ihrer Docker-Images während der Entwicklung sollte Teil Ihres Workflows sein, damit Schwachstellen so früh wie möglich erkannt werden.

Wenn Sie die Sicherheit nach links verlagern möchten, sollten Entwickler eine Dockerfile und ihre Images idealerweise auf dem lokalen Rechner scannen können, bevor diese in ein Repository oder eine Build-Pipeline übernommen werden.

Das bedeutet nicht, dass Sie Scans in der CI-Pipeline durch lokale Scans ersetzen sollten. Vielmehr empfiehlt es sich, in allen Entwicklungsphasen zu scannen und diese Scans möglichst zu automatisieren. Denken Sie an automatisierte Scans während des Builds, vor dem Push des Images in eine Registry und vor der Bereitstellung in einer Produktionsumgebung. Es sollte als Best Practice gelten, ein Image nicht in eine Registry oder ein Produktionssystem zu übernehmen, wenn ein automatisierter Scan neue Schwachstellen gefunden hat.

Der kürzlich veröffentlichte Scan von Snyk zur Verwaltung von Container-Schwachstellen analysiert Docker-Images, indem er die Image-Ebenen extrahiert und die Manifestinformationen des Paketmanagers prüft. Anschließend vergleichen wir jedes im Image installierte Betriebssystempaket mit unserer Docker-Datenbank für Schwachstellen. Darüber hinaus ist es entscheidend, die wichtigsten Binärdateien in den Images zu scannen. Snyk unterstützt auch das Scannen wichtiger Binärdateien, die häufig nicht über den Betriebssystem-Paketmanager (dpkg, RPM und APK), sondern auf andere Weise installiert werden, beispielsweise mit einem RUN-Befehl.

Wenn Sie Entwicklern Tools an die Hand geben, mit denen sie Dockerfiles und Images während der Entwicklung auf ihren lokalen Rechnern scannen können, schaffen Sie eine zusätzliche Schutzebene. So können Entwickler aktiv zu einem insgesamt sichereren System beitragen.

Container in der Produktion scannen

Wie sich herausstellt, scannen 91 % der Befragten ihre Docker-Images nicht in der Produktion. Wenn Sie Ihre Container aktiv prüfen, können Sie sich viel Ärger ersparen, sobald eine neue Schwachstelle entdeckt wird und Ihr Produktionssystem gefährdet sein könnte.

Mit den Monitoring-Funktionen von Snyk für Container können Sie Ihr Docker-Image regelmäßig (zum Beispiel täglich) scannen. Snyk erstellt eine Momentaufnahme der Abhängigkeiten des Images und überwacht sie kontinuierlich.

Zusätzlich sollten Sie auch das Laufzeit-Monitoring aktivieren. Wenn Sie in Ihrer Laufzeitumgebung nach ungenutzten Modulen und Paketen suchen, erfahren Sie, wie sich Images verkleinern lassen. Durch das Entfernen ungenutzter Komponenten verhindern Sie, dass unnötige Schwachstellen in System- und Anwendungsbibliotheken gelangen. Außerdem wird das Image dadurch leichter wartbar.

Lesen Sie weiter:

Laden Sie den Bericht jetzt herunter!

Gepostet in:
Container-Sicherheit