Uradne slike PHP Docker: oznake, digesti in ponovna gradnja

Na kratko: Uradna slika PHP na Docker Hubu obstaja v mnogih oznakah, ki združujejo različico, varianto (na primer cli, fpm, apache) in osnovni sistem. Oznaka je kazalec, ki se po novih gradnjah premakne na nova stanja; samo digest označuje natanko eno stanje. Proti PHP2Shell potrebujete sliko s PHP 8.5.12, 8.4.27, 8.3.36 ali 8.2.35, preverjeno s php -v, in ponovno gradnjo svojih slik na tej podlagi.

Zakaj oznaka sama malo pove

Mnoge ekipe v svoj Dockerfile zapišejo vrstico, kot je FROM php:8.3-fpm, in jo nato pozabijo. To deluje, dokler nihče ne vpraša, katera različica PHP dejansko teče. Od PHP2Shell sprašuje vsak.

Odgovora ni v Dockerfileu. Oznaka, kot je 8.3-fpm, ob prenosu kaže na najnovejše stanje te veje. Če je bila slika prenesena pred 21. oktobrom in od takrat ni bila obnovljena, vsebuje ranljivo različico, čeprav oznaka danes kaže na odpravljeno stanje. Po smernicah Docker Official Images se slike dejavno gradijo znova, tudi ob varnostnih popravkih. Vašega lokalnega stanja to ne zadene.

Celoten potek od ponovne gradnje do na novo ustvarjenega vsebnika opisuje Popravljanje PHP v vsebnikih Docker. Tukaj gre za predhodno vprašanje: katera slika je prava in kako dokažete njeno stanje?

Oznake slik PHP Docker: kako so sestavljene

Oznake so sestavljene iz do treh delov. Docker Hub prikazuje primere, kot so php:8.2-cli, php:8.2-fpm-alpine ali php:8.4.27-zts-alpine3.24.

Variante za PHP2Shell niso enakovredne. fpm upravlja PHP-FPM, apache upravlja PHP kot modul Apache, torej mod_php. Ta način delovanja ekipa PHP uvršča najvišje, ker je bil tam prikazan exploit, še preden se sploh izvede koda aplikacije. Več na strani Zakaj je mod_php posebej ogrožen. Varianta cli je namenjena nalogam v ukazni vrstici.

Tudi osnovni sistem ima posledice. Slike Alpine so majhne, a uporabljajo drugo knjižnico C kot slike Debian; nekatere razširitve ali vnaprej prevedene knjižnice se tam obnašajo drugače. Osnovnega sistema zato ne menjajte mimogrede z varnostno posodobitvijo, ampak najprej ostanite pri tem, kar vaša aplikacija pozna.

Pomembno za razumevanje: v uradni sliki PHP ne izvira iz paketov osnovne distribucije. Docker Hub opisuje, da izvorna koda PHP leži v sliki in da se razširitve vgradijo prek pomožnih skriptov, kot je docker-php-ext-install. Posodobitev paketov osnovnega sistema v lastnem Dockerfileu zato na različici PHP ne spremeni ničesar. Merodajno je samo, na kateri izdaji uradne slike gradite.

Oznaka ali digest: kaj se kdaj spremeni

Digest je kontrolna vsota vsebine slike, zapisana kot sha256: z dolgim nizom znakov. Spremeni se z vsako novo gradnjo. Zato je primeren kot dokaz: kdor pozna digest, natanko ve, katero stanje teče.

V praksi se obnese delitev nalog:

• V Dockerfileu uporabite oznako veje, na primer php:8.4-fpm, da nova gradnja samodejno dobi najnovejši popravek te veje.
• Pri uvajanju uporabite digest končno zgrajene lastne slike, da je jasno, kaj se dostavlja.
• V dokumentaciji zabeležite oboje: oznako, digest in različico, preverjeno s php -v.

Kdor namesto tega trdno zapiše polno oznako različice, kot je 8.3.35-fpm, popravka nikoli ne dobi samodejno. To je lahko želeno, a zahteva postopek, ki oznako dvigne ob vsakem varnostnem obvestilu.

PHP2Shell: preverite sliko pred uporabo

Naslednji ukazi prenesejo sliko in preberejo podatke. Tekočih vsebnikov ne spreminjajo.

# Prenesite trenutno stanje oznake veje
docker pull php:8.4-fpm

# Katera različica PHP je v sliki?
docker run --rm php:8.4-fpm php -v

# Prikaz digesta prenesene slike
docker image inspect php:8.4-fpm --format '{{index .RepoDigests 0}}'

# Digest in platforme neposredno iz registra
docker buildx imagetools inspect php:8.4-fpm

Poizvedba z imagetools pri slikah za več platform prikaže nadrejeni digest in pod njim za vsako platformo, na primer linux/amd64 ali linux/arm64, svojega. Dokumentirajte digest, ki ga vaši strežniki dejansko prenesejo, in upoštevajte, da razvijalski računalniki z drugo arhitekturo dobijo drug digest platforme.

Če php -v ne pokaže vsaj odpravljene različice veje, je slika zastarela ali prihaja iz vmesnega pomnilnika. Tedaj preverite, ali vaše okolje uporablja zrcalo registra, ki dostavlja stara stanja.

Za PHP 8.1 in starejše projekt PHP ne izdaja več uradnih izdaj. Uradna slika teh vej zato ne more vsebovati redne odpravljene različice. Oznake, ki se ne vzdržujejo več, po smernicah Docker ostanejo dosegljive, a se ne posodabljajo več.

Tipične napake pri izbiri slike

• Varianta iz navade: Izbrana je varianta apache, ker se enostavno zažene, čeprav bi bil mogoč fpm z ločenim spletnim strežnikom.
• Brez ponovne gradnje lastnih slik: Osnovna slika je aktualna, iz nje zgrajena slika aplikacije ne.
• Spregledane večstopenjske gradnje: V Dockerfileu z več vrsticami FROM je prilagojena samo ena.
• Pozabljene stranske slike: Delavci, vsebniki cron in skrbniška orodja uporabljajo lastne oznake.
• Zanašanje samo na latest: Oznaka ne pove ničesar o veji in varianti ter lahko ob novi glavni veji nepričakovano skoči.

Kako avtomatizirate ponovne gradnje, da zastarela slika sploh ne teče dolgo, opisuje CI/CD: samodejna ponovna gradnja slik PHP. Osnove o PHP v vsebnikih pojasnjuje PHP v vsebnikih.

Kako PHP SOS pomaga konkretno?

• Preverjanje stanja: Preberemo, katere oznake, digesti in različice PHP so v vaših slikah in tekočih vsebnikih.
• Ocena variante: Preverimo, ali je mod_php potreben ali pa fpm z ločenim spletnim strežnikom zmanjša tveganje.
• Ponovna gradnja in dokaz: S storitvijo popravljanja PHP slike znova zgradimo na odpravljeni podlagi in dokumentiramo oznako, digest in različico.
• Utrditev postopka: Dockerfile in uvajanja uredimo tako, da naslednji popravek prispe načrtovano.

Pogosta vprašanja

Viri

• Docker Hub: uradna slika PHP
• Dokumentacija Docker: docker buildx imagetools inspect
• Docker Official Images: smernice in vzdrževanje
• php.net: varnostna obvestila