10 Best Practices zum Sichern von Docker-Images. Teil 1

Eine Übersetzung des Artikels wurde speziell für Studenten des Linux-Sicherheitskurses erstellt .




In diesem Artikel möchten wir uns auf Docker konzentrieren und Tipps und Tricks diskutieren, die einen sichereren und qualitativ hochwertigeren Prozess für die Verarbeitung von Docker-Bildern bieten.

Beginnen wir also mit unserer Liste von 10 bewährten Methoden für die Docker-Imagesicherheit.

1. Bevorzugen Sie minimale Grundbilder


Häufig können Sie Projekte mit einem einfachen Docker-Container-Image starten, indem Sie beispielsweise „standardmäßig“ eine Docker- Dockerfile mit dem FROM node schreiben. Beachten Sie jedoch bei der Angabe eines Node-Images, dass die vollständig installierte Debian Stretch-Distribution das Basis-Image ist, mit dem es erstellt wird. Wenn für Ihr Projekt keine gemeinsamen Systembibliotheken oder Dienstprogramme erforderlich sind, sollten Sie die Verwendung eines voll funktionsfähigen Betriebssystems als Basisimage vermeiden.

Im Snyk Open Source-Sicherheitsstatusbericht 2019 haben wir festgestellt, dass viele der beliebten Docker-Container auf der Docker Hub-Website Bilder enthalten, die viele bekannte Sicherheitslücken aufweisen. Wenn Sie beispielsweise das beliebte Universal docker pull node Image verwenden, geben Sie das Betriebssystem tatsächlich in Ihre Anwendung ein, deren Systembibliotheken bekanntermaßen 580 Sicherheitslücken aufweisen.



Wie Sie dem Sicherheitsbericht entnehmen können, enthielt jedes der zehn beliebtesten Docker-Images, die wir im Docker Hub getestet haben, bekannte Schwachstellen. Indem Sie minimale Images bevorzugen, die nur die für die Ausführung Ihres Projekts erforderlichen Systemtools und Bibliotheken kombinieren, minimieren Sie auch den Angriffsbereich für Angreifer und stellen sicher, dass Sie ein sicheres Betriebssystem bereitstellen.

ERFAHREN SIE MEHR ÜBER DIE SICHERHEIT IHRER BILDER

2. Am wenigsten privilegierter Benutzer


Wenn in der Dockerfile nicht USER , wird der Container standardmäßig als Root-Benutzer ausgeführt. In der Praxis gibt es nur wenige Gründe, warum ein Container über Root-Berechtigungen verfügen muss. Docker startet Container standardmäßig mit dem Root-Benutzer. Wenn dieser Namespace dem Root-Benutzer in einem laufenden Container zugeordnet wird, hat der Container möglicherweise Root-Zugriff auf dem Docker-Host. Das Ausführen der Anwendung in einem Container mit einem Root-Benutzer erweitert den Angriffsbereich weiter und bietet eine einfache Möglichkeit, die Berechtigungen zu erhöhen, wenn die Anwendung selbst für Exploits anfällig ist.

Aktivieren Sie die Erstellung eines dedizierten Benutzers und einer dedizierten Gruppe im Docker-Image für die Anwendung, um die Belichtung zu minimieren. Verwenden Sie die USER Direktive in der Dockerfile , um zu überprüfen, ob der Container die Anwendung mit dem geringsten Zugriffsrecht startet.

Möglicherweise ist im Image kein dedizierter Benutzer vorhanden. Erstellen Sie diesen Benutzer anhand der Anweisungen in der Dockerfile .

Das Folgende ist ein vollständiges Beispiel dafür, wie dies für ein universelles Ubuntu-Image getan wird:

 FROM ubuntu RUN mkdir /app RUN groupadd -r lirantal && useradd -r -s /bin/false -g lirantal lirantal WORKDIR /app COPY . /app RUN chown -R lirantal:lirantal /app USER lirantal CMD node index.js 

Beispiel oben:

  • Erstellt einen Systembenutzer (-r) ohne Kennwort, ohne Installation eines Basisverzeichnisses und ohne Shell
  • Fügt den von uns erstellten Benutzer der vorhandenen Gruppe hinzu, die wir zuvor erstellt haben (mithilfe von groupadd).
  • Fügt das letzte Argument in Kombination mit der von uns erstellten Gruppe dem Namen des Benutzers hinzu, den wir erstellen möchten

Node.js und alpine Images enthalten bereits einen generischen Benutzer namens node . Hier ist ein Beispiel für Node.js unter Verwendung des generischen Benutzerknotens:

 FROM node:10-alpine RUN mkdir /app COPY . /app RUN chown -R node:node /app USER node CMD [“node”, “index.js”] 

Wenn Sie Node.js-Anwendungen entwickeln, können Sie auf die offiziellen Best Practices von Docker und Node.j verweisen.

3. Signieren und überprüfen Sie die Bilder, um MITM-Angriffe zu vermeiden


