Podman, KVM ja konteinerid: praktiline juhend turvalise virtualiseerimise kohta

Informatec Digital » Ressursid » Podman, KVM ja konteinerid: praktiline juhend turvalise virtualiseerimise kohta

Kui hakkate Linuxis tõsist konteinerkeskkonda seadistama, tekib kohe sama küsimus: mil määral on ohutu loota ainult konteineritele ja millal on soovitatav uuendada KVM-ile või mikro-virtuaalmasinatele? Ettevõtte keskkondades, kus Docker, Podman, LXC, KVM virtuaalmasinad ja mitmesugused hüperviisorid on omavahel segamini, on isolatsioonimudeli hea mõistmine vigade vältimiseks võtmetähtsusega.

Lisaks pole haruldased ka mõnevõrra keerulised stsenaariumid, näiteks Docker Desktopi või Podmani kasutamine virtuaalmasinas VirtualBoxis või KVM-is , kus mängus on mitu virtualiseerimise taset (pesastatud või mitte) ja on lihtne kohata selliseid vigu nagu „KVM pole hostil lubatud“. Korraldame kõik need osad – konteinerid, virtuaalmasinad, Podman, KVM, võrgundus ja turvalisus – ning vaatame, kuidas neid ühendada, et saavutada tõeliselt turvaline ja praktiline virtualiseerimine.

Klassikaline virtualiseerimine KVM-i ja virtuaalsete masinatega

Kogu selle seadistuse aluseks on endiselt operatsioonisüsteemide täielik virtualiseerimine hüperviisorite, näiteks KVM, Xeni või ESXi abil . Siin käitab füüsiline riistvara hüperviisorit, mis vastutab masina "jagamise" eest mitmeks sõltumatuks virtuaalseks masinaks.

Selles mudelis käivitab iga virtuaalmasin oma kerneli ja külalisoperatsioonisüsteemi , mis on hostist täiesti eraldi. Hüperviisor (näiteks KVM, mis on integreeritud Linuxi kerneli) toimib riistvara ja virtuaalmasinate vahelise väravavahina ning vastutab nendevahelise tugeva isolatsiooni eest.

Üldiselt räägime kahte tüüpi hüperviisoritest: 1. tüüpi ehk paljad metallhüperviisorid, mis töötavad otse riistvaral, ja 2. tüüpi hüperviisorid, mis asuvad olemasoleva operatsioonisüsteemi peal. VirtualBox või VMware Workstation on 2. tüüpi , samas kui Linuxi serveris libvirti hallatav KVM on pigem 1. tüüpi stsenaariumile, kuigi see jagab ruumi hostiga.

Selle lähenemisviisi suurim eelis on see, et igal virtuaalmasinal on oma täielik stack: kernel, kasutajaruum, teenused, võrk ja salvestusruum . See pakub palju paindlikkust ja võimalust käitada samal füüsilisel masinal erinevaid operatsioonisüsteeme ja kerneli versioone.

Nende virtualiseeritud platvormide haldamiseks GNU/Linuxis kasutatakse libvirti peaaegu alati orkestreerimis-API-na , millele lisaks toetatakse graafilisi ja käsurea tööriistu või suuremaid projekte nagu OpenStack, mis loob täielikke pilvi, kombineerides virtuaalmasinaid, paljast metalli ja konteinereid.

Riistvaranõuded ja KVM-i levinumad probleemid

Enne KVM-i käitamist või sellest sõltuvate lahenduste (nt mõned Docker Desktopi või mikro-VM-i konfiguratsioonid) kasutamist peate veenduma, et protsessor toetab riistvara virtualiseerimist (VT-x Intelil või SVM/AMD-V AMD-l) ja et see on BIOS-is/UEFI-s lubatud.

Linuxis on meil kiire kontroll: kui käsk `grep -E 'svm|vmx' /proc/cpuinfo` ei tagasta midagi või see valik on püsivaras endiselt keelatud, siis KVM ei tööta. Lisaks, stsenaariumides, kus käitame virtuaalmasinaid teise virtuaalmasina sees (pesastatud virtualiseerimine), peab ülemise taseme hüperviisor need laiendused külalisarvutile selgesõnaliselt avaldama.

