CI/CD: samodejna ponovna gradnja slik PHP

Na kratko: Slika Docker vsebuje PHP v stanju svojega časa gradnje in zastara tudi brez spremembe kode. Kdor slike samodejno gradi znova, časovno vodeno in ob varnostnih obvestilih, v cevovodu preverja različico PHP in uvaja prek digesta, popravke, kot je tisti proti PHP2Shell, načrtovano spravi v produkcijo. Zelena gradnja sama ni dokaz; šteje različica v tekočem vsebniku.

Zakaj slike zastarajo brez spremembe kode

V mnogih ekipah se cevovod gradnje zažene samo, kadar kdo spremeni kodo. Za aplikacijo je to logično. Za varnost je to težava, ker PHP v sliki izvira iz osnovne slike z oznako zadnje gradnje.

PHP2Shell je to naredil vidno. Odpravljeni različici 8.5.12, 8.4.27, 8.3.36 in 8.2.35 so izšle 21. oktobra 2026. Projekt, pri katerem v teh dneh nihče ni delal, ni dobil nove gradnje in je tekel naprej s starim PHP, čeprav je bila osnovna slika že zdavnaj posodobljena. Ročno pot iz tega položaja opisuje Popravljanje PHP v vsebnikih Docker. Ta prispevek kaže, kako jo avtomatizirate.

Samodejna ponovna gradnja slik Docker: trije sprožilci

Robusten postopek združuje več sprožilcev, da nobeden ne nosi sam.

Pri GitHub Actions urnik prevzame dogodek schedule. Po dokumentaciji GitHub uporablja sintakso cron s petimi polji, teče v UTC in samo na privzeti veji. Načrtovani zagoni se lahko pri veliki obremenitvi zakasnijo, v javnih repozitorijih pa jih GitHub po 60 dneh brez aktivnosti izklopi. Prav to zadene mirne projekte, torej ravno tiste, ki samodejno ponovno gradnjo najbolj nujno potrebujejo.

Za drugi sprožilec Dependabot po dokumentaciji GitHub podpira ekosistem docker in nova stanja osnovnih slik predlaga kot pull request. Poznati je treba dve omejitvi. Prvič, nekdo mora pull request pregledati in združiti, sicer obleži. Drugič, pri oznaki veje, kot je php:8.3-fpm, se v Dockerfileu nič ne spremeni, ko se osnovna slika znova zgradi. Orodje, ki predlaga spremembe besedila, potem nima ničesar predlagati. Prav zato je poleg tega potrebna časovno vodena ponovna gradnja.

Tretji sprožilec zveni banalno, v praksi pa pogosto odpove pri vprašanju, kdo ga sproži. Določite, kdo spremlja varnostna obvestila o PHP in kdo sme zagnati cevovod, tudi ob koncu tedna. Pri PHP2Shell je med napovedjo in popravkom minil le en dan.

Cevovod, ki ujame zastarel PHP

Naslednji primer za GitHub Actions sliko gradi tedensko in na pritisk gumba, preveri različico PHP in prekine, če je pod odpravljenim stanjem. Register, imena in najnižjo različico prilagodite.

name: php-image-rebuild
on:
  schedule:
    - cron: "0 3 * * 1"      # ponedeljek ob 03:00 UTC
  workflow_dispatch: {}      # ročni zagon ob varnostnih obvestilih

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Image ohne Cache und mit frischem Basis-Image bauen
        run: docker build --pull --no-cache -t app:${{ github.run_id }} .
      - name: PHP-Version prüfen (Mindeststand des Zweigs 8.3)
        run: |
          docker run --rm app:${{ github.run_id }} php -v
          docker run --rm app:${{ github.run_id }} \
            php -r 'exit(version_compare(PHP_VERSION, "8.3.36", ">=") ? 0 : 1);'

