PHP8.4-Dockercontainer mit Vulnerablities

[p-bieling]

Hallo zusammen,

ich habe bisher mit Docker noch nicht viel gemacht und will mich da jetzt stärker einarbeiten. Mein Umgebung ist Windows 11 mit Docker Desktop.
Ich habe mal dieses Beisiel ausprobiert, was auch funktioniert. Statt PHP8.2 habe ich dann 8.4 verwendet.
https://medium.com/@mikez_dg/how-to-...3-9b0e24476ec6

Bei der Prüfung des Images php:8.4-apache mit dem Tool in Docker Desktop finde ich aber 76 "Vulnerabilities" darunter 3 mit Stufe "high" in

debian/libxml2 2.9.14+dfsg-1.3~deb12u1 .
Nun zu meiner Frage: Wie geht ihr mit solchen Meldungen um? Sollte man das lieber runterwerfen, oder ist das zumindest auf lokaler Ebene noch zu tolerieren?

Jetzt noch die andere Frage, die sich aus der Unsicherheit ergibt: Wie würde eure

Bauanleitung für eine LAMP- Umgebung in Docker aussehen?

Viele Grüße

Peter

[reddighamburg]

Das ist eine übliche Situation mit den vulnerabilities, da die "offiziellen" images ja manchmal nicht soooooo häufig aktualisiert werden.

Typische Sicherheitsupdates in den Paketen des Betriebssystems kannst du aber easy selbst aktualisieren, sofern es für ein direkt installiertes System welche gibt.

Mit einem eigenen Dockerfile, dass das "offizielle" image alse basis verwendet, sind das nur wenige Zeilen, wie z.b.

FROM php:8.4-apache

RUN set -xe && \
apt update && \
apt upgrade -y
​​​​

Das ganze baust du dann mithilfe von docker build
zu deinem eigenen image mit einem eigenen Namen

Die docker community bezeichnet dieses Vorgehen allerdings als Anti-Pattern und geht davon aus, dass die Base Images schon regelmäßig aktualisiert werden (was aber nicht immer der Realität entspricht).

Bevor du also sowas machst, solltest du nachsehen, ob es nicht ggf. schon eine neuere Version des offiziellen Image gibt.

Die trägt üblicherweise dasselbe Tag und ist nicht auf den ersten Blick als neuere Version zu erkennen.

Wenn es für die enthaltene Distro noch gar keine neuen Pakete gibt, dann geht's nicht so einfach. Jedoch ist der Container dann auch nicht unsicherer, als eine Box, die das ohne Docker ausführt.

Sowas wie einen "typischen" LAMP Stack mit docker gibt es imho nicht (bzw. wenn, dann nur für DEV Umgebung). Stattdessen sollte immer auf das tatsächlich im Einzelfall benötigte Minimum reduziert werden (z.B. was Extensions etc. angeht)

Docker bietet dir hier auch verschiedene Möglichkeiten, zwischen dev und prod zu unterscheiden.

[p-bieling]

Danke für die schnelle Antwort. Schön, dass Du in dem Thema drin bist. Ich habe mich schon durch viele Spezifikationen gearbeitet, zuletzt. für das E-Rezept. Da schrecken mich die 40% RTFM nicht. Besser ist es natürlich, wenn jemand einem die richtigen Stellen zeigt, die man lesen muss, um das Problem zu lösen. Ich melde mich nächste Woche mal bei Dir.

[Greyo]

Danke für die schnelle Antwort. Schön, dass Du in dem Thema drin bist. Ich habe mich schon durch viele Spezifikationen gearbeitet, zuletzt. für das E-Rezept. Da schrecken mich die 40% RTFM nicht. Besser ist es natürlich, wenn jemand einem die richtigen Stellen zeigt, die man lesen muss, um das Problem zu lösen. Ich melde mich nächste Woche mal bei Dir.

Welche Stelle in der Spezifikation zum E-Rezept hat dir bisher am meisten Kopfzerbrechen bereitet?

[p-bieling]

Welche Stelle in der Spezifikation zum E-Rezept hat dir bisher am meisten Kopfzerbrechen bereitet?

Sorry, das ist ein Missverständnis. Beim E-Rezept ist es die schiere Menge an Spezifikationen, die die Sache schwierig macht. Dazu kommt, dass alles auf FHIR-Profilen aufbaut. Wer damit fertig wird, wird auch mit Docker fertig.

Zum E-Rezept ein Artikel von mir:
https://www.media-palette.de/blog/e-...so_kompliziert

Möchtest Du über das E-Rezept diskutieren oder mir dabei helfen, oder wie kann ich Deine Frage verstehen?