Lühidalt: Dockeri pilt sisaldab PHP-d oma ehitusmomendi seisuga ja aegub ka ilma koodimuudatuseta. Kes ehitab pilte automaatselt uuesti, ajastatult ja turvateadete korral, kontrollib konveieris PHP versiooni ning juurutab digesti järgi, toob paigad nagu PHP2Shelli vastu tootmisse planeeritavalt. Roheline ehitus üksi ei ole tõend; loeb töötava konteineri versioon.
Miks pildid ilma koodimuudatuseta aeguvad
Paljudes meeskondades käivitub ehituskonveier ainult siis, kui keegi koodi muudab. Rakenduse jaoks on see loogiline. Turvalisuse jaoks on see probleem, sest pildi PHP pärineb baaspildist viimase ehituse päeva sildiga.
PHP2Shell on seda nähtavaks teinud. Parandatud versioonid 8.5.12, 8.4.27, 8.3.36 ja 8.2.35 ilmusid 21. oktoobril 2026. Projekt, mille kallal nendel päevadel keegi ei töötanud, ei saanud uut ehitust ja töötas vana PHP-ga edasi, kuigi baaspilt oli ammu uuendatud. Käsitsi tee sellest olukorrast kirjeldab leht PHP paikamine Dockeri konteinerites. See artikkel näitab, kuidas seda automatiseerida.
Dockeri piltide automaatne uuesti ehitamine: kolm käivitajat
Töökindel protsess kombineerib mitu käivitajat, et ükski ei pea üksi kandma.
| Käivitaja | Teostus | Tähelepanuks |
|---|---|---|
| Ajakava | ajastatud töövoog, nt iganädalane | toob paigad kätte ka ilma koodimuudatuseta |
| Uus baaspilt | tööriist, mis jälgib baaspilte ja pakub muudatusi | toimib eelkõige fikseeritud versioonisiltide puhul |
| Turvateade | konveieri käsitsi käivitamine käitusmeeskonna poolt | vajab selget vastutajat |
GitHub Actionsis täidab ajakava sündmus schedule. GitHubi dokumentatsiooni kohaselt kasutab see viieväljalist cron-süntaksit, töötab UTC-s ja ainult vaikeharul. Ajastatud käivitused võivad suure koormuse korral hilineda ning avalikes hoidlates lülitab GitHub need pärast 60 päeva tegevusetust välja. Just viimane tabab vaikseid projekte, see tähendab neid, kes automaatset uuesti ehitamist kõige rohkem vajavad.
Teise käivitaja jaoks toetab Dependabot GitHubi dokumentatsiooni kohaselt ökosüsteemi docker ja pakub baaspiltide uusi seisusid pull requestina. Kaks piirangut peaksite teadma. Esiteks peab keegi pull requesti üle vaatama ja liitma, muidu jääb see seisma. Teiseks ei muutu haru sildi nagu php:8.3-fpm puhul Dockerfile'is midagi, kui baaspilt uuesti ehitatakse. Tekstimuudatusi pakkuval tööriistal ei ole siis midagi pakkuda. Just seetõttu on vaja lisaks ajastatud uuesti ehitamist.
Kolmas käivitaja kõlab banaalselt, kuid praktikas takerdub sageli küsimusse, kes selle käivitab. Määrake kindlaks, kes jälgib PHP turvateateid ja kes tohib konveierit käivitada, ka nädalavahetusel. PHP2Shelli puhul oli eelteate ja paiga vahel vaid üks päev.
Konveier, mis püüab aegunud PHP kinni
Järgmine GitHub Actionsi näide ehitab pildi iganädalaselt ja nupuvajutusel, kontrollib PHP versiooni ja katkestab, kui see on parandatud seisust madalam. Register, nimed ja miinimumversiooni kohandage.
name: php-image-rebuild
on:
schedule:
- cron: "0 3 * * 1" # esmaspäeviti 03:00 UTC
workflow_dispatch: {} # käsitsi käivitus turvateadete korral
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);'
Versioonikontroll toimib ametlike PHP piltide puhul, mille versiooninumber näitab tegelikku seisu. Kui teie pilt kasutab distributsiooni PHP pakette, jääb number pärast backporti sageli samaks. Siis kontrollige numbri asemel paketi muudatuslogist CVE-numbreid, nagu on kirjeldatud artiklis CVE-numbrite tõendamine paketi muudatuslogis.
Pärast kontrolli järgneb praktikas veel kolm sammu: pildi skaneerimine teadaolevate haavatavuste suhtes, selle registrisse lükkamine kuupäeva ja digestiga ning digesti andmine edasi juurutusele. Millised sildid ja variandid baasiks sobivad, selgitab Ametlikud PHP Dockeri pildid.
Ehitusest töötava konteinerini
Sagedaseim mõttevigu: konveier on roheline, seega on kõik paigatud. Tegelikult asub uus pilt vaid registris. Paik hakkab mõjuma alles siis, kui iga konteiner on uuest pildist uuesti loodud.
- Juurutage digesti järgi: juurutus viitab uue pildi digestile, mitte liikuvale sildile.
- Esmalt staging, siis tootmine: automaatsed testid koopial püüavad kinni uute baaspiltide põhjustatud katkestused.
- Kontrollige töös: pärast juurutust käivitage
php -vtöötavas konteineris ja võrrelge digesti ehitusega. - Piirake tagasitee: vana pilt jääb lühikeseks tagasiteeks kättesaadavaks, kuid sisaldab haavatavat PHP-d.
Kubernetes'es kehtivad selle jaoks omad reeglid, näiteks pull-poliitika kohta; need on lehel PHP paikamine Kubernetes'es.
Tüüpilised lüngad ahelas
- Ehitusvahemälu runneril: ilma valikuteta
--pullja--no-cachekasutatakse vana baaspilti uuesti. - Registri peegel: sisemine vahemälu annab endiselt baaspildi vana seisu.
- Mitmeastmelised ehitused: loeb viimase etapi PHP versioon, kontrollitakse aga sageli ainult esimest.
- Kõrvalpildid: järjekorra töölistel, cron-konteineritel ja sisetööriistadel on oma konveierid või üldse mitte ühtegi.
- Fikseeritud digestid: kord fikseeritud baaspildi digesti ei uuendata kunagi, kui seda ükski tööriist ei jälgi.
Uuesti ehitamine asendab PHP, mitte andmeid. Kahjulik kood, mis on enne paika jõudnud köidetesse (volume), üleslaadimiskataloogidesse või andmebaasi, jääb alles ja seda tuleb eraldi kontrollida.
Kes reageerib, kui uuesti ehitamine ebaõnnestub?
Automaatne uuesti ehitamine on nii hea kui reaktsioon selle ebaõnnestumisele. Kui versioonikontroll annab häire või ehitus katkeb muutunud baaspildi tõttu, peab keegi seda märkama. Paljudes meeskondades jõuavad sellised teated postkasti, mida keegi ei loe, või kanalisse, kus punased ehitused on ammu igapäevane nähtus.
Selge reegel on end tõestanud: ebaõnnestunud turvaline uuesti ehitus on pilet vastutaja ja tähtajaga, mitte üks teade teiste hulgas. Märkige lisaks iga juurutatud pildi kohta kuupäev, digest ja kontrollitud PHP versioon. See nimekiri vastab järgmise teate korral minutitega, millised rakendused on mõjutatud, ja on tõendiks auditeerijatele või kindlustajatele. Kuidas sellest saab püsiv protsess, kirjeldab Paigahaldus protsessina, mitte tuletõrjena.
Kuidas PHP SOS konkreetselt aitab?
- Konveierite kontroll: Vaatame teie ehitus- ja juurutusahelad üle ning näitame, kus paik võib kinni jääda.
- Uuesti ehitamise automatiseerimine: Seadistame ajastatud ehitused, versioonikontrolli ja juurutuse digesti järgi.
- Kõigi piltide kaardistamine: Seome iga töötava konteineri tema konveieriga, ka kõrval- ja vanad pildid.
- Püsiv hooldus: Turvahoolduslepingu raames jälgime turvateateid ja käivitame uuesti ehitamised.
Korduma kippuvad küsimused
Kui sageli peaks PHP pilti uuesti ehitama?
Kindlat arvu pole. End on tõestanud korrapärane ajastatud ehitus, näiteks iganädalane, pluss kohene ehitus turvateadete korral. Otsustav on, et uus paik ei pea ootama järgmist koodimuudatust.
Kas edukas ehitus on piisav tõend?
Ei. Ehitus tõendab ainult seda, et uus pilt on olemas. Paik on mõjus alles siis, kui töötavad konteinerid on sellest pildist uuesti loodud ja php -v näitab neis parandatud versiooni.
Miks ilmub pärast uuesti ehitamist ikkagi vana PHP versioon?
Sagedased põhjused on ehitusvahemälu, mis kasutab vana baaspilti uuesti, registri peegel vana seisuga või teine FROM-rida mitmeastmelises ehituses. Ehitage valikutega --pull ja --no-cache ning kontrollige iga etappi.
Kas Dependabot saab baaspilte uuendada?
GitHubi dokumentatsiooni kohaselt toetab Dependabot ökosüsteemi Docker versiooni- ja turvauuenduste jaoks. See pakub baaspiltide muudatusi pull requestina. Uuesti ehitamist muutumatu sildi puhul see ei asenda.