10 Sicherheitstipps für Docker

Sicherheit von Docker-Containern

Die Sicherheit von Docker-Containern betrifft einerseits die Sicherheit der Dockerfiles selbst, also Docker-Base-Images und potenziell fehlerhafte Sicherheitseinstellungen. Andererseits sind aber auch Sicherheitsbelange der Docker-Container während der Laufzeit, also Netzwerk-Ports, Benutzerberechtigungen, der Zugriff auf gemountete Dateisysteme und weitere Themen, von Belang. In diesem Artikel geht es um die Sicherheit von Docker-Containern. Im Mittelpunkt steht dabei die Erstellung von Docker-Images, die Vermeidung von Schwachstellen in Basis-Images und Sicherheitstipps zu Dockerfiles.

Was versteht man unter Docker-Sicherheit?

Docker-Sicherheit bezieht sich auf den Aufbau, die Laufzeit und die Orchestrierung von Docker-Containern. Sie umfasst Sicherheitsbelange in Bezug auf Basis-Images und Laufzeit, darunter etwa Benutzerberechtigungen, Docker-Daemon, eine geeignete CPU-Containersteuerung und weitere Aspekte rund um die skalierbare Orchestrierung von Docker-Containern.

Beim Thema Sicherheit von Docker-Containern lassen sich vier Sicherheitsbelange unterscheiden:

1. Dockerfile-Sicherheit und Best Practices

2. Sicherheit von Docker-Containern zur Laufzeit

3. Sicherheitsrisiken rund um Docker Hub und dessen Bedeutung für Container-Images

4. Sicherheitsfragen bei der cloud-nativen Container-Orchestrierung bzgl. Kubernetes und Helm

In diesem Cheatsheet soll es um das Thema Docker-Sicherheit und Best Practices in diesem Bereich gehen, mit denen die Sicherheit und Qualität von Docker-Images gewährleistet werden kann.

Beachten Sie außer dem unseren Bericht zur Docker-Sicherheit: Docker-Sicherheit nach links verschieben

Und hier unsere zehn Best Practices zum Thema Docker-Sicherheit

1. Minimalistische Basis-Images

Ein häufiges Problem in Sachen Sicherheit von Docker-Containern sind übergroße Images für Docker-Container. Viele Projekte beginnen mit einem generischen Container-Image, etwa indem ein Dockerfile standardmäßig mit einem FROM node erstellt wird. Bei der Festlegung des Node-Images sollte man jedoch beachten, dass die vollständig installierte Debian Stretch-Distribution zugrunde liegt. Erfordert das Projekt allerdings gar keine allgemeinen Systembibliotheken oder Dienstprogramme, ist es ratsam, kein vollständiges Betriebssystem (OS) als Basis-Image zu verwenden.

UnserState of Open Source Security Report 2020 kommt zu dem Schluss, dass viele beliebte Docker-Container im Docker-Hub Images enthalten, die zahlreiche bekannte Schwachstellen aufweisen. So nimmt man mit einem generischen und gerne heruntergeladenen Node-Image wie dem docker pull node ein komplettes Betriebssystem in seine Anwendung auf, dessen Systembibliotheken erwiesenermaßen 642 Schwachstellen enthalten. Das beeinträchtigt die Docker-Sicherheit natürlich von Beginn an.

Die zehn beliebtesten Docker-Images enthalten jeweils mindestens 30 Schwachstellen

Laut dem Open Source Security Report 2020 enthalten die zehn beliebtesten Docker-Images, die in Docker Hub untersucht wurden, allesamt bekannte Schwachstellen. Die einzige Ausnahme bildet hier Ubuntu. Mit minimalistischen Images, die nur die für das Projekt unbedingt notwendigen Systemwerkzeuge und Bibliotheken enthalten, verringert man also die Angriffsfläche und erhöht zudem die Sicherheit des Betriebssystems.

2. Prinzip der geringsten Nutzerrechte

Wird in einer Dockerfile kein konkreter Benutzer angegeben, wird der Container standardmäßig mit dem Root-Benutzer ausgeführt. In der Praxis gibt es nur sehr wenige Anlässe, einem Container Root-Berechtigungen zuzuweisen, da diese mit einiger Wahrscheinlichkeit zu Sicherheitsproblemen führen. Docker-Container werden standardmäßig vom Root-Benutzer ausgeführt. Wird dieser Namensraum dann dem Root-Benutzer in dem ausgeführten Container zugeordnet, erhält dieser möglicherweise einen Root-Zugriff auf den Docker-Host. Wird eine Anwendung im Container mit dem Root-Benutzer ausgeführt, vergrößert dies die Angriffsfläche zusätzlich, da Zugriffsberechtigungen ohne Probleme erweitert werden können, sofern die Anwendung selbst angreifbar ist.

