Es ist sehr wahrscheinlich im Alltag mit containerisierten Anwendungen in Ber\u00fchrung zu kommen, ohne sich dessen bewusst zu sein. In einer Zeit, in der sich der Trend der Unternehmen weiterhin stark in Richtung Cloud bewegt, gewinnen Container immer mehr an Bedeutung. Es ist von hoher Relevanz, diese meist containerisierten Anwendungen mit Best Practices abzusichern, um ein gewisses Ma\u00df an Grundsicherheit zu erreichen. Container bieten einen gro\u00dfen Mehrwert, vor allem in Bezug auf Isolation, Skalierung, Kontrolle und Nutzung der Ressourcen.<\/p>\n\n\n\n
Viele Anwendungen bieten entweder selbst oder durch von der Community entwickelte Container-L\u00f6sungen an, die einfach einzurichten sind und minimale Anstrengungen f\u00fcr die Installation erfordern. Dies ist jedoch nicht immer der Fall oder durch die Individualisierung einer Applikation, muss diese selbst in einem Container verpackt werden.<\/p>\n\n\n\n
Um Fl\u00fcchtigkeitsfehler bei der Entwicklung zu vermeiden, ist es wichtig, alle Dateien, die im Container verwendet werden sollen, in einem separaten Verzeichnis zu speichern. Dadurch wird sichergestellt, dass bei der Arbeit mit relativen Pfaden die ben\u00f6tigten Dateien verf\u00fcgbar sind und versehentliche Fehler vermieden werden.<\/p>\n\n\n\n
FROM<\/code> Befehl in einer Dockerfile beschreibt, welches Image f\u00fcr den Docker Container verwendet werden soll. Es gibt keine Garantie daf\u00fcr, dass diese Images weiterhin maintained und zu 100\u00a0% frei von Sicherheitsl\u00fccken sind. Es ist ebenfalls wichtig, signierte Images durch den Docker Content Trust zu verwenden, da so garantiert wird, dass diese nicht durch Dritte ver\u00e4ndert wurden. Empfehlenswert ist auch, die Images zuvor auf Docker Hub zu pr\u00fcfen, da dort aktuelle Sicherheitsl\u00fccken aufgelistet werden. Als Beispiel hier die Analyse des GCC Containers auf Docker Hub<\/a>.<\/li>\n<\/ul>\n\n\n\nFROM alpine:3.19<\/code><\/pre>\n\n\n\n\n- Image Version festsetzten
Docker Tags sind ver\u00e4nderbar, was nicht garantiert, dass der Tag IMAGE:1.0<\/code> immer 1.0<\/code> ist. Die Version 1.0<\/code> k\u00f6nnte zum Beispiel ein Alias f\u00fcr die Patch-Version 1.1<\/code> sein. Dies ist ein valider Ansatz, da er es erm\u00f6glicht, Sicherheits-Patches auf ein Image anzuwenden, ohne dass der IT-Administrator die Imageversion f\u00fcr jeden Container \u00e4ndern muss. Dennoch zeigt sich hier das Problem, dass wenn man eine bestimmte Version eines Images verwenden m\u00f6chte, noch weitere Ma\u00dfnahmen ergreifen muss. F\u00fcr jeden Release eines Images wird ein entsprechender Hash generiert, mit dem ein Container eindeutig identifiziert werden kann. Die Verwendung des Hashes im Dockerfile kann dem FROM<\/code> Befehl hinzugef\u00fcgt werden. Diese Hash kann direkt \u00fcber die Docker Hub<\/a> eingesehen werden.<\/li>\n<\/ul>\n\n\n\nFROM alpine:3.19@sha256:6457d53fb065d6f250e1504b9bc42d5b6c65941d57532c072d929dd0628977d0<\/code><\/pre>\n\n\n\n\n- Minimal Images
Das Grundprinzip der Containerisierung besteht darin, nur das in den Container aufzunehmen, was die Anwendung ben\u00f6tigt. Dies bezieht sich nicht nur auf Binaries, sondern auch auf Bibliotheken. Lightweight Linux Distributionen wie Alpine<\/code> sollten hier das Minimum sein. Images k\u00f6nnen auch durch die Verwendung von distroless-Images wie gcr.io\/distroless\/base-debian12<\/code> gesichert werden. Diese enthalten nur die Basispakete und nur die Bibliotheken, die zur Ausf\u00fchrung eines Programms ben\u00f6tigt werden, das dynamische Bibliotheken erfordert. Wenn auch diese nicht notwendig sind und die Anwendung statisch gebaut wurde, kann auch das Image gcr.io\/distroless\/static-debian12<\/code> verwendet werden, welches dann auch diese “\u00fcberfl\u00fcssigen” dynamische Bibliotheken entfernt.<\/li>\n\n\n\n- Multistage builds
Im Sinne des minimal Image Ansatzes wird auch empfohlen, mehrstufige Images zu verwenden, wenn eine Kompilierung von Dateien erforderlich ist. Diese sind n\u00fctzlich, da sie es erm\u00f6glichen, den Build Prozess vom ver\u00f6ffentlichten Docker Container zu trennen. So sollten beispielsweise Build Tools wie GCC nicht in den endg\u00fcltigen Container aufgenommen werden.<\/li>\n<\/ul>\n\n\n\n# "builder" stage\nFROM gcc:9.5.0-bullseye@sha256:44a9e26a95ca57839a1ac37106f9d93025d508072aa6ea84fcda696737a80bc1 as builder\nWORKDIR \/my-app\nCOPY app-src .\/host-path\nRUN |BUILD COMMAND|\n\n# Final stage were we copy artifacts from "builder"\nFROM alpine:3.19@sha256:6457d53fb065d6f250e1504b9bc42d5b6c65941d57532c072d929dd0628977d0\nCOPY --from=builder |BUILD PATH| |CONTAINER PATH|\nENTRYPOINT [|CONTAINER PATH|]<\/code><\/pre>\n\n\n\n\n- Rootless containers
Das Ausf\u00fchren der Anwendung unter root ist nur in bestimmten F\u00e4llen notwendig und meistens ein Edge Case. Deshalb sollten im Container unterschiedliche Benutzer, UIDs und GIDs verwendet werden.
Es sollte darauf geachtet werden, dass der Benutzer Zugriff auf die zu auszuf\u00fchrenden Anwendungsdateien hat.<\/li>\n<\/ul>\n\n\n\n# Create user and set owner and permissions\nRUN adduser -D drunner && chown -R drunner |APP CONTAINER PATH|\nUSER drunner<\/code><\/pre>\n\n\n\nOptional kann auch der Root Benutzer deaktiviert werden.
RUN chsh -s \/usr\/sbin\/nologin root<\/code><\/p>\n\n\n\n\n- File read \/ write permissions
Es ist zu beachten, dass nur die Dateien und Pfade Schreibrechte haben sollten, die f\u00fcr die Ausf\u00fchrung der Anwendung notwendig sind. In jedem Fall sollte darauf geachtet werden, dass alle ausf\u00fchrbaren Dateien schreibgesch\u00fctzt sind, um eine gewisse Grundsicherheit im Anwendungsablauf zu schaffen.<\/li>\n\n\n\n - Ports
Damit der Container sicher l\u00e4uft, ist es wichtig, dass nur die Ports ge\u00f6ffnet werden, die f\u00fcr die Nutzung der Anwendung notwendig sind. Bei einer Webanwendung w\u00e4ren dies in diesem Fall 80 (HTTP) und 443 (HTTPS). Idealerweise sollte auch das entsprechende Kommunikationsprotokoll angegeben werden.<\/li>\n<\/ul>\n\n\n\n# Expose ports\nEXPOSE 80\/tcp\nEXPOSE 443\/tcp<\/code><\/pre>\n\n\n\n\n- Linting
Tools wie hadolint<\/a> helfen dabei, einige Best Practices in der Dockerfile zu \u00fcberpr\u00fcfen.<\/li>\n<\/ul>\n\n\n\nEin Beispiel einer Dockerfile, welche diese Best Practices umsetzt, k\u00f6nnte wie folgt aussehen:<\/p>\n\n\n\n
# "builder" stage\nFROM gcc:9.5.0-bullseye@sha256:44a9e26a95ca57839a1ac37106f9d93025d508072aa6ea84fcda696737a80bc1 as builder\nWORKDIR \/my-app\nCOPY app-src .\nRUN |BUILD COMMAND|\n\n# Final stage were we copy artifacts from "builder"\nFROM alpine:3.19@sha256:6457d53fb065d6f250e1504b9bc42d5b6c65941d57532c072d929dd0628977d0\nCOPY --from=builder |BUILD PATH| |APP CONTAINER PATH|\n\n# Create user and set owner and permissions\nRUN adduser -D drunner && chown -R drunner |APP CONTAINER PATH|\nUSER drunner\nENTRYPOINT [|APP CONTAINER PATH|]\n\n# Expose ports\nEXPOSE 80\/tcp\nEXPOSE 443\/tcp<\/code><\/pre>\n\n\n\nNutzung von Docker Compose zum bauen von Images<\/h3>\n\n\n\n
Um sicherzustellen, dass der Build Prozess immer reproduzierbar bleibt, ist es von Vorteil, den Build in der Docker Compose Datei zu sichern. Der gro\u00dfe Mehrwert dabei ist, dass durch die Versionierung nachvollzogen werden kann, welcher Build Prozess zu welcher Version der Container Images passt. Eine vollst\u00e4ndige Liste der Optionen findet sich unter Docker Docs<\/a>.<\/p>\n\n\n\n\nDocker bietet Argument und Environment Variablen zur Verwendung externer Parameter. Es ist zu beachten, dass Argumente nur w\u00e4hrend des Build Prozesses existieren und ab der Laufzeit des Containers nicht mehr verf\u00fcgbar sind.<\/p>\n<\/blockquote>\n\n\n\n
build:\n context: .\n dockerfile: linux-prod.Dockerfile\n platforms:\n - "linux\/amd64"\n privileged: false\n network: none\n args:\n - VAR_XXX=foobar<\/code><\/pre>\n\n\n\nContainer sicher starten<\/h2>\n\n\n\n
An dieser Stelle sei erw\u00e4hnt, dass im Folgenden nur Beispiele mit Docker Compose aufgef\u00fchrt sind. Diese Einstellungen k\u00f6nnen jedoch mit Hilfe der Docker Dokumentation 1 zu 1 in Docker-CLI Kommandos \u00fcbersetzt werden. Der optimale Ansatz, um vergessene Argumente und Fehlverhalten fr\u00fcherer Instanzen zu vermeiden, ist die Verwendung von Docker Compose.<\/p>\n\n\n\n
Anhand des folgenden Beispiels werden nun Best Practices in die Konstruktion von Docker Compose Dateien integriert. In diesem Beispiel wird eine Webanwendung erstellt und ausgef\u00fchrt, die sensible Dokumente generiert, um sie f\u00fcr Benutzer zum Herunterladen bereitzustellen.<\/p>\n\n\n\n
services:\n secure-app:\n build:\n context: .\n dockerfile: app.DockerFile\n ports:\n - 80<\/code><\/pre>\n\n\n\n\n- Temporary mounts
Beim Umgang mit sensiblen Dateien ist es wichtig, dass sie nicht f\u00fcr jedermann zug\u00e4nglich sind und nicht dauerhaft gespeichert werden sollten. Unter Linux ist es m\u00f6glich, tmpfs<\/code> zu verwenden, das daf\u00fcr sorgt, dass Dateien nur im fl\u00fcchtigen Speicher des Hosts gespeichert werden. Nach dem Herunterfahren oder Neustart des Containers werden diese Dateien einfach verworfen.<\/li>\n<\/ul>\n\n\n\ntmpfs:\n - \/app\/sensitiv_data<\/code><\/pre>\n\n\n\n\n- Ports
Die Optionen f\u00fcr die Portfreigabe innerhalb von Docker Compose bieten mehrere M\u00f6glichkeiten. So k\u00f6nnen Ports im Container Netzwerk, Docker Netzwerk oder im Host Netzwerk ge\u00f6ffnet werden. Dies ist jedoch teilweise davon abh\u00e4ngig, welches Netzwerk dem Container zugewiesen wurde und welche Capabilities (Berechtigungen) dem Container zu gewissen sind.<\/li>\n<\/ul>\n\n\n\nports:\n - "127.0.0.1:8080:80"<\/code><\/pre>\n\n\n\nAnwendungen, die aus dem Internet erreichbar sind, sollten immer nur \u00fcber eine sichere Verbindung zug\u00e4nglich sein. Um den Verwaltungsaufwand zu reduzieren, empfiehlt sich der Einsatz einer Reverse Proxy, \u00fcber die die entsprechenden Zertifikate zentral ausgestellt werden und bestimmte Regeln bez\u00fcglich der Allow- und Blocklist gepflegt werden. Um Ports nur innerhalb des Docker Netzwerks zu \u00f6ffnen, sollte der keywoard expose verwendet werden. Normalerweise befinden sich die Anwendungen in separaten Containernetzen, was zur Isolation beitr\u00e4gt. Um die Dienste jedoch zug\u00e4nglich zu machen, sollte man darauf achten, wie die Ports ge\u00f6ffnet werden.<\/p>\n\n\n\n