Kui midagi läheb valesti, ilmuvad tüüpilised teated, näiteks kurikuulus Docker Desktopi hüpikaken RHEL 9-s VirtualBoxi sees: „KVM pole hostil lubatud .“ Probleem ei seisne siin otseselt Dockeris ega RHEL-is, vaid pigem selles, et VirtualBoxi virtuaalmasin ei saa KVM-i käitamiseks vajalikke virtualiseerimislaiendusi.

Käsklused nagu `modprobe kvm` või `modprobe kvm_amd / kvm_intel` peaksid kerneli moodulid laadima ilma veateadeteta. Kui `dmesg` ei näita midagi olulist või `lsmod | grep kvm` näitab ainult tühist `kvm` ja `irqbypass` ning protsessorispetsiifilised moodulid puuduvad, on väga tõenäoline, et riistvara virtualiseerimine ei ole külalissüsteemile avatud või on see püsivaras keelatud.

Sellistel juhtudel, isegi kui kõik külaliskeskkonnas on kõik võimalikud funktsioonid lubatud, kui VirtualBox ei paku pesastatud virtualiseerimist või see on valesti konfigureeritud, siis KVM lihtsalt ei tööta . Lahendus hõlmab hosti hüperviisori konfiguratsiooni (VirtualBox, VMware jne) ülevaatamist ja pesastatud virtualiseerimise lubamist, kui see on saadaval.

Konteinerid: kerge virtualiseerimine operatsioonisüsteemi tasandil

Erinevalt traditsioonilistest virtuaalmasinatest pakuvad konteinerid teistsugust lähenemisviisi: nad ei emuleeri kogu riistvara, vaid taaskasutavad hosti kerneli ning isoleerivad protsesse ja ressursse Linuxi kerneli funktsioonide abil.

Konteiner on sisuliselt nimeruumide ja cgroup'ide abil kapseldatud protsesside kogum . Selles "keskkonnas" arvab rakendus, et see töötab oma masinas, oma failisüsteemi, võrguliideste ja PID-idega, kuid tegelikkuses jagab see kerneli hostiga.

Konteinerid pakuvad peaaegu natiivset jõudlust, kuna neil pole vaja teist kerneli ega täielikku riistvara emuleerimist . Lisakoormus on minimaalne: täpselt nii palju kui vaja nimeruumide ühendamiseks, ressursside piiramiseks cgroups'idega ja turvapoliitikate (seccomp, AppArmor, SELinux jne) jõustamiseks.

Sellel disainil on aga oluline tagajärg: kõik töökoormused jagavad sama füüsilist kerneli . Selle kerneli tõsine haavatavus võib ootamatult muutuda potentsiaalseks põgenemisvektoriks kõigile sellel sõlmel töötavatele konteineritele.

Seepärast öeldakse tihti, et konteineri isolatsioon ei ole "absoluutne" nagu virtuaalmasina puhul . Kui kellelgi õnnestub ära kasutada kriitilist kerneli viga, lakkavad nimeruumid olemast efektiivne barjäär ning konteinerite ja hostide vahelised piirid võivad hägustuda.

Nimeruumid ja cgroupid: konteinerite isoleerimise alus

Linuxis tugineb konteinerite isolatsioon kahele peamisele sambale: nimeruumid süsteemivaadete eraldamiseks ja cgroups ressursside piiramiseks ja arvestamiseks.

Nimeruumid isoleerivad selliseid asju nagu PID-id, võrk, ühenduspunktid, IPC, hostinimi (UTS) ja kasutajad . Sel viisil "näeb" protsess ainult oma nimeruumi protsesse, võrguliideseid, failisüsteemi ja hostinime, andes sellele tunde, nagu asuks see teises süsteemis.

Cgroups omalt poolt võimaldavad teil määrata, kui palju protsessorit, mälu, ketta sisend-/väljundvõimsust, protsesside arvu jne konteiner tarbida saab . See hoiab ära kontrollimatu koormuse kogu hosti ülekoormamise, mis on oluline sõlmede jagamisel meeskondade või projektide vahel.