Um dieses Risiko zu verringern, empfiehlt sich für diese Anwendung die Erstellung eines speziellen Benutzers und einer gesonderten Gruppe im Docker-Image. Dazu stellt man mithilfe der Docker-Anweisung USER im Dockerfile sicher, dass der Container die Anwendung mit den geringstmöglichen Zugriffsberechtigungen ausführt.

Möglicherweise enthält das Image aber gar keinen konkreten Benutzer; in diesem Fall sollte man mithilfe der Anleitung im Dockerfile einen solchen erstellen. Nachstehend wird anhand eines Beispiels veranschaulicht, wie man dies bei einem gewöhnlichen Ubuntu-Image anstellt.

1FROM ubuntu
2RUN mkdir /app
3RUN groupadd -r lirantal && useradd -r -s /bin/false -g lirantal lirantal
4WORKDIR /app
5COPY . /app
6RUN chown -R lirantal:lirantal /app
7USER lirantal
8CMD node index.js

In dem obigen Beispiel:

• wird ein Systembenutzer (-r) ohne Passwort, zugeordnetem „Home“-Verzeichnis und Shell erstellt

• wird der so erstellte Benutzer zu einer vorhandenen Gruppe hinzugefügt, die im Vorfeld (per groupadd) eingerichtet wurde

• wird dem Benutzernamen mit Blick auf die erstellte Gruppe ein letztes Argument zugewiesen

Node.js und Alpine-Images erledigen diesen Schritt unter dem Namen node übrigens von sich aus. Hier ein Beispiel zu Node.js mit einem generischen Node-Benutzer:

1FROM node:10-alpine 
2RUN mkdir /app
3COPY . /app
4RUN chown -R node:node /app
5USER node
6CMD [“node”, “index.js”]

Bei der Entwicklung von Node.js-Anwendungen empfiehlt sich ein Blick in die Docker and Node.js Best Practices.

3. Images zum Schutz vor MITM-Angriffen signieren und prüfen

Die Echtheit von Docker-Images sicherzustellen, kann eine echte Herausforderung sein. Schließlich setzen wir großes Vertrauen in diese Images, da wir sie im wahrsten Sinne des Wortes als Container verwenden, die unseren Code in der Produktion ausführen. Deshalb muss gewährleistet sein, dass das abgerufene Image auch tatsächlich vom jeweiligen Publisher stammt und absolut unverändert ist. Manipulationen können etwa auf dem Übertragungsweg zwischen Docker-Client und Registry oder durch Einschleusung von Schad-Images in die Registry des Inhaberkontos erfolgen.

Docker-Images prüfen

Standardmäßig erlaubt Docker die Verwendung von Docker-Images ohne Echtheitsprüfung und öffnet anderen Docker-Images mit unbekanntem Ursprung und Verfasser damit Tür und Tor.

Deshalb sollte man Images vor dem Abruf ungeachtet der geltenden Richtlinien stets genau prüfen. Um das auszuprobieren, kann mit dem folgenden Befehl Docker Content Trust vorübergehend aktiviert werden:

1export DOCKER_CONTENT_TRUST=1

Nun können Sie ein Image abrufen, von dem Sie wissen, dass es nicht signiert ist. Daraufhin wird die Aufforderung abgewiesen und das Image nicht abgerufen.

Docker-Images signieren

Docker Certified-Images von vertrauenswürdigen, geprüften Partnern von Docker Hub sollten stets Vorrang vor Images erhalten, deren Ursprung und Echtheit sich nicht überprüfen lässt.

Docker ermöglicht die Signatur von Images und sorgt damit für noch mehr Sicherheit. Und genau zu diesem Zweck gibt es den Docker Notary. Dieser virtuelle Notar prüft die Signatur und unterbindet die Ausführung von Images mit ungültiger Signatur.

Ist Docker Content Trust wie oben beschrieben aktiviert, werden Images beim Image-Build signiert. Bei der ersten Signatur erzeugt Docker einen privaten Schlüssel für den jeweiligen Benutzer, der unter ~/docker/trust gespeichert wird. Dieser private Schlüssel wird dann auch für die Signatur aller weiteren Images verwendet.

