Security-Updates in Docker Container

[sorcim]

Hallo zusammen,

ich versuche gerade, mich etwas in Docker einzuarbeiten und zu verstehen, wie man einzelne Services als Docker Container betreibt.

Ich habe allerdings ein kleines Verständnisproblem. Meinem Verständnis nach beginnt man damit, sich ein geeignetes Basis-Image zu suuchen und dann in dem Dockerfile die entsprechenden Befehle zu implementieren, die notwendig sind, um den Service zu installieren. Durch den Build wird dann das aktuelle Basis-Image (z.B. Debian) gedownloadet und die Befehle in dem Dockerfile ausgeführt, sodass man dann ein Image erhält, das zum Zeitpunkt des Build auf dem aktuellen Stand (bzgl Sicherheitsupdates) sein sollte.

Ich frage mich jedoch, wie sichergestellt ist, dass das Image (bzw ein Container, der von dem Image abgeleitet wurde) mit Sicherheitsupdates versorgt wird. Ich sehe zwei Alternativen:
1. Das Image und alle davon abgeleiteten Container werden regelmäßig neu erstellt. Das halte ich für nicht praktikabel, oder täusche ich mich da?
2. Man sorgt selbst dafür, dass die Pakete im Container mit Sicherheitsupdates versorgt werden, z.B. durch unattended-upgrades, die im Image eingerichtet werden.

Sind dies die zwei möglichen Alternativen oder übersehe ich eine andere Möglichkeit? Wenn ich mir z.B. das Dockerfile von kanboard ansehe [1], dann erkenne ich nicht, dass die zweite Alternative umgesetzt ist. Wie hat der Autor das Problem der regelmäßigen Sicherheitsupdates gelöst, bzw hat er dieses Problem an den Nutzer delegiert?

Es wäre nett, wenn mir jemand hier einen Hinweis gibt, wie man in einem Docker-Container üblicherweise sicherstellt, dass der Service weiterhin mit allen Sicherheits-Patches versorgt wird.

Vielen Dank!

[1] https://github.com/kanboard/kanboard/bl ... Dockerfile

[hikaru]

Ich frage mich jedoch, wie sichergestellt ist, dass das Image (bzw ein Container, der von dem Image abgeleitet wurde) mit Sicherheitsupdates versorgt wird. Ich sehe zwei Alternativen:
1. Das Image und alle davon abgeleiteten Container werden regelmäßig neu erstellt. Das halte ich für nicht praktikabel, oder täusche ich mich da?
2. Man sorgt selbst dafür, dass die Pakete im Container mit Sicherheitsupdates versorgt werden, z.B. durch unattended-upgrades, die im Image eingerichtet werden.

Sind dies die zwei möglichen Alternativen oder übersehe ich eine andere Möglichkeit?

Nein, du übersiehst hier nichts (oder ich tue es ebenfalls). Du hast diese zwei Möglichkeiten, einen Container zu aktualisieren.

Wenn ich mir z.B. das Dockerfile von kanboard ansehe [1], dann erkenne ich nicht, dass die zweite Alternative umgesetzt ist. Wie hat der Autor das Problem der regelmäßigen Sicherheitsupdates gelöst, bzw hat er dieses Problem an den Nutzer delegiert?

Ohne mir diesen speziellen Container angesehen zu haben, gehe ich davon aus, dass die Lösung des von dir erkannten Problems dem Nutzer überlassen wird, denn es ist die (für den Entwickler) einfachste Lösung.

Ich habe hier einen Kollegen (guter Programmierer, schlechter Systemadministrator) der auch ganz großer Docker-Fan ist, denn Speicher kostet ja heute nichts mehr und mit Docker fallen schließlich die lästigen Abhängigkeiten weg, deren Aktualisierungen oft dazu führen, dass man an den eigenen Code ran muss. Sein Host-System aktualisiert er regelmäßig (bzw. macht die IT-Abteilung und er lässt es zu: soll ja sicher sein; und ist außerdem Policy des AG), aber seine Docker-Container lässt er vergammeln um den Wartungsaufwand für seinen Code kleinzuhalten.
Spricht man ihn darauf an, dass sein Verhalten suboptmal ist, dann steckt er sich die Finger in die Ohren und ruft laut "Lalalala!"
Ich freue mich schon auf den Zeitpunkt, an dem ihm seine Container um die Ohren fliegen, weil sie nicht mehr zum Host-System kompatibel sind.