Siiski on oluline mõista, et nimeruumid ja cgroupid üksi ei ole täielik turvasüsteem . Need ei takista kerneli haavatavuste ärakasutamist, ei filtreeri süsteemikõnesid ega halda detailseid juurdepääsupoliitikaid. Need on küll alus, aga neid tuleb tugevdada.

Mõistlik viis keskkonna karastamiseks on kombineerida syscall-filtreid seccompi, MAC-poliitikatega (AppArmor või SELinux) ja protsesside võimekuste drastiliselt vähendades , ideaalis koos kasutajanimeruumide ja juurteta režiimiga, et minimeerida kahju, kui kellelgi õnnestub konteinerist pääseda.

Konteinerplatvormide turvaohud

Päris konteinerplatvormil on rünnakupind jaotatud mitme kihi vahel: kernel ja käituskeskkond (runc, containerd, CRI-O), kujutise tarneahel, konteineri/orkestraatori konfiguratsioon ja aluseks olev infrastruktuur (pilv, salvestusruum, IAM, võrk).

Levinud rünnakuvektorite hulka kuuluvad tarkvara haavatavused kernelis või konteineri käituskeskkonnas, ebaturvaliste või hooldamata kujutiste kasutamine, konfiguratsioonivigade tegemine Kuberneteses või Dockeris (privilegeeritud konteinerid, ohtlikud hostiühendused, liiga avatud võrgurežiimid) ning turvavead registrites või CI/CD torujuhtmetes.

Paljudes reaalsetes intsidentides pole tegemist üheainsa "maagilise veaga", vaid pigem teadaoleva haavatavuse ja lohaka konfiguratsiooni kombinatsiooniga : konteinerid töötavad root'ina, lipu --privileged kasutamine, hosti failisüsteemi paigaldamine konteinerisse ning seccomp või MAC-aadressi puudumine.

Kõigele lisaks on oluline tarneahela probleem: avalikud baaskujutised sisaldavad sageli CVE-sid, aegunud pakette ja halvasti kontrollitud sõltuvusi . Pahavaral on suhteliselt lihtne läbi lipsata või ohustatud teek jääda uinuma, kuni tingimused on selle käivitamiseks sobivad.

Seega pole see tootmiskeskkonnas valikuline: enne klastrisse juurutamist tuleb kujutisi skannida haavatavuste suhtes selliste tööriistadega nagu Trivy, Clair või Grype , kontrollida, milliseid registreid kasutatakse (Harbor, Quay, GHCR koos poliitikatega) ja need allkirjastada/kontrollida.

Docker vs Podman: mõju ohumudelile

Rakenduskonteinerite maailmas hõlmavad Docker ja Podman sarnaseid funktsioone, kuid nende arhitektuur erineb märkimisväärselt ja see muudab hostil kasutatavat turvamudelit .

Docker tugineb oma klassikalises root-režiimis kesksele deemonile (dockerd), mis töötab root-kasutajana . CLI suhtleb selle deemoniga faili /var/run/docker.sock või TCP kaudu ning just see privilegeeritud protsess loob ja hävitab konteinereid, haldab pilte, võrke ja köiteid ning suhtleb registritega.

See tähendab, et igaühel, kellel on juurdepääs Dockeri soklile, on praktiliselt hostile juurjuurdepääs , kuna nad saavad käivitada privilegeeritud konteinereid, ühendada suvalisi failisüsteeme ja muuta kriitilist konfiguratsiooni. Deemonist saab sisuliselt ainus rikkepunkt.

Podman seevastu sündis ideega olla deemonivaba konteinermootor, mis on Linuxile võimalikult "natiivne" . Puudub püsiv keskset protsessi; konteinereid juhib kasutaja või systemd ning integratsioon viimasega võimaldab konteinereid juhtida teenindusüksuste kaudu.