Eine genaue Anleitung zur Einrichtung signierter Images findet sich in der offiziellen Dokumentation von Docker.

Wie unterscheidet sich die Signatur von Docker-Images mit Docker Content Trust und Notary von GPG? Das erklärt Diogo Mónica hier. Grundsätzlich geht es bei GPG aber eher um die Verifizierung und nicht um Replay-Angriffe.

4. Open-Source-Sicherheitslücken aufspüren, schließen und kontrollieren

Bei der Auswahl eines Basis-Images für einen Docker-Container werden indirekt sämtliche Risiken der Container-Sicherheitübernommen, die mit diesem Image einhergehen. Dabei kann es sich etwa um ungünstig konfigurierte Standardeinstellungen handeln, die die Sicherheit des Betriebssystems beeinträchtigen, oder um die in den ausgewählten Basis-Images enthaltenen Systembibliotheken.

In einem ersten Schritt empfiehlt es sich, möglichst minimalistische Basis-Images zu verwenden, die natürlich noch die Ausführung der jeweiligen Anwendung ermöglichen. So verkleinert man die Angriffsfläche durch möglichst wenige Schwachstellen. Andererseits werden so keine eigenständigen Prüfungen durchgeführt und es entsteht kein Schutz vor künftigen Schwachstellen im verwendeten Basis-Image, die erst später bekannt werden.

Schutz vor solchen Schwachstellen in Open-Source-Sicherheitssoftware bieten etwa Tools wie Snyk, um auch kontinuierliche Scans der Docker-Sicherheit und die Prüfung der Schwachstellen, die alle verwendeten Docker-Image-Layer betreffen können, durchzuführen.

Und mit diesen Befehlen lassen sich Docker-Images auf bekannte Schwachstellen hin prüfen:

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

Werden Docker-Images auf bekannte Schwachstellen hin kontrolliert, kann Snyk bei Bekanntwerden weiterer Schwachstellen im Image auf diese hinweisen und Gegenmaßnahmen vorschlagen:

1$ snyk monitor --docker node:10

„Scans durch Snyk-Benutzer haben ergeben, dass in 44 % der Fälle bekannte Schwachstellen vorlagen und eigentlich neuere, sicherere Basis-Images als Alternative vorhanden gewesen wären. Dass solche Gegenmaßnahmen vorgeschlagen werden, ist ein Alleinstellungsmerkmal von Snyk. Auf Grundlage der Vorschläge können die Entwickler dann eingreifen und ihre Docker-Images upgraden.“

Snyk hat auch herausgefunden, dass bei 20 % aller Image-Scans nur ein kompletter Neubau des Docker-Images erforderlich gewesen wäre, um die Anzahl der Schwachstellen zu verringern.

Verfahren zur Prüfung der Container-Sicherheit

Das Scannen Linux-basierter Container-Projekte auf bekannte Schwachstellen ist eine zentrale Voraussetzung für die Sicherheit der Umgebung. Zu diesem Zweck prüft Snyk Basis-Images auf ihre Abhängigkeiten hin: installierte und vom Package Manager verwaltete Betriebssystempakete und Binärdateien – Layers, die nicht vom Package Manager installiert worden sind.

Snyk ist ein kostenloses Tool für die Container-Sicherheit. Auf Grundlage der Prüfergebnisse schlägt Snyk Maßnahmen und Tipps für öffentliche Docker Hub-Images vor. Diese umfassen Empfehlungen zu Basis-Images und den Dockerfile-Layern, in denen die Schwachstellen gefunden wurden, und vieles mehr.

5. Keine sensiblen Daten in Docker-Images

Wird eine Anwendung in einem Docker-Image erstellt, sind manchmal Geheimnisse wie private SSH-Schlüssel oder Token nötig, um Code aus einem privaten Repository abzurufen bzw. private Pakete zu installieren. Werden diese in den zwischengeschalteten Docker-Container kopiert, erfolgt das Caching auf dem Layer, zu dem sie hinzugefügt werden, selbst wenn sie später wieder gelöscht werden. Solche Token und Schlüssel müssen außerhalb der Dockerfile verwahrt werden.

Mehrstufige Builds