Preverjanje različice deluje pri uradnih slikah PHP, katerih številka različice kaže dejansko stanje. Če vaša slika uporablja pakete PHP distribucije, številka po backportu pogosto ostane enaka. Tedaj namesto številke preverite changelog paketa glede številk CVE, kot opisuje prispevek Dokazovanje številk CVE v changelogu paketa.

Po preverjanju v praksi sledijo še trije koraki: pregled slike glede znanih ranljivosti, potiskanje v register z datumom in digestom ter predaja digesta uvajanju. Katere oznake in variante so primerne za osnovo, pojasnjuje Uradne slike PHP Docker.

Od gradnje do tekočega vsebnika

Najpogostejša miselna napaka: cevovod je zelen, torej je vse popravljeno. V resnici nova slika leži le v registru. Popravek postane učinkovit šele, ko je vsak vsebnik iz nove slike na novo ustvarjen.

1. Uvedba prek digesta: Uvajanje se sklicuje na digest nove slike, ne na premikajočo se oznako.
2. Najprej staging, nato produkcija: Samodejni testi na kopiji ujamejo zlome zaradi novih osnovnih slik.
3. Preverjanje v delovanju: Po uvedbi zaženite php -v v tekočem vsebniku in digest primerjajte z gradnjo.
4. Omejitev poti nazaj: Stara slika ostane kratek čas na voljo za vrnitev, vsebuje pa ranljiv PHP.

V Kubernetesu za to veljajo lastna pravila, na primer o politiki prenosa; opisana so pod Popravljanje PHP v Kubernetesu.

Tipične vrzeli v verigi

• Predpomnilnik gradnje na runnerju: Brez --pull in --no-cache se stara osnovna slika znova uporabi.
• Zrcalo registra: Notranji vmesni pomnilnik še dostavlja staro stanje osnovne slike.
• Večstopenjske gradnje: Šteje različica PHP zadnje stopnje, preverja pa se pogosto samo prva.
• Stranske slike: Delavci čakalnih vrst, vsebniki cron in notranja orodja imajo lastne cevovode ali nobenih.
• Fiksno vpisani digesti: Enkrat zapisan digest osnovne slike se nikoli ne posodobi, če ga nobeno orodje ne spremlja.

Kdo se odzove, če ponovna gradnja ne uspe?

Samodejna ponovna gradnja je tako dobra kot odziv na njeno odpoved. Če preverjanje različice sproži alarm ali gradnja zaradi spremenjene osnovne slike odpove, mora to nekdo opaziti. V mnogih ekipah taka sporočila pristanejo v poštnem predalu, ki ga nihče ne bere, ali v kanalu, v katerem so rdeče gradnje že zdavnaj vsakdan.

Obneslo se je jasno pravilo: neuspela varnostna ponovna gradnja je zahtevek z odgovorno osebo in rokom, ne opozorilo med mnogimi. Za vsako uvedeno sliko zabeležite tudi datum, digest in preverjeno različico PHP. Ta seznam ob naslednjem obvestilu v minutah odgovori, katere aplikacije so prizadete, in služi kot dokaz za revizorje ali zavarovalnice. Kako iz tega nastane trajen postopek, opisuje Upravljanje popravkov kot postopek namesto gašenja požarov.

Kako PHP SOS pomaga konkretno?

• Pregled cevovodov: Preglejmo vaše verige gradnje in uvajanja ter pokažemo, kje lahko popravek obtiči.
• Avtomatizacija ponovne gradnje: Vzpostavimo časovno vodene gradnje, preverjanje različice in uvajanje prek digesta.
• Zajem vseh slik: Vsakemu tekočemu vsebniku dodelimo njegov cevovod, tudi stranskim in starim slikam.
• Trajna oskrba: V varnostni vzdrževalni pogodbi spremljamo varnostna obvestila in sprožamo ponovne gradnje.

Pogosta vprašanja

Viri

• GitHub Docs: dogodki, ki sprožijo delovne tokove (schedule)
• GitHub Docs: ekosistemi, ki jih podpira Dependabot
• Docker Hub: uradna slika PHP
• PHP: podprte različice