See lähenemisviis on paremini kooskõlas Unixi mudeliga, kus "iga protsess kuulub kasutajale, kes selle käivitab", ja väldib lootmist kõrge privileegiga deemonile . Lisaks pakub Podman ühilduvust Dockeri käskudega, lihtsustades migreerimist (keskkondades, kus te ei soovi Docker CE-d installida, saate isegi kasutada aliast `docker=podman`).

Juurteta režiim ja kasutajanimeruumid

Üks peamisi praktilisi edusamme võimaliku konteineri põgenemiskäsu mõju vähendamisel on juurteta režiim koos kasutajanimeruumidega . Küsimus, millele see püüab vastata, on: "Mis juhtub, kui konteiner pääseb põgenemiskäsuga?"

Kasutajanimeruumid võimaldavad teil konteineri UID 0 ümber kaardistada hostil olevale privilegeerimata UID-le . Teisisõnu, konteineri sees arvab rakendus, et on root, kuid hosti vaatenurgast on see protsess tegelikult tavaline kasutaja, kellel on määratud subuid/subgid vahemik.

Sel viisil, isegi kui ründaja saab konteineris juurõigused ja suudab kerneli või käitusaja ärakasutamise aheldada, teeb ta hostile naastes seda privilegeerimata kasutajana . Nad ei saa üle kirjutada juurbinaarfaile, ühendada tundlikke failisüsteeme ega manipuleerida seadmetega, mille puhul neil puuduvad vajalikud õigused.

Podman loodi algusest peale seda mudelit silmas pidades: vaikimisi juurteta konteineriseerimine igal võimalusel , SELinuxi/AppArmori ja cgroupside kasutamine isegi ilma juurteta ning tugev rõhk struktuuriliste privileegide minimeerimisele.

Docker pakub nüüd ka tõelist juurteta režiimi , kus dockerd ja konteinerid asuvad kasutajanimeruumis, erinevalt vanemast userns-remapist, kus deemon jäi root'iks. Turvalisuse seisukohast takistab see dockerdi vastu suunatud ärakasutamisel hostile automaatset juurjuurdepääsu andmist.

Konteinervõrgud Podmaniga: silla-, host-, MacVlan- ja juurteta liidesed

Teine oluline element turvalisuse ja praktilise toimimise jaoks on konteinervõrgu kiht . Podman pakub ühenduvuse tagamiseks mitmesuguseid mehhanisme, pöörates erilist tähelepanu juurteta stsenaariumidele.

Podman 4 tutvustas netavarki, võrgudraiverit, mis järgib CNI mudelit , et pakkuda konteineritele IP-aadresse sillavõrkudes, MacVlanides jne. Netavarki abil ühenduvad juurkasutajatega konteinerid tavaliselt vaikimisi võrguga nimega „podman”, mis on seotud hostil oleva Linuxi sillaga (podman0) ja mille aadress on 10.88.0.0/16.

See vaikimisi sillavõrk pakub SNAT-reeglite kaudu põhilist internetiühendust ja võimaldab teil konteinerporte hostile avaldada, kasutades `-po --publish`, mis genereerib DNAT-reeglid iptables/nftables failides. Dockeri ühilduvuse tagamiseks ei käita see võrk sisemist DNS-serverit.

Samuti saame luua kasutaja määratletud sildvõrke , mis isoleerivad konteinerite rühmad üksteisest ja pakuvad sisemist DNS-i. See võimaldab konteineritel oma privaatvõrgus nime järgi lahendada, lihtsustab teenuste eraldamist, mis ei peaks üksteist nägema, ning annab suurema kontrolli MTU, tulemüüride ja muude funktsioonide üle.

Täiustatud keskkondades on konteinerite hosti füüsilise võrguga otse ühendamiseks võimalik kasutada MacVlani või IPVLANi võrke . MacVlan võimaldab konteineritel omavahel suhelda, samas kui IPVLAN kipub neid rohkem isoleerima; need on kasulikud valikud juurutustes, kus iga konteinerit peab ülejäänud võrk nägema reaalse hosti rollis.

Juurteta võrgud: slirp4netns ja pasta