Eine weitere Möglichkeit zur Verbesserung der Container-Sicherheit in Docker sind mehrstufige Builds. Docker unterstützt mehrstufige Builds. Auf diese Weise lassen sich Geheimnisse in einem temporären Image-Layer erfassen und verwalten, der später wieder gelöscht wird. So gelangen keine vertraulichen Daten in das Image. Mithilfe von Code lassen sich diese zwischengeschalteten Layer um Geheimnisse ergänzen, wie das folgende Beispiel veranschaulicht:

1FROM ubuntu as intermediate
2
3WORKDIR /app
4COPY secret/key /tmp/
5RUN scp -i /tmp/key build@acme/files .
6
7FROM ubuntu
8WORKDIR /app
9COPY --from=intermediate /app .

Befehle für Docker Secrets

Mit einem Alpha-Feature lassen sich sensible Dateien in Docker ohne Caching mounten. Dies sieht folgendermaßen aus:

Weitere Informationen zu Secrets in Docker finden Sie auf der Homepage.

1# syntax = docker/dockerfile:1.0-experimental
2FROM alpine
3
4# shows secret from default secret location
5RUN --mount=type=secret,id=mysecret cat /run/secrets/mysecre
6
7# shows secret from custom secret location
8RUN --mount=type=secret,id=mysecret,dst=/foobar cat /foobar

Vorsicht vor rekursiven Kopien

Vorsicht ist auch geboten, wenn Dateien in einen Image-Build kopiert werden sollen. Mit dem folgenden Befehl wird beispielsweise der gesamte Kontextordner des Builds rekursiv in das Docker-Image kopiert, das somit vertrauliche Dateien enthalten könnte:

1COPY . .

Enthält ein Ordner also sensible Dateien, sollte man diese entweder entfernen oder per .dockerignore übergehen:

1private.key
2appsettings.json

Wie lassen sich Docker-Container schützen?

Verwenden Sie am besten mehrstufige Builds, damit für die Produktion vorgesehene Container-Images frei von Entwicklerressourcen, Secrets und Token bleiben.

Zudem empfiehlt sich die Verwendung eines Container-Sicherheitstools wie Snyk, mit dem man Docker-Images kostenlos per CLI, Docker-Hub, Amazon ECR, Google GCR etc. überprüfen kann.

6. Unveränderliche Tags

Docker-Images können mehrere Tags beinhalten, bei denen es sich um Abwandlungen derselben Images handelt. Das häufigste dieser Tags ist latest, das die aktuellste Version des Images repräsentiert. Image-Tags sind nicht unveränderlich und können von ihren Urhebern auch mehrfach verwendet werden.

Das bedeutet, dass sich das Basis-Image einer Dockerfile von Build zu Build ändern kann. Dies kann wiederum zu Verhaltensunterschieden führen, die durch die Änderungen am Basis-Image bedingt sind. Dieses Problem lässt sich auf verschiedene Weise umgehen, um die Docker-Sicherheit weiter zu verbessern.

• Immer das am besten passende Tag wählen. Enthält ein Image mehrere Tags, wie :8 und :8.0.1 oder :8.0.1-alpine, sollte man Letzteres bevorzugen, da es sich am genausten auf das Image bezieht. Keine allgemeinen Tags wie „latest“ verwenden. Bedenken Sie, dass auch sehr präzise Tags irgendwann gelöscht werden könnten.

• Um zu verhindern, dass spezifische Image-Tags irgendwann nicht mehr verfügbar sind und den gesamten Betrieb lahmlegen, sollte man die Ausführung einer lokalen Kopie dieses Images in einer Registry oder einem Konto in Erwägung ziehen, auf das man selbst Zugriff hat. Dabei ist zu beachten, dass dieser Ansatz durchaus einigen Mehraufwand bedeutet, der durch die Pflege der Registry entsteht. Die Replikation des zu verwendenden Images in einer eigenen Registry ist eine gute Möglichkeit, um sicherzustellen, dass das verwendete Image nicht verändert wird.

• Auf Genauigkeit achten! Anstatt ein Tag abzurufen, empfiehlt sich der Abruf von Images über deren genaue SHA256-Referenz. So ist garantiert, dass jeder Abruf dasselbe Image ergibt. Achtung: SHA256-Referenzen bergen auch Risiken – wird das Image verändert, existiert der Hash möglicherweise nicht mehr.

Sind Docker-Images sicher?

Docker-Images können auf Open-Source-Linux-Distributionen basieren und Open-Source-Software und -Bibliotheken enthalten. Eine aktuelle Recherche zum Thema Sicherheit und Open Source von Snyk kommt zu dem Ergebnis, dass die beliebtesten Docker-Images mindestens 30 Schwachstellen enthalten.