[heisenberg]

Das Image und alle davon abgeleiteten Container werden regelmäßig neu erstellt. Das halte ich für nicht praktikabel, oder täusche ich mich da?

Das ist die übliche Methode. Daten werden dabei - idealerweise - außerhalb des Containers gehalten, d. h. entweder über das Hostsystem(Volumes) oder über das Netzwerk(z. B. NFS) eingebunden werden.

Wichtig ist dabei auch noch, dass bei Containern, die nicht stateless sind, also solche, die Konfigurations- oder Nutzdaten verwenden, diese die Daten auch immer auf die aktuelle Version konvertieren.

Beim nextcloud-docker-container gibt es bei jeder Version z. B. Datenbankänderungen, die eingepflegt werden müssen. Die von Nextcloud herausgegebenen Docker-Images unterstützen dies dadurch, dass eine Docker-Programm(=Image)-Version eine Konvertierung der letzten Docker-Daten-Version konvertieren kann. D. h. wenn man regelmässig Updates durchführt, dann können die Daten immer schön mitkonvertiert werden. Wenn man das zu lange nicht tut, hat man da einiges an manueller Arbeit.

Viele große Projekte bringen in Ihren Containern diese Datenkonvertierungsfähigkeit mit. Bei kleineren Sachen muss man das selbst tun.

Es gibt im ServerSupportForum einige Diskussionen zu Docker und Container, in denen viel Wissenswertes dazu steht. Ebenso gibt es dort einige wenige Profis, die das auch tatsächlich in großem Maßstab einsetzen.

[sorcim]

Vielen Dank für die Antworten!

Daraus schließe ich: Immer schön darauf achten, dass die Docker-Container stateless sind und alle Daten/Konfigurationsdateien extern einbinden. Beim Erstellen neuer Images dann hoffen, dass sich an den Daten/Konfigurationsdateien möglichst wenig geändert hat, damit kein manueller Aufwand anfällt.

Klingt erstmal trotzdem noch nach viel Arbeit, da ja Sicherheitsupdates theoretisch täglich erscheinen können (wir haben ja nicht wie bei Windows einen monatlichen Patch-Day), also müsste man theoretisch die Container täglich neu erstellen und neu starten. Außerdem - da ja ein Container nur eine spezifische Aufgabe erfüllen soll (Micro Service), gehe ich davon aus, dass man mehrere Container hat, die man ständig neu erstellen muss. Irgendwie hätte ich gedacht, diese Docker-Architektur erleichtert einem Sysadmin - nach der Initialkonfiguration - das Leben eher anstatt es zu verkomplizieren.

Werden denn die offiziellen Images von z.B. Nextcloud oder PostgreSQL täglich (oder zumindest regelmäßig) neu erstellt? Insbesondere auch die alten Tags/Releases eines Services? In der Regel möchte man ja nicht unbedingt immer sofort auf die neueste Version upgraden, sondern lieber bei der eigenen produktiv eingesetzten Version bleiben und nur Sicherheitsupdates einspielen, um z.B. sicherzustellen, dass die von einem Service abhängigen anderen Services weiterhin funktionieren. (Ein Versionsupgrade könnte ja z.B. eine bestehende Schnittstelle entfernen oder ändern, sodass andere Services auf diese Schnittstelle dann nicht mehr zugreifen können).

EDIT: OK, zumindest bei PostgreSQL habe ich gerade gesehen, dass auch alte Programmversionen vor kurzem neu gepublished wurden. Ich gehe davon aus, dass es sich dabei um Sicherheitsupdates handelt.

[heisenberg]