Kui kasutajal pole juurõigusi, lähevad asjad keeruliseks: privileegideta kasutaja ei saa globaalset võrgu nimeruumi vabalt muuta ega suvalisi liideseid luua, seega peab Podman ühenduvuse tagamiseks kasutama kasutajaruumi lahendusi.

Siin tulebki mängu slirp4netns , klassikaline mehhanism, mida Podman rootless kasutab . See projekt loob konteineri sees isoleeritud võrgukeskkonna ja kasutab kerneli slirp moodulit aadresside teisendamiseks (NAT) ning konteineri juurdepääsuks internetile hosti võrgu kaudu.

Praktikas loob slirp4netns konteineri võrgu nimeruumis TAP-liidese (näiteks tap0 IP-aadressiga 10.0.2.100 ja lüüsiga 10.0.2.2) ning suunab liikluse kasutajaruumis rakendatud TCP/IP-pinu kaudu. See on funktsionaalne, kuid lisab teatud lisakoormust ja piiranguid.

Üks neist piirangutest on see, et privileegideta kasutajad ei saa kasutada porte, mille suurus on alla 1024. sysctl parameeter net.ipv4.ip_unprivileged_port_start märgib, millisest portist alates neid "privileegideta" peetakse (vaikimisi 1024), kuigi seda saab hoolikalt reguleerida, kui turvamudel seda lubab.

Podman 5-s on slirp4netns asendatud pastaga, mis on vaikimisi juurteta mehhanism . Pasta töötab samuti täielikult kasutajaruumis, kuid tänu puuteliidesele ja kopeerimata tehnikatele saavutab see peaaegu natiivse võrgu jõudluse, vähendades latentsusaja ja läbilaskevõime mõju võrreldes slirp4netnsiga.

Sildade ja hostivõrkude loomine juurteta konteinerites

Isegi mitte-root režiimis töötades saame juurteta konteinereid ühendada vaikimisi "podman" sillavõrguga, kasutades `--network=podman`. See kasutab ära netavarki võimalusi ja kaardistab pordid hostiga `-p` abil, täpselt nagu root-režiimis.

Samuti on võimalik luua kasutaja määratletud sildvõrke juurteta keskkondades . Sellisel juhul ei looda sildu ja nendega seotud seadmeid hosti globaalses võrgu nimeruumis, vaid kasutaja nimeruumis, seega pole need liidesed hostilt lihtsa käsuga `sudo ip a` nähtavad.

Nende juurteta sildade kontrollimiseks pakub Podman käsku `podman unshare --rootless-netns` , mis avab kasutaja võrgu nimeruumis kesta. Sealt saab jälgida sisemisi sildu ja kontrollida otseühendust konteineritega.

Sellel isolatsioonil on kummaline mõju: Hostilt ei pruugi olla otseühendust nende juurteta konteinerite IP-aadressidega.aga see töötab hosti enda IP-aadressiga kaardistatud portidega, mis toimivad teenuse sisenemispunktina.
Konteinerite vaheliseks suhtluseks võimaldab kasutaja määratletud sillavõrku integreeritud DNS-server neil nimepidi rääkida, mis lihtsustab oluliselt hajutatud rakenduste seadistamist.

Teises otsas on hostvõrk (--network=host) , kus konteiner jagab võrgupinu hostiga ilma oma IP-aadressita. Selles režiimis, kui juurõigusteta konteiner käivitab serveri pordil 8080/tcp, on teenus otse hosti pordil 8080 saadaval, säästes pordi kaardistamist, kuid vähendades isolatsiooni.

Podman Desktop, pildindustööriistad ja kohalik orkestreerimine

Neile, kes eelistavad midagi visuaalsemat, pakub Podman Desktop graafilist keskkonda konteinerite, podide, piltide ja võrgukonfiguratsioonide haldamiseks arendusmasinates, toimides otsese alternatiivina Docker Desktopile, kuid tuginedes deemonivabale mootorile.