7. COPY statt ADD

Docker bietet für das Kopieren von Dateien zwischen Host und Docker-Image zwei Befehle: COPY und ADD. Diese sind sich zwar ähnlich, unterscheiden sich aber hinsichtlich ihrer Funktionalität und können durchaus Sicherheitsrisiken bergen.

• COPY: Mit diesem Befehl werden lokale Dateien rekursiv unter Angabe der genauen Quell- und Zieldateien bzw. -verzeichnisse kopiert. Bei COPY sind zudem genaue Ortsangaben zwingend.

• ADD: Mit diesem Befehl werden lokale Dateien rekursiv kopiert. Dabei wird ein Zielverzeichnis erstellt, sofern keines existiert. Als Quelle werden auch Archive als lokale oder Remote-URLs akzeptiert, die dann erweitert bzw. in das Zielverzeichnis heruntergeladen werden.

Die Unterschiede zwischen ADD und COPY sind zwar klein, aber entscheidend. Um potenzielle Sicherheitsrisiken abzuwenden, sollte man sie genau kennen:

• Werden Remote-URLs verwendet, um Daten direkt in einen Quellort zu kopieren, kann dies Man-in-the-Middle-Angriffe begünstigen, bei denen der Inhalt der heruntergeladenen Datei manipuliert wird. Zudem erfordern Herkunft und Echtheit der Remote-URLs eine genaue Überprüfung. Bei COPY müssen Quelle und Herkunft der von Remote-URLs herunterzuladenden Dateien über eine sichere TLS-Verbindung bestätigt werden.

• Platz- und Layer-Erwägungen: COPY ermöglicht eine getrennte Ergänzung von Archiven aus Remote-Quellen und deren Entpacken als eigene Layer, was den Image-Cache optimiert. Sind Remote-Dateien erforderlich, lässt sich der Single-Layer-Ansatz optimieren, indem man sie zu einem RUN-Befehl kombiniert, der heruntergeladen, extrahiert und anschließend bereinigt wird. Mit ADD wären dafür mehrere Layer erforderlich.

• Bei Verwendung lokaler Archive werden diese per ADD automatisch in das Zielverzeichnis extrahiert. Das mag zwar akzeptabel sein, birgt aber die Gefahr von Archivbomben und „Zip Slips“, die in diesem Fall automatisch ausgelöst werden können.

8. Metadaten-Kennzeichnung

Image-Labels enthalten Metadaten zum jeweiligen Image. So lässt sich leichter nachvollziehen, wie das Image zu verwenden ist. Das häufigste dieser Labels ist der „maintainer“. Dieser gibt die E-Mail-Adresse und den Namen der für das Image verantwortlichen Person an. Und mit diesem LABEL-Befehl lassen sich Metadaten hinzufügen:

1LABEL maintainer="me@acme.com"

Neben Angaben zur verantwortlichen Person kann man beliebige weitere Metadaten hinzufügen, die im Einzelfall relevant sind. Dies kann ein Commit-Hash, ein Link zum jeweiligen Build, der Qualitätszustand (wurden sämtliche Prüfungen bestanden?), Quellcode, ein Verweis zum Speicherort der SECURITY.TXT und vieles mehr sein.

Grundsätzlich empfiehlt sich eine SECURITY.TXT-Datei (RFC5785), die auf die geltende Veröffentlichungspolitik zu Docker-Labels verweist. Ein Beispiel dafür sehen Sie hier:

1LABEL securitytxt="https://www.example.com/.well-known/security.txt"

Weitere Informationen zu Labels von Docker-Images finden Sie hier: http://label-schema.org/rc1/

9. Mehrstufige Builds für kleine und sichere Docker-Images

Wird eine Anwendung per Dockerfile erstellt, entstehen zahlreiche Artefakte, die ausschließlich für den Build benötigt werden. Dabei kann es sich um Pakete wie etwa Entwicklertools und Bibliotheken für die Kompilierung, Abhängigkeiten für Unit-Tests oder temporäre Dateien, Secrets und vieles mehr handeln.

