Oficjalne obrazy PHP Docker: tagi, digesty i przebudowa

Krótko: Oficjalny obraz PHP na Docker Hub istnieje w wielu tagach, które łączą wersję, wariant (na przykład cli, fpm, apache) i system bazowy. Tag jest wskaźnikiem, który po przebudowach przesuwa się na nowe stany; tylko digest oznacza dokładnie jeden stan. Przeciw PHP2Shell potrzebują Państwo obrazu z PHP 8.5.12, 8.4.27, 8.3.36 lub 8.2.35, sprawdzonego poleceniem php -v, oraz przebudowy własnych obrazów na jego bazie.

Dlaczego sam tag mówi niewiele

Wiele zespołów wpisuje do swojego Dockerfile wiersz w rodzaju FROM php:8.3-fpm i o nim zapomina. Działa to tak długo, jak długo nikt nie pyta, jaka wersja PHP właściwie działa. Od PHP2Shell pyta każdy.

Odpowiedzi nie ma w Dockerfile. Tag taki jak 8.3-fpm wskazuje w chwili pobrania na najnowszy stan tej gałęzi. Jeśli obraz pobrano przed 21 października i od tamtej pory nie odnowiono, zawiera podatną wersję, choć tag dziś wskazuje na poprawiony stan. Według wytycznych Docker Official Images obrazy są aktywnie przebudowywane, także przy poprawkach bezpieczeństwa. Państwa lokalnego stanu to jednak nie dotyka.

Pełny przebieg od przebudowy do nowo utworzonego kontenera opisuje Łatanie PHP w kontenerach Docker. Tu chodzi o pytanie wstępne: który obraz jest właściwy i jak udokumentować jego stan?

Tagi obrazów PHP Docker: jak są zbudowane

Tagi składają się z maksymalnie trzech części. Docker Hub pokazuje przykłady takie jak php:8.2-cli, php:8.2-fpm-alpine czy php:8.4.27-zts-alpine3.24.

Warianty nie są dla PHP2Shell równoważne. fpm uruchamia PHP-FPM, apache uruchamia PHP jako moduł Apache, czyli mod_php. Ten tryb pracy zespół PHP ocenia najwyżej, ponieważ pokazano tam exploit, zanim w ogóle zacznie działać kod aplikacji. Więcej pod adresem Dlaczego mod_php jest szczególnie zagrożony. Wariant cli przeznaczony jest do zadań w wierszu poleceń.

System bazowy też ma konsekwencje. Obrazy Alpine są małe, ale używają innej biblioteki C niż obrazy Debiana; niektóre rozszerzenia lub prekompilowane biblioteki zachowują się tam inaczej. Systemu bazowego nie należy więc zmieniać przy okazji aktualizacji bezpieczeństwa, lecz najpierw pozostać przy tym, co zna Państwa aplikacja.

Ważne dla zrozumienia: w oficjalnym obrazie PHP nie pochodzi z pakietów dystrybucji bazowej. Docker Hub opisuje, że źródła PHP leżą w obrazie, a rozszerzenia wbudowuje się skryptami pomocniczymi takimi jak docker-php-ext-install. Aktualizacja pakietów systemu bazowego we własnym Dockerfile nie zmienia więc wersji PHP. Rozstrzygające jest wyłącznie to, na jakim stanie oficjalnego obrazu Państwo budują.

Tag czy digest: co zmienia się kiedy

Digest to suma kontrolna zawartości obrazu, zapisywana jako sha256: z długim ciągiem znaków. Zmienia się przy każdej przebudowie. Dzięki temu nadaje się jako dowód: kto zna digest, wie dokładnie, jaki stan działa.

W praktyce sprawdza się podział ról:

• W Dockerfile używać tagu gałęzi, na przykład php:8.4-fpm, aby przebudowa automatycznie otrzymywała najnowszą poprawkę tej gałęzi.
• We wdrożeniu używać digestu gotowego, zbudowanego własnego obrazu, aby było jednoznaczne, co jest dostarczane.
• W dokumentacji zapisać oba: tag, digest i wersję sprawdzoną poleceniem php -v.

