Stručne: Ak chcete prevádzkovať PHP v kontajneroch, zvoľte vhodný variant oficiálneho obrazu (fpm, apache alebo cli), aktivujte produkčný php.ini, nainštalujte len potrebné rozšírenia a nastavte limity pamäte a procesov, ktoré k sebe pasujú. Kontajnery sú nemenné: bezpečnostná aktualizácia PHP, ako pri PHP2Shell, zaberie až vtedy, keď je obraz zostavený znova a každý kontajner reštartovaný. Toto nové zostavenie preto patrí ako pevný proces do každej prevádzky kontajnerov.
Prečo PHP v kontajneroch?
Kontajnery zabalia PHP, rozšírenia a konfiguráciu do obrazu, ktorý beží na každom serveri rovnako. Pre firmy to znamená: menej prekvapení medzi testom a produkciou, rýchlejšie obnovenie a jasné stavy verzií. Pre bezpečnosť to však znamená aj novú povinnosť: v kontajneri nikto automaticky nenasadzuje aktualizácie.
Táto stránka sa venuje prebiehajúcej prevádzke. Ako konkrétne záplatovať existujúce kontajnery proti PHP2Shell, je uvedené v Záplatovanie PHP v kontajneroch Docker.
Voľba správneho variantu obrazu
| Variant | Obsah | Typické použitie |
|---|---|---|
php:<version>-fpm |
PHP-FPM, vyžaduje predradený webový server | produkcia s Nginx, Caddy alebo ingressom |
php:<version>-apache |
Apache s mod_php, štandardne mpm_prefork | jednoduché nasadenia, staršie aplikácie |
php:<version>-cli |
príkazový riadok, ako jediný variant obsahuje aj php-cgi | cronjoby, queue workery, kroky zostavenia |
…-alpine |
na Alpine Linux s musl | malé obrazy, pri niektorých rozšíreniach sú potrebné úpravy |
…-bookworm, …-trixie |
na uvedenej verzii Debianu | pevný základ pre reprodukovateľné zostavenia |
Pre nové projekty sa spravidla odporúča variant fpm so samostatným kontajnerom webového servera. Pri mod_php vidí tím PHP v súvislosti s PHP2Shell najvyššie riziko; kto používa obraz apache, prevádzkuje práve tento spôsob prevádzky.
Zostavenie produkčného obrazu
Štíhly príklad pre aplikáciu s prístupom k MySQL:
FROM php:8.4-fpm-alpine
# Aktivovať produkčnú konfiguráciu (podľa dokumentácie obrazu dôrazne odporúčané)
RUN mv "$PHP_INI_DIR/php.ini-production" "$PHP_INI_DIR/php.ini"
# Iba potrebné rozšírenia
RUN docker-php-ext-install -j"$(nproc)" pdo_mysql
# Vlastné nastavenia
COPY zz-sicherheit.ini "$PHP_INI_DIR/conf.d/"
# Kód patrí používateľovi root; workeri FPM bežia ako www-data a môžu ho iba čítať
COPY . /var/www/html
Pomocné skripty obrazu preberajú zostavovanie rozšírení: docker-php-ext-configure pre voľby, docker-php-ext-install na zostavenie, docker-php-ext-enable na aktiváciu, napríklad po pecl install. Ak sa pomocou docker-php-source rozbalí zdrojový kód, má sa podľa dokumentácie v tej istej vrstve opäť zmazať. Súbor zz-sicherheit.ini by mohol vyzerať takto:
expose_php = Off
display_errors = Off
log_errors = On
session.use_strict_mode = 1
session.cookie_httponly = 1
Dva ďalšie zásady robia obrazy odolnejšími. Po prvé, dodávaný obraz obsahuje iba to, čo sa potrebuje za behu; kompilátory, cache balíkov a testovacie súbory patria do samostatného stupňa zostavenia. Po druhé, používateľ, pod ktorým PHP beží, smie zapisovať iba tam, kde je to nevyhnutné, napríklad do adresárov na nahrávanie alebo cache na pripojených volumes. Mnohé tímy prevádzkujú kontajner navyše so súborovým systémom chráneným proti zápisu. Votknutý súbor PHP má potom výrazne ťažšie zostať natrvalo a každý reštart obnoví čistý stav obrazu. To nenahrádza vyšetrovanie po incidente, ale citeľne zmenšuje plochu útoku.
Procesy, pamäť a logy v kontajneri
Tri nastavovacie skrutky rozhodujú o tom, či PHP kontajner beží stabilne.
- Počet workerov:
pm.max_childrenv poole FPM určuje, koľko požiadaviek sa vybavuje súčasne. Každý worker môže obsadiť ažmemory_limit. - Limit pamäte kontajnera: Obmedzuje všetky procesy dohromady. Ako hrubé pravidlo platí: počet workerov krát pamäť na workera plus rezerva musí vojsť pod limit, inak systém procesy ukončí.
- Logy: Kontajnery zapisujú logy na štandardný výstup. V PHP-FPM presmeruje
catch_workers_output = yesvýstupy workerov do hlavného logu; bez tohto nastavenia skončia podľa príručky v prázdne.
Užitočný je aj request_terminate_timeout, ktorý jednotlivé požiadavky po určitom čase ukončí, ak max_execution_time nezaberie. Ako prevádzkovať kontajnery v klastri, opisuje Záplatovanie PHP v Kubernetes.
Kontajnery a bezpečnosť: čo ukázal PHP2Shell
Pri PHP2Shell zohrávajú kontajnery dvojakú úlohu. Na jednej strane sú pomocou: php.net odporúča ako prechodné opatrenie k CVE-2026-109618 kombinovať memory_limit=-1 s limitom pamäte cez kontajner alebo cgroup, ideálne tak, aby sa ukončil iba dotknutý worker. RLIMIT_AS a RLIMIT_DATA sú na to podľa php.net nevhodné. Toto opatrenie nie je úplnou ochranou a aktualizáciu nenahrádza.
Na druhej strane sú kontajnery pascou, ak sa obrazy nezostavia znova. Obraz s PHP 8.4.26 zostáva zraniteľný, bez ohľadu na to, ako často sa kontajner reštartuje. Až nové zostavenie na 8.4.27 alebo novšie a výmena všetkých bežiacich kontajnerov zraniteľnosť uzavrie. Stav sa dá skontrolovať priamo v bežiacom kontajneri:
docker exec <container> php -v
docker exec <container> php-fpm -v
docker exec <container> php -r 'var_dump(ini_get("memory_hard_limit_percent"));'
Ak posledný príkaz vráti bool(false), PHP nepozná direktívu zavedenú s opravenými verziami; podľa príručky je potom verzia dotknutá. Trvalo pomôže iba automatické nové zostavenie, ako je opísané v CI/CD: automatické nové zostavenie obrazov PHP.
V Dockerfile určte presnú verziu PHP v tagu a zvyšujte ju vedome. V kóde je tak dohľadateľné, kedy sa ktorá verzia nasadila.
Ako PHP SOS konkrétne pomáha?
Pri zabezpečení servera pre webové servery PHP sa staráme aj o kontajnery:
- Kontrola obrazov: Základný obraz, verzia PHP, rozšírenia a konfigurácia každého obrazu.
- Sprísnenie konfigurácie: Produkčný ini, štíhly zoznam rozšírení, vhodné limity workerov a pamäte.
- Nastavenie nového zostavovania: Postup, ktorý obrazy pri nových vydaniach PHP zostaví znova a nasadí.
- Kontrola za behu: Dokladujeme, že v každom bežiacom kontajneri beží opravená verzia.
Časté otázky
Ktorý variant obrazu PHP je správny?
Pre Nginx alebo iný proxy variant fpm, pre jednoduché nasadenie s Apache variant apache, pre skripty a cronjoby variant cli. Varianty Alpine sú menšie, ale stavajú na musl namiesto glibc, čo sa pri niektorých rozšíreniach prejaví.
Aktualizuje sa PHP v kontajneri automaticky?
Nie. Bežiaci kontajner sa nemení. Obraz musíte zostaviť znova s novou verziou PHP a kontajnery reštartovať. Až potom beží opravená verzia.
Ako spolu súvisia memory_limit a limit kontajnera?
memory_limit obmedzuje každú jednotlivú požiadavku PHP, limit kontajnera celý kontajner. Oba musia k sebe pasovať: počet workerov krát pamäť na workera by mal byť pod limitom kontajnera.
Potrebujem v kontajneroch php.ini?
Áno. Oficiálne obrazy dodávajú php.ini-development a php.ini-production ako šablóny. Pre produkciu dokumentácia obrazu výslovne odporúča produkčnú šablónu; vlastné nastavenia patria do conf.d.