Werden diese Artefakte im Basis-Image belassen, das auch für die Produktion verwendet wird, erhöht dies die Größe des Docker-Images. Dadurch kann sich wiederum der Zeitaufwand für den Download vergrößern und es erhöht sich die Angriffsfläche, da mehr Pakete installiert werden müssen. Dasselbe gilt für das verwendete Docker-Image. Möglicherweise braucht man ein bestimmtes Docker-Image für die Erstellung, nicht aber für die Ausführung des Anwendungscodes.

Golang ist dafür ein gutes Beispiel. Für Golang-Anwendungen wird der Go Compiler benötigt. Dieser erzeugt eine ausführbare Datei, die auf allen Betriebssystemen läuft – ganz ohne Abhängigkeiten und eigene Images.

Und genau aus diesem Grund unterstützt Docker mehrstufige Builds. So lassen sich im Entwicklungsprozess mehrere temporäre Images verwenden. Nur das jeweils aktuellste Image wird dann aber mitsamt der überführten Daten aufbewahrt. Auf diese Weise entstehen zwei Images:

• Image 1: sehr groß, mit zahlreichen Abhängigkeiten für Anwendungsentwicklung und Tests.

• Image 2: sehr klein, mit wenigen Bibliotheken und nur einer Kopie der für die Anwendungsausführung in der Produktivumgebung erforderlichen Artefakte.

10. Linter

Mit einem Linter lassen sich häufige Fehler vermeiden und Best Practices zum Verfahren aufstellen, die dann in der Entwicklung automatisch befolgt werden. Es handelt sich dabei um einen Docker-Sicherheitsscan, bei dem Sicherheitsprobleme in Dockerfiles statistisch ausgewertet werden.

hadolint ist einer dieser Linter. hadolint analysiert Dockerfiles und weist auf Verstöße gegen die Best Practices zum Verfahren hin.

"hadolint-docker-image-security/hadolint-docker-image-security"Hadolint ist in integrierten Entwicklungsumgebungen sogar noch leistungsfähiger. Wird hadolint beispielsweise als VSCode-Erweiterung eingesetzt, werden Fehler bereits bei der Eingabe angezeigt. Und das beschleunigt natürlich das Programmieren von Dockerfiles.

Drucken Sie sich dieses Cheatsheet aus und hängen Sie es an einer gut sichtbaren Stelle auf. So haben Sie unsere Sicherheitstipps stets vor Augen, wenn Sie mit Docker-Images zu tun haben.

Wie macht man Container-Images widerstandsfähiger?

Mit Lintern wie hadolint oder dockle gewährleisten Sie die Sicherheit Ihrer Dockerfile-Konfiguration. Außerdem sollten Sie Ihre Container-Images scannen, um Schwachstellen zu erkennen, die die Sicherheit der Produktionscontainer beeinträchtigen könnten. Empfehlenswert sind in diesem Zusammenhang unsere 10 Sicherheitstipps für Docker-Images.

Birgt die Nutzung von Docker Sicherheitsrisiken in sich?

Docker ist ein beliebtes und verbreitetes Verfahren der Software-Virtualisierung. Selbstverständlich erfordert auch Docker, dass bestimmte Sicherheitstipps befolgt werden. Denn nur so lassen sich Schwachstellen in Basis-Images und Datenschutzrisiken durch falsch konfigurierte Docker-Container vermeiden.

Wie schützt man Docker-Container?

Befolgen Sie die Docker-Sicherheitstipps, um nur Basis-Images mit geringen oder keinen Schwachstellen zu verwenden, die richtigen Sicherheitseinstellungen vorzunehmen und die verwendeten Container zu überwachen, um Diskrepanzen zwischen Entwicklung und Produktion zu verhindern. Außerdem sollten Sie darauf achten, bei der Container-Orchestrierung die Best Practices zu Infrastructure-as-Code (IaC) zu befolgen.

Hier noch einmal die wichtigsten Sicherheitstipps für gute Docker-Images für Node.js und Java-Anwendungen:

1. Sind Sie in der Java-Entwicklung tätig? Dann empfehlen wir Ihnen diese weiterführenden Materialien: Docker für Java-Entwickler: 5 Tipps für mehr Sicherheit

2. 10 Best Practices zur Erstellung von Java-Containern mit Docker - Eine umfassendes Cheatsheet zur Erstellung leistungsfähiger Container für Java-Anwendungen.

3. 10 Best Practices zur Containerisierung von Node.js-Anwendungen mit Docker - In dieser Schritt-für-Schritt-Anleitung wird erklärt, wie man leistungsfähige und sichere Basis-Images für Node.js-Anwendungen erstellt.