Kto zamiast tego na stałe wpisze pełny tag wersji, taki jak 8.3.35-fpm, nigdy nie otrzyma poprawki automatycznie. Może to być zamierzone, ale wymaga procesu podnoszącego tag przy każdym komunikacie bezpieczeństwa.

PHP2Shell: sprawdzenie obrazu przed użyciem

Poniższe polecenia pobierają obraz i odczytują informacje. Nie zmieniają działających kontenerów.

# Pobrać aktualny stan tagu gałęzi
docker pull php:8.4-fpm

# Jaka wersja PHP jest w obrazie?
docker run --rm php:8.4-fpm php -v

# Wyświetlić digest pobranego obrazu
docker image inspect php:8.4-fpm --format '{{index .RepoDigests 0}}'

# Zapytać o digest i platformy bezpośrednio w rejestrze
docker buildx imagetools inspect php:8.4-fpm

Zapytanie przez imagetools pokazuje w obrazach wieloplatformowych nadrzędny digest, a pod nim własny dla każdej platformy, na przykład linux/amd64 lub linux/arm64. Proszę udokumentować digest, który faktycznie pobierają Państwa serwery, i pamiętać, że komputery programistów z inną architekturą otrzymają inny digest platformy.

Jeśli php -v nie pokazuje co najmniej poprawionej wersji gałęzi, obraz jest przestarzały lub pochodzi z pamięci pośredniej. Proszę wtedy sprawdzić, czy środowisko używa lustra rejestru, które dostarcza stare stany.

Dla PHP 8.1 i starszych projekt PHP nie wydaje już oficjalnych wydań. Oficjalny obraz tych gałęzi nie może więc zawierać regularnej poprawionej wersji. Tagi, które nie są już utrzymywane, pozostają według wytycznych Docker dostępne, ale nie są już aktualizowane.

Typowe błędy przy wyborze obrazu

• Wariant z przyzwyczajenia: Wariant apache jest wybierany, bo łatwo się uruchamia, choć możliwy byłby fpm z osobnym serwerem WWW.
• Brak przebudowy własnych obrazów: Obraz bazowy jest aktualny, zbudowany z niego obraz aplikacji nie.
• Pominięte buildy wieloetapowe: W Dockerfile z kilkoma wierszami FROM dostosowywany jest tylko jeden.
• Zapomniane obrazy poboczne: Workery, kontenery cron i narzędzia administracyjne używają własnych tagów.
• Poleganie wyłącznie na latest: Tag nic nie mówi o gałęzi i wariancie i przy nowej gałęzi głównej może nieoczekiwanie skoczyć.

Jak zautomatyzować przebudowy, aby przestarzały obraz nie działał długo, opisuje CI/CD: automatyczna przebudowa obrazów PHP. Podstawy PHP w kontenerach wyjaśnia PHP w kontenerach.

Jak konkretnie pomaga PHP SOS?

• Sprawdzić zasoby: Odczytujemy, jakie tagi, digesty i wersje PHP tkwią w Państwa obrazach i działających kontenerach.
• Ocenić wariant: Sprawdzamy, czy mod_php jest potrzebny, czy fpm z osobnym serwerem WWW obniży ryzyko.
• Zbudować od nowa i udokumentować: W ramach usługi PHP-Patch-Service budujemy obrazy od nowa na poprawionej bazie i dokumentujemy tag, digest i wersję.
• Utrwalić proces: Ustawiamy Dockerfile i wdrożenia tak, aby następna poprawka docierała w sposób planowalny.

Częste pytania

Źródła

• Docker Hub: oficjalny obraz PHP
• Dokumentacja Docker: docker buildx imagetools inspect
• Docker Official Images: wytyczne i utrzymanie
• php.net: komunikaty bezpieczeństwa