# PHP ielāpošana Kubernetes > Kubernetes PHP image ielāpošana pēc PHP2Shell: atrodiet ievainojamos podus, pārbūvējiet image, izlaidiet darba slodzes un pierādiet stāvokli katram podam. Avots: https://phpsos.de/lv/server/kubernetes/ Aktuāls uz: 25.10.2026 Pakalpojuma sniedzējs: PHP SOS, PHP ārkārtas palīdzība un serveru drošība. Tūlītēja palīdzība pa WhatsApp: https://wa.me/491736494914?text=Sveiki%2C%20PHP%20SOS%2C%20mums%20nepiecie%C5%A1ama%20pal%C4%ABdz%C4%ABba%20ar%20m%C5%ABsu%20PHP%20serveri.%20Uz%C5%86%C4%93mums%3A%20%E2%80%A6%20Vietne%3A%20%E2%80%A6 **Īsi:** Kubernetes PHP atrodas konteinera image, nevis klasterī. Pēc PHP2Shell katrs Kubernetes PHP image jāpārbūvē ar labotu PHP versiju, visas skartās darba slodzes jāizlaiž no jauna un pēc tam katrā darbojošajā podā jāpārbauda stāvoklis. Atjaunināts bāzes image registrā vien darbojošos podus nemaina. ## Kāpēc klasteris pats neielāpo Kubernetes pārvalda konteinerus, bet nerūpējas par programmatūru tajos. Katrs pods darbojas ar image, no kura tas tika startēts, līdz tiek aizstāts. Kas klasterī darbina PHP lietojumprogrammas, tam tāpēc jāatbild par image, pat ja klasteris darbojas kā pārvaldīts pakalpojums pie mākoņpakalpojumu sniedzēja. Sniedzējs parasti uztur vadības līmeni un mezglus, nevis klientu image. PHP2Shell ietver CVE-2026-109618 un CVE-2026-109619, katru ar CVSS v4.0 9.2. Skarti ir, cita starpā, PHP-FPM, Apache ar mod_php un FrankenPHP, tātad ierastie darbības režīmi PHP image. Labotas ir PHP 8.5.12, 8.4.27, 8.3.36 un 8.2.35. ## Inventarizācija: kurš Kubernetes PHP image kur darbojas? Sāciet ar visu klastera image sarakstu. Turpmākās komandas tikai lasa. Namespace, deployment un konteineru nosaukumi ir piemēri. ```bash # Visu podu visi image, grupēti kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{range .spec.containers[*]}{.image}{" "}{end}{"\n"}{end}' # Faktiski darbojošais image digest katram konteineram kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{range .status.containerStatuses[*]}{.imageID}{" "}{end}{"\n"}{end}' # PHP versija darbojošā podā kubectl exec -n shop deploy/web -c php -- php -v ``` Līdzās Deployment padomājiet arī par StatefulSet, DaemonSet, CronJob un init konteineriem. Lielākos klasteros palīdz image skeneri, kas meklē image zināmas CVE. Distributīva pakotnēm image iekšienē kā visur: backports var atstāt versijas numuru nemainītu, tad noteicošs ir pakotnes izmaiņu žurnāls. ## Image pārbūve Vispirms atjauniniet bāzes image. Ja izmantojat oficiālos PHP image, izvēlieties variantu ar labotu PHP versiju. Pēc tam pārbūvējiet savu image, nepārņemot veco bāzes slāni no kešatmiņas. ```bash # Piemērs: pārbūvēt image, bāzes image aktīvi ielādēt no jauna docker build --pull --no-cache -t registry.example.com/shop/web:2026-10-25 . # Pārbaudīt PHP versiju jaunajā image pirms rollout docker run --rm registry.example.com/shop/web:2026-10-25 php -v ``` Nepaļaujieties uz tagiem, piemēram, `latest`, vai tikai galveno versiju. Manifestā pēc iespējas atsaucieties uz jaunā image digest, lai būtu skaidrs, kurš stāvoklis tiek izlaists. Ja izvietošana notiek caur GitOps vai Helm, mainiet image tur, lai stāvoklis nākamajā salīdzināšanā netiktu atiestatīts. ## Rollout un kontrole Jauns rollout pakāpeniski aizstāj visus darba slodzes podus. Pēc tam pārbaudiet stāvokli darbojošajos podos. Tikai tad ielāps ir spēkā, jo jauni faili palīdz tikai tad, ja veci PHP procesi vairs nedarbojas. ```bash # Rollout ar jaunu image (nosaukumi kā piemērs) kubectl -n shop set image deploy/web php=registry.example.com/shop/web@sha256: kubectl -n shop rollout status deploy/web # Kontrole: visi podi pārstartēti, aktīvs jaunais digest? kubectl -n shop get pods -o wide kubectl -n shop exec deploy/web -c php -- php -v ``` Ja image zem tā paša taga ir ielādēts no jauna, `kubectl rollout restart` izraisa pārstartēšanu; podi image no jauna ielādē tikai tad, ja to paredz `imagePullPolicy`. Drošāk ir pāriet uz jaunu digest. > **Svarīgi:** > Saglabājiet žurnālus, pirms aizstājat podus. Kopā ar veco podu pazūd arī tā lokālie protokoli. Saglabājiet tīmekļa servera un lietojumprogrammas žurnālus no 2026. gada 20. oktobra, ideālā gadījumā centrālā žurnālu platformā. ## Pagaidu pasākumi klasterī Ja jūsu PHP versijai labota image vēl nav pieejama, php.net iesaka pagaidu pasākumus bez pilnīgas aizsardzības. Klasterī atmiņas ierobežojumus iestatiet ar konteineru resursu limitiem, kas balstās uz cgroups. Tas atbilst ieteikumam atmiņu ierobežot ar konteineru vai cgroups, nevis ar `RLIMIT_AS` vai `RLIMIT_DATA`. ```ini ; php.ini vai FPM pūls image, piem., pievienots ar ConfigMap session.upload_progress.enabled = 0 post_max_size = 8M upload_max_filesize = 6M ``` Ja ir augšupielādes funkcija, php.net min `post_max_size = 32M`. PHP 8.5 gadījumā klāt nāk `fatal_error_backtraces=0`. Pēc konfigurācijas maiņas nepieciešams jauns rollout. Papildus NetworkPolicy ierobežo PHP podu izejošos savienojumus, un Ingress ar aizsardzības noteikumiem var apgrūtināt uzbrukuma mēģinājumus. Noteikumi tikai pēc pieprasījuma datiem saskaņā ar Cloudflare tomēr nav pietiekami. ## Ilgtermiņa sagatavotība Plānojiet regulāras automātiskas visu PHP image pārbūves, image pārbaudi būvēšanas ķēdē un politikas, kas pieļauj tikai parakstītus vai pārbaudītus image. Ja PHP konteineri darbojas ar lietotāju bez root tiesībām un ar rakstīšanas aizsargātu failu sistēmu, veiksmīga uzbrukuma radītais kaitējums samazinās. Norādes atsevišķiem konteineriem atrodamas lapā [PHP ielāpošana Docker konteineros](https://phpsos.de/lv/php2shell/docker-container-patchen/), FrankenPHP lapā [FrankenPHP aizsardzība](https://phpsos.de/lv/server/frankenphp/). Daudzos klasteros PHP lietojumprogrammas nedarbojas vienas. Bieži ir sidecar konteineri žurnālu vai metriku vākšanai, palīgimage datubāzes migrācijām un darbi, kas startē tikai naktī. Arī trešo pušu image, piemēram, vikijam, uzraudzības saskarnei vai biļešu sistēmai, var saturēt PHP, un to nevar noteikt pēc nosaukuma. Tāpēc pārbaudiet ne tikai savas lietojumprogrammas, bet katru image klasterī. Svešiem image: gaidiet ražotāja atjaunināto versiju, pārbaudiet tā norādes par iekļauto PHP versiju un ierobežojiet sasniedzamību, līdz tā ir pieejama. Ja šāda sistēma darbojas tikai iekšēji, tas samazina risku, bet atjauninājumu neaizstāj. ## Kā PHP SOS palīdz konkrēti? - Mēs uzskaitām visas darba slodzes ar PHP, to image un digest un pārbaudām PHP versiju darbojošos podos. - Ar [PHP ielāpu pakalpojumu](https://phpsos.de/lv/leistungen/php-patch-service/) mēs pārbūvējam image, izlaižam tos un dokumentējam stāvokli katrai darba slodzei. - Mēs saglabājam žurnālus pirms nomaiņas un pārbaudām, vai nav uzbrukuma pēdu. - Ar [drošības monitoringu](https://phpsos.de/lv/leistungen/security-monitoring/) un automatizētām pārbūvēm mēs nodrošinām, ka nākamais ielāps klasterī nonāk ātrāk. ## Biežāk uzdotie jautājumi **Vai pietiek ar bāzes image atjaunināšanu registrā?** Nē. Darbojošies podi turpina izmantot image, ar kuru tie tika startēti. Podus aizstāj tikai jauns rollout ar jaunizveidoto image. Pēc tam pārbaudiet PHP versiju katrā darbojošajā podā. **Kāpēc image atsaukties pēc digest?** Tags var norādīt uz dažādiem image stāvokļiem atkarībā no tā, kad tas ielādēts. Digest apzīmē tieši vienu stāvokli. Tā jūs droši zināt, kurš kods kurā podā darbojas, un rollout kļūst izsekojami. **Kā ir ar CronJob un init konteineriem?** Arī tie var saturēt PHP un ietilpst inventarizācijā. CronJob katrā palaišanas reizē no savas veidnes startē jaunus podus; tāpēc atjauniniet image veidnē. Init konteineri darbojas katra poda startā. **Vai NetworkPolicy aizsargā pret PHP2Shell?** Tā ievainojamību neaizver, bet var ierobežot kaitējumu. Kas ierobežo PHP podu izejošos savienojumus, tas apgrūtina ļaunprātīga koda lejupielādi un sānvirziena kustību klasterī. ## Avoti - [php.net: drošības paziņojumi](https://www.php.net/) - [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php) - [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/) - [BSI (Vācijas Federālā informācijas drošības birojs)](https://www.bsi.bund.de/)