Popravljanje PHP v Kubernetesu

Na kratko: V Kubernetesu je PHP v sliki vsebnika, ne v gruči. Po PHP2Shell morate vsako sliko PHP v Kubernetesu znova sestaviti z odpravljeno različico PHP, vse prizadete delovne obremenitve znova razviti in nato v vsakem delujočem podu preveriti stanje. Posodobljena osnovna slika v registru sama na delujoče pode ne vpliva.

Zakaj gruča sama ne popravlja

Kubernetes upravlja vsebnike, a ne skrbi za programsko opremo v njih. Vsak pod teče s sliko, iz katere je bil zagnan, dokler ni zamenjan. Kdor v gruči poganja aplikacije PHP, je zato odgovoren za slike, tudi če gruča teče kot upravljana storitev pri ponudniku oblaka. Ponudnik praviloma vzdržuje nadzorno ravnino in vozlišča, ne pa strankinih slik.

PHP2Shell obsega CVE-2026-109618 in CVE-2026-109619, vsaka s CVSS v4.0 9,2. Prizadeti so med drugim PHP-FPM, Apache z mod_php in FrankenPHP, torej običajni načini delovanja v slikah PHP. Odpravljeni so PHP 8.5.12, 8.4.27, 8.3.36 in 8.2.35.

Popis: katera slika PHP v Kubernetesu teče kje?

Začnite s seznamom vseh slik v gruči. Spodnji ukazi samo berejo. Imena imenskih prostorov, deploymentov in vsebnikov so primeri.

# Vse slike vseh podov, združene
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{range .spec.containers[*]}{.image}{" "}{end}{"\n"}{end}'

# Dejansko delujoči digest slike za vsak vsebnik
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{range .status.containerStatuses[*]}{.imageID}{" "}{end}{"\n"}{end}'

# Različica PHP v delujočem podu
kubectl exec -n shop deploy/web -c php -- php -v

Poleg deploymentov pomislite tudi na StatefulSete, DaemonSete, CronJobe in inicializacijske vsebnike. V večjih gručah pomagajo optični bralniki slik (image scanner), ki slike pregledajo glede znanih CVE. Pri paketih distribucij znotraj slike velja kot povsod: backport lahko pusti številko različice nespremenjeno, takrat šteje dnevnik sprememb paketa.

Znova sestavite slike

Najprej posodobite osnovno sliko. Če uporabljate uradne slike PHP, izberite različico z odpravljeno različico PHP. Nato znova sestavite lastno sliko, ne da bi prevzeli staro osnovno plast iz predpomnilnika.

# Primer: znova sestavite sliko, osnovno sliko aktivno znova potegnite
docker build --pull --no-cache -t registry.example.com/shop/web:2026-10-25 .

# Pred rolloutom preverite različico PHP v novi sliki
docker run --rm registry.example.com/shop/web:2026-10-25 php -v

Ne zanašajte se na oznake, kot je latest, ali na golo glavno različico. V manifestu po možnosti referencirajte digest nove slike, da je nedvoumno, katero stanje se razvija. Če uvajanje poteka prek GitOps ali Helma, sliko spremenite tam, da se stanje ob naslednji uskladitvi ne ponastavi.

Rollout in kontrola

Nov rollout postopoma zamenja vse pode delovne obremenitve. Nato preverite stanje v delujočih podih. Šele takrat je popravek učinkovit, kajti nove datoteke pomagajo samo, če stari procesi PHP ne tečejo več.

# Rollout z novo sliko (imena kot primer)
kubectl -n shop set image deploy/web php=registry.example.com/shop/web@sha256:<digest>
kubectl -n shop rollout status deploy/web

# Kontrola: so vsi podi znova zagnani, je aktiven nov digest?
kubectl -n shop get pods -o wide
kubectl -n shop exec deploy/web -c php -- php -v

Če je bila slika pod isto oznako znova potisnjena, kubectl rollout restart sproži ponovni zagon; podi pa sliko znova potegnejo samo, če to predvideva imagePullPolicy. Varnejša je zamenjava na nov digest.

Vmesni ukrepi v gruči

Če za vašo različico PHP odpravljena slika še ni na voljo, php.net priporoča vmesne ukrepe brez popolne zaščite. V gruči omejitve pomnilnika nastavite prek omejitev virov vsebnikov, ki temeljijo na cgroups. To ustreza priporočilu, naj se pomnilnik omeji prek vsebnika ali cgroups in ne prek RLIMIT_AS ali RLIMIT_DATA.

; php.ini ali pool FPM v sliki, npr. vključen prek ConfigMap
session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 6M

S funkcijo nalaganja datotek php.net navaja post_max_size = 32M. Pri PHP 8.5 se doda fatal_error_backtraces=0. Po spremembi konfiguracije je potreben nov rollout. Dodatno NetworkPolicy omejijo odhodne povezave podov PHP, Ingress z zaščitnimi pravili pa lahko oteži poskuse napada. Pravila samo na podlagi podatkov zahteve pa po navedbah Cloudflare ne zadoščajo.

Trajno boljša postavitev

Načrtujte redno samodejno ponovno sestavljanje vseh slik PHP, preverjanje slik v verigi gradnje in pravilnike, ki dovoljujejo samo podpisane ali preverjene slike. Če vsebniki PHP tečejo z uporabnikom brez pravic root in z datotečnim sistemom samo za branje, se škoda uspešnega napada zmanjša. Napotki za posamezne vsebnike so na strani Popravljanje PHP v vsebnikih Docker, za FrankenPHP na strani Zaščita FrankenPHP.

V mnogih gručah aplikacije PHP ne tečejo same. Pogosto obstajajo vsebniki sidecar za beleženje ali metrike, pomožne slike za migracije zbirk podatkov in opravila, ki se zaženejo samo ponoči. Tudi slike tretjih ponudnikov, na primer za wiki, nadzorni vmesnik ali sistem za prijave, lahko vsebujejo PHP, ne da bi bilo to razvidno iz imena. Zato ne preverjajte samo lastnih aplikacij, temveč vsako sliko v gruči. Za tuje slike velja: počakajte na posodobljeno izdajo proizvajalca, preverite njegove navedbe o vsebovani različici PHP in omejite dosegljivost, dokler je ni. Če tak sistem teče samo interno, to tveganje zmanjša, vendar ne nadomesti posodobitve.

Kako PHP SOS konkretno pomaga?

• Popišemo vse delovne obremenitve s PHP, njihove slike in digeste ter preverimo različico PHP v delujočih podih.
• Prek storitve popravljanja PHP znova sestavimo slike, jih razvijemo in dokumentiramo stanje za vsako delovno obremenitev.
• Dnevnike zavarujemo pred zamenjavo in preverimo sledi napada.
• Z varnostnim nadzorom in samodejnim ponovnim sestavljanjem poskrbimo, da naslednji popravek hitreje pride v gručo.

Pogosta vprašanja

Viri

• php.net: varnostna obvestila
• PHP 8 ChangeLog
• OWASP Cheat Sheets (zbirke povzetkov)
• BSI (nemški zvezni urad za informacijsko varnost)