Daraus schließe ich: Immer schön darauf achten, dass die Docker-Container stateless sind und alle Daten/Konfigurationsdateien extern einbinden.

Container die Nutzdaten haben, sind per Definition nicht stateless. Daten würde ich grundsätzlich extern einbinden. Ein Stateless-Container ist z. B. ein Resolver, der nur ein paar Konfigurationsvariablen über die Container-Definition bekommt(docker-compose.yml, .env).

Klingt erstmal trotzdem noch nach viel Arbeit, da ja Sicherheitsupdates theoretisch täglich erscheinen können (wir haben ja nicht wie bei Windows einen monatlichen Patch-Day).

Ja ist es. Aber wie geschrieben, bei den großen Projekten werden diese Routinen mitgeliefert und es beschränkt sich auf ein paar Befehle (hier mit docker-compose. Plain docker geht natürlich genauso.):

Code: Alles auswählen

docker-compose pull
docker-compose build
docker-compose down
docker-compose up -d

Es gibt da eine Software, die auf neue Containerversionen prüft und diese dann automatisch neu baut. Das setze ich nicht ein. Wie bereits geschrieben: Schau mal im SSF. Dort steht das irgendwo.

Werden denn die offiziellen Images von z.B. Nextcloud oder PostgreSQL täglich (oder zumindest regelmäßig) neu erstellt?

Täglich wahrscheinlich nicht unbedingt; regelmässig aber schon. Wenn ich mir auf dem Docker-Hub ein paar grosse Projekte anschaue, dann sind die letzten Uploads zwischen <1 Tag und 1 Monat.

Insbesondere auch die alten Tags/Releases eines Services? In der Regel möchte man ja nicht unbedingt immer sofort auf die neueste Version upgraden, sondern lieber bei der eigenen produktiv eingesetzten Version bleiben und nur Sicherheitsupdates einspielen, um z.B. sicherzustellen, dass die von einem Service abhängigen anderen Services weiterhin funktionieren. (Ein Versionsupgrade könnte ja z.B. eine bestehende Schnittstelle entfernen oder ändern, sodass andere Services auf diese Schnittstelle dann nicht mehr zugreifen können).

Wenn die Docker-Unterstützung durch das Projekt sehr gut ist gibt es für jede Versions-Linie ein "Tag". Z. B. für mariadb:

• mariadb:10.8
• mariadb:10.9
• mariadb:latest

Mit "latest" bekommst Du immer die neueste Version. Mit "10.9" bekommst Du die neueste 10.9.x Version. "10.8" analog. Für einen Produktivserver würde man sich dann auf eine gewünschtes Version festlegen, z. B. "10.5". Welche Tags es gibt, sieht man auf dem Docker-Hub: https://hub.docker.com/_/mariadb

Ansonsten ist das mit den Docker-Containern und dem Thema Sicherheit so eine Vertrauenssache: Installiere die Container-Images von den Anbietern, die für Dich vertrauenswürdig erscheinen. Als gute Faustregel wende ich da für mich an: Ich nehme nur Container von den Projekten selbst und nicht von Drittanbietern.

[sorcim]

Nochmals vielen Dank für die Antwort. Ich habe in der Zwischenzeit in dem verlinkten Forum etwas gestöbert und bin auf diesen für mich sehr hilfreichen Thread gestoßen:
https://serversupportforum.de/threads/c ... tes.60448/

Von hier aus versuche ich mich erstmal selbstständig weiter einzuarbeiten.

[TRex]

Was du darüber hinaus tun kannst: nimm ne beliebige Software zum Überwachen der Pakete auf Sicherheitslücken/Updates und lass sie regelmäßig mit der Version des Image laufen, das bei dir im Produktivbetrieb im Einsatz ist. So machst du dich nicht abhängig von Upstream, was die Verantwortung angeht und bist auch nicht auf "pauschal täglich neu bauen" angewiesen, ohne zu wissen, ob das was ändert (und wenn du nicht von scratch baust, können ja trotzdem alte Pakete im Basis-Image vorhanden sein).