PHP in containers draaien

Kort gezegd: Om PHP in containers te draaien kiest u de passende variant van het officiële image (fpm, apache of cli), activeert u de productie-php.ini, installeert u alleen benodigde extensies en stelt u geheugen- en procesgrenzen in die bij elkaar passen. Containers zijn onveranderlijk: een PHP-beveiligingsupdate zoals die voor PHP2Shell werkt pas wanneer het image opnieuw is gebouwd en elke container opnieuw is gestart. Deze nieuwbouw hoort daarom als vast proces bij elk containerbedrijf.

Waarom PHP in containers?

Containers verpakken PHP, extensies en configuratie in een image dat op elke server hetzelfde draait. Voor bedrijven betekent dat: minder verrassingen tussen test en productie, snellere herstelling en duidelijke versiestanden. Voor de beveiliging betekent het echter ook een nieuwe plicht: in een container voert niemand automatisch updates door.

Deze pagina behandelt het lopende bedrijf. Hoe u bestaande containers concreet tegen PHP2Shell patcht, staat onder PHP in Docker-containers patchen.

De juiste imagevariant kiezen

Voor nieuwe projecten verdient in de regel de fpm-variant met een gescheiden webservercontainer de voorkeur. Bij mod_php ziet het PHP-team in verband met PHP2Shell het hoogste risico; wie het apache-image gebruikt, draait precies deze bedrijfsmodus.

Een productie-image bouwen

Een slank voorbeeld voor een toepassing met MySQL-toegang:

FROM php:8.4-fpm-alpine

# Productieconfiguratie activeren (volgens de imagedoc dringend aanbevolen)
RUN mv "$PHP_INI_DIR/php.ini-production" "$PHP_INI_DIR/php.ini"

# Alleen benodigde extensies
RUN docker-php-ext-install -j"$(nproc)" pdo_mysql

# Eigen instellingen
COPY zz-sicherheit.ini "$PHP_INI_DIR/conf.d/"

# De code is van root; de FPM-workers draaien als www-data en kunnen hem alleen lezen
COPY . /var/www/html

De hulpscripts van het image nemen het bouwen van extensies over: docker-php-ext-configure voor opties, docker-php-ext-install om te bouwen, docker-php-ext-enable om te activeren, bijvoorbeeld na pecl install. Wordt met docker-php-source de broncode uitgepakt, dan moet die volgens de doc in dezelfde laag weer worden verwijderd. Het bestand zz-sicherheit.ini kan er zo uitzien:

expose_php = Off
display_errors = Off
log_errors = On
session.use_strict_mode = 1
session.cookie_httponly = 1

Twee verdere uitgangspunten maken images robuuster. Ten eerste bevat het uitgeleverde image alleen wat tijdens de uitvoering nodig is; compilers, pakketcaches en testbestanden horen in een eigen buildfase. Ten tweede mag de gebruiker onder wie PHP draait alleen schrijven waar het nodig is, bijvoorbeeld in upload- of cachemappen op gekoppelde volumes. Veel teams draaien de container bovendien met een tegen schrijven beveiligd bestandssysteem. Een binnengesmokkeld PHP-bestand heeft het dan aanzienlijk moeilijker om blijvend te zijn, en elke herstart herstelt de schone staat van het image. Dat vervangt geen onderzoek na een incident, maar verkleint het aanvalsoppervlak merkbaar.

Processen, geheugen en logs in de container

Drie afstelschroeven bepalen of een PHP-container stabiel draait.

1. Aantal workers: pm.max_children in de FPM-pool bepaalt hoeveel verzoeken gelijktijdig worden afgehandeld. Elke worker kan tot memory_limit in beslag nemen.
2. Geheugengrens van de container: Ze begrenst alle processen samen. Als vuistregel geldt: aantal workers maal geheugen per worker plus reserve moet onder de limiet passen, anders beëindigt het systeem processen.
3. Logs: Containers schrijven logs naar de standaarduitvoer. In PHP-FPM stuurt catch_workers_output = yes uitvoer van de workers naar het hoofdlog; zonder de instelling verdwijnt die volgens de handleiding in het niets.

Nuttig is bovendien request_terminate_timeout, dat afzonderlijke verzoeken na een tijdsduur beëindigt wanneer max_execution_time niet ingrijpt. Hoe u containers in het cluster beheert, beschrijft PHP in Kubernetes patchen.

Containers en beveiliging: wat PHP2Shell heeft getoond

Bij PHP2Shell spelen containers een dubbele rol. Enerzijds zijn ze een hulp: php.net adviseert als overgangsmaatregel bij CVE-2026-109618 memory_limit=-1 te combineren met een geheugengrens via container of cgroup, bij voorkeur zo dat alleen de getroffen worker wordt beëindigd. RLIMIT_AS en RLIMIT_DATA zijn daarvoor volgens php.net ongeschikt. Deze maatregel is geen volledige bescherming en vervangt de update niet.

Anderzijds zijn containers een valkuil wanneer images niet opnieuw worden gebouwd. Een image met PHP 8.4.26 blijft kwetsbaar, hoe vaak de container ook opnieuw start. Pas een nieuwbouw naar 8.4.27 of nieuwer en de vervanging van alle draaiende containers dichten het lek. De stand laat zich direct in de draaiende container controleren:

docker exec <container> php -v
docker exec <container> php-fpm -v
docker exec <container> php -r 'var_dump(ini_get("memory_hard_limit_percent"));'

Levert de laatste opdracht bool(false) op, dan kent PHP de met de fix-versies ingevoerde directive niet; volgens de handleiding is de versie dan getroffen. Blijvend helpt alleen een automatische nieuwbouw, zoals beschreven onder CI/CD: PHP-images automatisch opnieuw bouwen.

Hoe helpt PHP SOS concreet?

Bij de serverhardening voor PHP-webservers zorgen wij ook voor containers:

• Images controleren: Basisimage, PHP-versie, extensies en configuratie van elk image.
• Configuratie harden: Productie-ini, slanke extensielijst, passende worker- en geheugengrenzen.
• Nieuwbouw inrichten: Een verloop dat images bij nieuwe PHP-releases opnieuw bouwt en uitrolt.
• Looptijd controleren: Wij tonen aan dat in elke draaiende container de gecorrigeerde versie draait.

Veelgestelde vragen

Bronnen

• Docker Official Image: PHP
• PHP-handleiding: FPM-configuratie
• php.net: beveiligingsmelding van 21 oktober 2026