Die Authentizität von Docker-Bildern ist ein Problem. Wir verlassen uns auf diese Bilder, weil wir sie buchstäblich als Container verwenden, in dem unser Code in der Produktion ausgeführt wird. Daher ist es wichtig sicherzustellen, dass das von uns verwendete Bild genau das ist, das der Verlag liefert, und dass keine Seite es geändert hat. Fälschungen können durch eine kabelgebundene Verbindung zwischen dem Docker-Client und der Registrierung oder durch Hacken der Registrierung des Besitzerkontos auftreten, um das Image zu ersetzen.

Überprüfen eines Docker-Images


Mit den Standardeinstellungen von Docker können Sie Docker-Bilder abrufen, ohne ihre Authentizität zu überprüfen. Dies kann möglicherweise zur Verwendung von Docker-Bildern führen, deren Ursprung und Autor nicht überprüft werden.

Es wird empfohlen, Bilder unabhängig von den Richtlinien immer zu überprüfen, bevor Sie sie verwenden. Aktivieren Sie Docker Content Trust vorübergehend mit dem folgenden Befehl, um mit der Validierung zu experimentieren:

 export DOCKER_CONTENT_TRUST=1 

Versuchen Sie nun, das Bild aufzurufen, von dem Sie wissen, dass es nicht signiert ist. Die Anfrage wird abgelehnt und das Bild wird nicht empfangen.

Unterschrift Docker Bilder


Bevorzugen Sie von Docker zertifizierte Bilder von vertrauenswürdigen Partnern, die vom Docker Hub überprüft und überwacht wurden, anstelle von Bildern, deren Herkunft und Authentizität Sie nicht überprüfen können.

Mit Docker können Sie Bilder signieren und erhalten so eine weitere Schutzstufe. Verwenden Sie Docker Notary, um Bilder zu signieren. Notar überprüft die Bildsignatur für Sie und blockiert den Start des Bildes, wenn die Bildsignatur ungültig ist.

Wenn die Docker-Inhaltsvertrauensstellung aktiviert ist (siehe oben), wird das Image durch die Zusammenstellung des Docker-Images signiert. Wenn das Image zum ersten Mal angemeldet wird, erstellt und speichert Docker den privaten Schlüssel für Ihren Benutzer in ~/docker/trust . Dieser private Schlüssel wird dann verwendet, um zusätzliche Bilder beim Erstellen zu signieren.

Ausführliche Anweisungen zum Einrichten signierter Bilder finden Sie in der offiziellen Docker-Dokumentation .

4. Finden, beheben und verfolgen Sie Schwachstellen in Open Source-Komponenten


Wenn wir das Basisimage für unseren Docker-Container auswählen, gehen wir indirekt das Risiko aller Sicherheitsprobleme ein, mit denen das Basisimage verbunden ist. Dies können schlecht konfigurierte Standardeinstellungen sein, die nicht zur Sicherheit des Betriebssystems beitragen, sowie Systembibliotheken, die dem ausgewählten Basisimage zugeordnet sind.

Ein guter erster Schritt besteht darin, das minimale Basisimage so gut wie möglich zu verwenden, um die Anwendung ohne Probleme auszuführen. Dies hilft, den Angriffsraum zu verringern, indem die Sicherheitsanfälligkeit begrenzt wird. Auf der anderen Seite führt es keine eigenen Überprüfungen durch und schützt Sie nicht vor zukünftigen Sicherheitslücken, die für die verwendete Version des Basis-Images identifiziert werden können.

Daher besteht eine Möglichkeit zum Schutz vor Sicherheitslücken in Open Source-Software darin, Tools wie Snyk zu verwenden, um das kontinuierliche Scannen und Verfolgen von Sicherheitslücken in allen Ebenen der verwendeten Docker-Images zu ermöglichen.



Mit den folgenden Befehlen wird ein Docker-Image auf bekannte Sicherheitslücken überprüft:

 # fetch the image to be tested so it exists locally $ docker pull node:10 # scan the image with snyk $ snyk test --docker node:10 --file=path/to/Dockerfile 

Das Docker-Image wird auf bekannte Sicherheitsanfälligkeiten überwacht, sodass es nach dem Erkennen neuer Sicherheitsanfälligkeiten im Snyk-Image folgende Benachrichtigungen und Empfehlungen zur Behebung bereitstellen kann:

 $ snyk monitor --docker node:10 

Basierend auf den Scans, die von Snyk-Benutzern durchgeführt wurden, stellten wir fest, dass 44% der Docker-Image-Scans bekannte Sicherheitslücken aufwiesen und für die neuere und sicherere Basis-Images verfügbar waren. Diese Problembehebung, bei der Entwickler Maßnahmen ergreifen und ihre Docker-Images aktualisieren können, ist nur in Snyk verfügbar.
Snyk stellte außerdem fest, dass für 20% aller Docker-Image-Scans nur das Docker-Image neu erstellt werden muss, um Sicherheitslücken zu schließen . Weitere Informationen zur Anzahl der offenen Sicherheitsberichte für 2019 finden Sie im Snyk-Blog.

Das Ende des ersten Teils.

Fortsetzung im zweiten Teil , und jetzt laden wir alle zu einem kostenlosen Webinar zum Thema „Docker-Schwachstellen. Entkomme mit zunehmenden Rechten aus dem Container zum Host .

Source: https://habr.com/ru/post/de480970/


All Articles