Pildid hangitakse käsuga `podman pull`, mis laadib alla failis `/etc/containers/registries.conf` määratletud registritest . Kui pildile ei ole lisatud registrinime, proovib Podman selle leida konfigureeritud registrijärjekorrast, kasutades vaikimisi silti `latest`.

Lisaks Podmani käsureale saame skopeot kasutada spetsiaalse tööriistana piltide haldamiseks, kontrollimiseks ja kopeerimiseks registrite ja kohalike repositooriumide vahel. Käsklused nagu copy, delete ja sync võimaldavad automatiseerida repositooriumide vahelist sünkroonimist, märkida pilte prügikoristuseks ja teisaldada artefakte keskkondade vahel.

Kui kujutis on alla laaditud, võimaldab `podman run` käivitada konteinereid, määrates transpordi ja tee (vaikimisi Dockeri transport ja otsides konfigureeritud registrist). Tavapärased valikud (-d, -p, --name, --pod jne) hõlmavad nii laboristsenaariume kui ka tõsisemaid juurutusi.

Igapäevast haldust teostatakse konteinerite loetlemiseks käsuga `podman ps`, olemasolevate eksemplaride peatamiseks või käivitamiseks käsuga `podman stop/start` ja peatatud konteinerite eemaldamiseks käsuga `podman rm` . Kui konteinerit on muudetud ja soovime selle uueks pildiks teisendada, salvestab `podman commit` need muudatused uue nime all.

Pod-id ja täiustatud teostusmudelid Podmaniga

Kubernetese inspireerituna võimaldab Podman teil konteinereid grupeerida pod'ideks, mis jagavad sama võrgupinu ja teatud ressursse . See on ideaalne muster selliste asjade jaoks nagu andmebaas ja selle klient või mitu mikroteenust, mis peavad suhtlema madala latentsusega.

Käsk `podman pod create` loob uue podi ja tagastab selle ID, kuid vaikimisi jääb pod peatatuks, kuni käivitatakse seotud konteiner või see käivitatakse selgesõnaliselt käsuga `podman pod start`.

Süsteemis olevate podide nägemiseks kasutage käsku `podman pod ls` , mis kuvab ka iga podiga seotud INFRA konteineri. See spetsiaalne konteiner hoiab võrgu ja muud podi jagatud ressursid töös, seega konteinerite arv pole kunagi null.

Podman pakub spetsiifilisi käske tervete podide käivitamiseks, peatamiseks või taaskäivitamiseks (podman pod start/stop/restart) , aga me saame tegutseda ka ainult konkreetse konteineri peal podis, muutmata ülejäänud osa, säilitades protsesside isolatsiooni rakenduse tasandil.

Olemasolevale podile konteinerite lisamiseks kasutage käsku `podman run --pod POD_NAME` , järgides sama süntaksit nagu üksikute konteinerite puhul. Konteinerit ei saa podist eemaldada ilma seda hävitamata, kuna podi liikmelisus on seotud selle elutsükliga.

Jälgimist saab teostada käsuga podman ps –pod või spetsiaalsete käskudega, et jälgida kõigi podide kõigi konteinerite protsesse , tuvastades kiiresti, mis millisesse gruppi kuulub ja kuidas teenused on jaotatud.

Konteinerid, LXC ja rakenduste virtualiseerimine

Kuigi Docker ja Podman domineerivad vestluses, pole need ainsad GNU/Linuxis kasutatavad konteinerdamisvõimalused . Lahendused nagu LXC/LXD, systemd-nspawn ja Kata Containers käsitlevad probleemi veidi erinevate nurkade alt.

LXC pakub väga kergeid süsteemikonteinereid, millel on oma hostinimi, IP-aadress, failisüsteem ja täielik initsialiseerimissüsteem . Koos LXD-ga, mis toimib konteinerite ja virtuaalmasinate hüperviisorina, pakub see kogemust, mis on väga sarnane mitme kerge masina omamisega peaaegu tühja metalliga jõudlusega.

Kuigi Docker/Podman keskendub OCI-ühilduvatele rakenduste konteineritele , särab LXC siis, kui on vaja püsivaid keskkondi mitme teenuse ja protsessiga, käitudes nagu virtuaalmasin, kuid väiksema üldkuluga ja väga loomuliku integratsiooniga Linuxi kerneliga.

Jõudluse seisukohast suudab LXC käitada andmemahukaid ettevõtterakendusi praktiliselt ilma karistusteta , mistõttu on see võimas valik latentsusaja suhtes tundlike töökoormuste jaoks, mis ei vaja traditsioonilise virtuaalmasina tugevat isolatsiooni.

Lisaks sellele on populaarsust kogunud ka mikro-virtuaalmasinatele ja täiustatud isolatsioonile suunatud tehnoloogiad, näiteks Kata Containers , mis käivitab iga podi väikese virtuaalmasina sees, millel on oma kernel, või gVisor, mis lisab rakenduse ja Linuxi vahele Go-keeles kirjutatud "kerneli liivakasti". Mõlemad vähendavad sõltuvust jagatud kernelist ja liiguvad lähemale virtuaalmasinate turvamudelile, säilitades samal ajal konteinerite kasutajasõbralikkuse.

Dockeri ja Podmani karastamise parimad tavad

Kõike eelnevat arvesse võttes on mõistlik lähenemisviis robustse konteinerplatvormi loomiseks töötada kihtidena: segmenteerimine nimeruumide/cgroups'idega, filtreerimispoliitikad seccomp'i ja MAC-aadressidega ning struktuuriliste õiguste piiramine juurteta režiimi kaudu.

Praktikas on soovitatav konteinerite käitamine mitte-root režiimis alati , kui see on võimalik, eriti mitme üürnikuga keskkondades või jagatud pilvedes. Podman hõlbustab seda vaikimisi ja Dockeri juurteta režiim hõlmab sama filosoofiat, kui ühilduvus on vajalik.

Hosti kerneli tuleb turvapaikadega ajakohasena hoida . Haavatavused, nagu Dirty COW, Dirty Pipe ja muud, lahendatakse värskendustega, mis tuleb suhteliselt kiiresti rakendada, kui me ei soovi jätta konteineripõgenemiste ohtu.

Teine väga tõhus meede on kasutada muutumatuid, konteinerpõhiste distributsioonide, näiteks openSUSE MicroOS või Flatcar Linux , kasutamine . Nende kirjutuskaitstud juurkasutaja ja aatomivärskendussüsteem vähendavad oluliselt rünnakupinda ja hõlbustavad tagasipööramisi, kui pärast parandust midagi valesti läheb.

Konfiguratsiooni osas: privilegeeritud konteinereid ei tohiks tootmiskeskkonnas kasutada, välja arvatud äärmiselt kontrollitud juhtudel , rakendusi ei tohiks konteineri sees root'ina käivitada, võimaluse korral tuleks kasutada kirjutuskaitstud failisüsteeme ja piirata võimalusi miinimumini. Rakenduse tegelike kõnede jaoks kohandatud SELinuxi/AppArmori ja seccompi profiilid on praktiliselt kohustuslikud.

Lõpuks ei tohi unustada ka rünnaku jälgimise aspekti . Tööriistad nagu Falco, Sysdig Secure või Aqua aitavad tuvastada anomaaliaid, põgenemiskatseid (näiteks ebatavaline juurdepääs /proc või /sys), ebatüüpilist võrguliiklust või kahtlaseid käske, andes aega reageerida enne rünnaku toimumist.

Klassikalise virtualiseerimise kombineerimisel KVM-iga, Podmani hallatavate konteineritega (eelistatavalt juurteta režiimis), hästi segmenteeritud võrkude ja heade turvalisuse tagamise tavadega saab luua väga paindliku ja üsna turvalise virtualiseerimisplatvormi. Mõistmine, et jagatud kernel on kõige kriitilisem punkt, virtuaalmasinatele või mikrovirtuaalmasinatele lootmine riski või regulatiivse vastavuse korral ning kujutiste tarneahela hoolikas haldamine teeb vahet laborikeskkonna ja tootmisvalmis infrastruktuuri vahel.