Podman, KVM in kontejnerji: praktični vodnik za varno virtualizacijo

Informatec Digital » Viri » Podman, KVM in kontejnerji: praktični vodnik za varno virtualizacijo

Ko začnete z nameščanjem resnega kontejnerskega okolja v Linuxu, se takoj pojavi isto vprašanje: v kolikšni meri je varno zanašati se izključno na kontejnerje in kdaj je priporočljivo nadgraditi na KVM ali mikro virtualne stroje? V poslovnih okoljih, kjer so pomešani virtualni stroji Docker, Podman, LXC, KVM in različni hipervizorji, je dobro razumevanje modela izolacije ključnega pomena za izogibanje napakam.

Poleg tega niso redki nekoliko zapleteni scenariji, kot je poskus uporabe Docker Desktop ali Podman znotraj virtualnega stroja v VirtualBoxu ali KVM , kjer pride v poštev več ravni virtualizacije (gnezdene ali ne) in je enostavno naleteti na napake, kot je »KVM ni omogočen na gostitelju«. Organizirajmo vse te dele – vsebnike, virtualne stroje, Podman, KVM, omrežje in varnost – in poglejmo, kako jih združiti, da dosežemo resnično varno in praktično virtualizacijo.

Klasična virtualizacija s KVM in virtualnimi stroji

Temelj celotne nastavitve ostaja popolna virtualizacija operacijskih sistemov z uporabo hipervizorjev, kot so KVM, Xen ali ESXi . Tukaj fizična strojna oprema poganja hipervizor, ki je odgovoren za "razdelitev" stroja na več neodvisnih virtualnih strojev.

V tem modelu vsak virtualni stroj zažene svoje jedro in gostujoči operacijski sistem , popolnoma ločeno od gostitelja. Hipervizor (na primer KVM, integriran v jedro Linuxa) deluje kot posrednik med strojno opremo in virtualnimi stroji ter je odgovoren za močno izolacijo med njimi.

Na splošno govorimo o dveh vrstah hipervizorjev: hipervizorji tipa 1 ali goli kovinski hipervizorji, ki delujejo neposredno na strojni opremi, in hipervizorji tipa 2, ki gostujejo na obstoječem operacijskem sistemu. VirtualBox ali VMware Workstation bi bil tipa 2 , medtem ko je KVM, ki ga upravlja libvirt na strežniku Linux, bližje scenariju tipa 1, čeprav si prostor deli s samim gostiteljem.

Največja prednost tega pristopa je, da ima vsak virtualni stroj svoj celoten sklad: jedro, uporabniški prostor, storitve, omrežje in shranjevanje . To zagotavlja veliko prilagodljivosti in možnost delovanja različnih operacijskih sistemov in različic jedra na istem fizičnem računalniku.

Za upravljanje teh virtualiziranih platform v GNU/Linuxu se libvirt skoraj vedno uporablja kot orkestracijski API , poleg katerega so podprta grafična orodja in orodja ukazne vrstice ali večji projekti, kot je OpenStack, ki gradi celotne oblake z združevanjem virtualnih strojev, golega ogrodja in vsebnikov.

Zahteve strojne opreme in pogoste težave s KVM

Preden zaženete KVM ali uporabite rešitve, ki so od njega odvisne (kot so nekatere konfiguracije Docker Desktop ali micro-VM), se morate prepričati, da procesor podpira virtualizacijo strojne opreme (VT-x na Intelu ali SVM/AMD-V na AMD) in da je omogočena v BIOS-u/UEFI-ju.

V Linuxu imamo hitro preverjanje: če ukaz `grep -E 'svm|vmx' /proc/cpuinfo` ne vrne ničesar ali če je možnost v vdelani programski opremi še vedno onemogočena, KVM ne bo deloval. Poleg tega mora v scenarijih, kjer bomo izvajali virtualne računalnike znotraj drugega virtualnega računalnika (gnezdena virtualizacija), hipervizor najvišje ravni te razširitve izrecno razkriti gostujočemu računalniku.

Ko gre kaj narobe, se pojavijo tipična sporočila, kot je na primer zloglasno pojavno okno Docker Desktop v RHEL 9 znotraj VirtualBoxa: »KVM ni omogočen na gostitelju .« Težava tukaj ni neposredno v Dockerju ali RHEL-u, temveč v tem, da virtualni stroj VirtualBox ne prejema potrebnih razširitev za virtualizacijo za zagon KVM-ja znotraj njega.

Ukazi, kot sta `modprobe kvm` ali `modprobe kvm_amd / kvm_intel`, bi morali naložiti module jedra brez sporočil o napakah. Če `dmesg` ne prikaže ničesar pomembnega ali `lsmod | grep kvm` prikaže le gola `kvm` in `irqbypass`, moduli, specifični za procesor, pa manjkajo, je zelo verjetno, da virtualizacija strojne opreme ni izpostavljena gostujočemu sistemu ali pa je onemogočena v vdelani programski opremi.

V teh primerih, tudi če so v gostujočem sistemu omogočene vse možne funkcije, KVM preprosto ne bo deloval, če VirtualBox ne ponuja vgnezdene virtualizacije ali je napačno konfiguriran . Rešitev vključuje pregled konfiguracije gostiteljskega hipervizorja (VirtualBox, VMware itd.) in omogočanje vgnezdene virtualizacije, če je na voljo.

Kontejnerji: lahka virtualizacija na ravni operacijskega sistema

V nasprotju s tradicionalnimi virtualnimi stroji ponujajo kontejnerji drugačen pristop: ne emulirajo vse strojne opreme, temveč ponovno uporabijo jedro gostitelja in izolirajo procese in vire z uporabo funkcij jedra Linuxa.

Vsebnik je v bistvu niz procesov, enkapsuliranih z imenskimi prostori in kontrolnimi skupinami . Znotraj tega "okolja" aplikacija verjame, da deluje na svojem računalniku, z lastnim datotečnim sistemom, omrežnimi vmesniki in PID-ji, v resnici pa si jedro deli z gostiteljem.

Vsebniki ponujajo skoraj izvorno zmogljivost, ker ni potrebno drugo jedro in ni popolne emulacije strojne opreme . Režijski stroški so minimalni: ravno toliko za priklop imenskih prostorov, omejevanje virov s cgroups in uveljavljanje varnostnih pravilnikov (seccomp, AppArmor, SELinux itd.).

Vendar ima ta zasnova pomembno posledico: vse delovne obremenitve si delijo isto fizično jedro . Resna ranljivost v tem jedru lahko nenadoma postane potencialni vektor pobega za vse vsebnike, ki se izvajajo na tem vozlišču.

Zato se pogosto pravi, da izolacija vsebnikov ni "absolutna" kot izolacija virtualnega stroja . Če nekomu uspe izkoristiti kritično napako v jedru, imenski prostori prenehajo biti učinkovita ovira, meje med vsebniki in gostitelji pa se lahko prebijejo.

Imenski prostori in cgroups: temelji izolacije vsebnikov

V Linuxu je izolacija vsebnikov zgrajena na dveh glavnih stebrih: imenskih prostorih za ločevanje sistemskih pogledov in kontrolnih skupinah za omejevanje in upoštevanje virov.

Imenski prostori izolirajo stvari, kot so PID-ji, omrežje, točke priklopa, IPC, ime gostitelja (UTS) in uporabniki . Na ta način proces "vidi" samo procese, omrežne vmesnike, datotečni sistem in ime gostitelja svojega imenskega prostora, kar mu daje občutek, da je na drugem sistemu.

Skupine cgroups pa vam omogočajo , da določite, koliko procesorja, pomnilnika, vhodno/izhodnih operacij diska, števila procesov itd. lahko vsebnik porabi . To preprečuje, da bi nenadzorovana obremenitev preobremenila celoten gostitelj, kar je bistveno pri souporabi vozlišč med ekipami ali projekti.

Vendar je ključnega pomena razumeti, da imenski prostori in kontrolne skupine sami po sebi niso popoln varnostni sistem . Ne preprečujejo izkoriščanja ranljivosti jedra, ne filtrirajo sistemskih klicev ali ne upravljajo podrobnih pravilnikov dostopa. So temelj, vendar jih je treba okrepiti.

Razumen način za okrepitev okolja je kombinacija filtrov sistemskih klicev s seccomp, pravilniki MAC (AppArmor ali SELinux) in drastičnim zmanjšanjem zmogljivosti procesov, idealno skupaj z uporabniškimi imenskimi prostori in načinom brez root-a, da se zmanjša škoda, če nekomu uspe pobegniti iz vsebnika.

Varnostne grožnje na kontejnerskih platformah

V resnični kontejnerski platformi je površina napada razporejena po več plasteh: jedru in izvajalnem okolju (runc, container, CRI-O), dobavni verigi slik, konfiguraciji kontejnerja/orkestratorja in osnovni infrastrukturi (oblak, shranjevanje, IAM, omrežje).

Med pogoste vektorje napadov spadajo programske ranljivosti v izvajalnem okolju jedra ali vsebnika, uporaba nezaščitenih ali nevzdrževanih slik, napake v konfiguraciji v Kubernetes ali Docker (privilegirani vsebniki, nevarne namestitve gostitelja, pretirano odprti omrežni načini) in varnostne pomanjkljivosti v registrih ali cevovodih CI/CD.

V mnogih resničnih incidentih ni ene same "čarobne napake", temveč kombinacija znane ranljivosti in ohlapne konfiguracije : vsebniki, ki se izvajajo kot root, uporaba zastavice --privileged, priklop datotečnega sistema gostitelja znotraj vsebnika in odsotnost seccomp ali MAC.

K vsemu temu se doda še težava dobavne verige: javne osnovne slike pogosto vsebujejo CVE, zastarele pakete in slabo nadzorovane odvisnosti . Zlonamerna programska oprema se relativno enostavno prebije ali pa ogrožena knjižnica ostane mirujoča, dokler niso izpolnjeni pogoji za njeno izvajanje.

Zato v produkciji to ni neobvezno: slike morate pregledati za ranljivosti z orodji, kot so Trivy, Clair ali Grype , nadzorovati, kateri registri se uporabljajo (Harbor, Quay, GHCR s pravilniki) in slike podpisati/preveriti, preden jih namestite v gručo.

Docker proti Podmanu: Vpliv na model groženj

V svetu aplikacijskih vsebnikov Docker in Podman pokrivata podobne funkcije, vendar se njuna arhitektura precej razlikuje, kar spremeni varnostni model, s katerim delamo na gostitelju.

Docker se v svojem klasičnem root načinu zanaša na osrednji demon (dockerd), ki se izvaja kot root . CLI komunicira s tem demonom prek /var/run/docker.sock ali prek TCP-ja, in prav ta privilegirani proces ustvarja in uničuje vsebnike, upravlja slike, omrežja in nosilce podatkov ter komunicira z registri.

To pomeni, da ima vsakdo z dostopom do vtičnice Docker praktično root dostop do gostitelja , saj lahko zažene privilegirane vsebnike, priklopi poljubne datotečne sisteme in spremeni kritično konfiguracijo. Daemon dejansko postane enotna točka odpovedi.

Podman pa se je rodil z idejo, da bi bil kontejnerski mehanizem brez demonov, ki je čim bolj "domačinski" Linuxu . Ni trajnega centralnega procesa; kontejnerje nadzoruje uporabnik ali systemd, integracija s slednjim pa omogoča nadzor kontejnerjev prek servisnih enot.

Ta pristop se bolje ujema z Unixovim modelom »vsak proces pripada uporabniku, ki ga zažene«, in se izogne ​​​​zanašanju na demon z visokimi privilegiji . Poleg tega Podman ponuja združljivost z Dockerjevimi ukazi, kar poenostavlja migracijo (v okoljih, kjer ne želite namestiti Docker CE, lahko celo uporabite vzdevek `docker=podman`).

Rootless način in uporabniški imenski prostori

Eden glavnih praktičnih napredkov pri zmanjševanju vpliva morebitnega pobega vsebnika je način brez korena v kombinaciji z uporabniškimi imenskimi prostori . Vprašanje, na katerega želi odgovoriti, je: "Kaj se zgodi, če vsebnik pobegne?"

Uporabniški imenski prostori vam omogočajo , da preslikate UID vsebnika 0 v neprivilegiran UID na gostitelju . Z drugimi besedami, znotraj vsebnika aplikacija meni, da je root, vendar je z vidika gostitelja ta proces v resnici običajen uporabnik z dodeljenim obsegom subuid/subgid.

Na ta način, tudi če napadalec pridobi korenske pravice znotraj vsebnika in mu uspe verižiti izkoriščanje jedra ali izvajalnega okolja, to po vrnitvi na gostitelja stori kot neprivilegiran uporabnik . Ne more prepisati korenskih binarnih datotek, priklopiti občutljivih datotečnih sistemov ali manipulirati z napravami, kjer nima potrebnih pravic.

Podman je bil od začetka zasnovan s tem modelom v mislih: privzeta uporaba root-brezkorenskih vsebnikov, kadar koli je to mogoče , uporaba SELinux/AppArmor in cgroups tudi brez root-a ter močan poudarek na zmanjševanju strukturnih privilegijev.

Docker zdaj ponuja tudi pravi način brez root-a , kjer se dockerd in vsebniki nahajajo znotraj uporabniškega imenskega prostora, za razliko od starejšega načina userns-remap, kjer je daemon ostal root. Z varnostnega vidika to preprečuje, da bi izkoriščanje dockerda samodejno podelilo root dostop gostitelju.

Kontejnerska omrežja s Podmanom: most, gostitelj, macvlan in vmesniki brez korena

Drug pomemben element za varnost in praktično delovanje je plast omrežja vsebnikov . Podman ponuja različne mehanizme za zagotavljanje povezljivosti, s posebnim poudarkom na scenarijih brez korenskega dostopa.

Podman 4 je predstavil netavark, omrežni gonilnik, ki sledi modelu CNI za zagotavljanje IP-naslovov vsebnikom v mostnih omrežjih, macvlan-ih itd. Z netavarkom se korenski vsebniki običajno privzeto povežejo z omrežjem, imenovanim »podman«, ki je povezano z mostom Linux (podman0) na gostitelju, z naslovom 10.88.0.0/16.

To privzeto mostno omrežje zagotavlja osnovno internetno povezljivost prek pravil SNAT in vam omogoča, da vrata vsebnika izpostavite gostitelju z uporabo `-po --publish`, ki ustvari pravila DNAT v iptables/nftables. Zaradi združljivosti z Dockerjem to omrežje ne izvaja notranjega strežnika DNS.

Ustvarimo lahko tudi uporabniško definirana mostna omrežja , ki izolirajo skupine kontejnerjev med seboj in zagotavljajo notranji DNS. To omogoča kontejnerjem, da se znotraj svojega zasebnega omrežja razrešujejo po imenu, olajša ločevanje storitev, ki se ne bi smele videti, in daje večji nadzor nad MTU, požarnimi zidovi in ​​drugimi funkcijami.

V naprednejših okoljih je mogoče uporabiti omrežja macvlan ali ipvlan za neposredno povezavo vsebnikov s fizičnim omrežjem gostitelja. Macvlan omogoča medsebojno komunikacijo vsebnikov, medtem ko jih ipvlan ponavadi bolj izolira; to so uporabne možnosti v uvajanjih, kjer mora preostali del omrežja vsak vsebnik videti kot pravega gostitelja.

Brezkorenska omrežja: slirp4netns in testenine

Ko uporabnik ni root, se stvari zapletejo: uporabnik brez privilegijev ne more prosto spreminjati imenskega prostora globalnega omrežja ali ustvarjati poljubnih vmesnikov, zato se mora Podman zateči k rešitvam uporabniškega prostora, da zagotovi povezljivost.

Tukaj pride na vrsto slirp4netns , klasičen mehanizem, ki ga uporablja Podman rootless . Ta projekt ustvari izolirano omrežno okolje znotraj vsebnika in uporablja modul slirp jedra za izvajanje prevajanja naslovov (NAT) in omogoča vsebniku dostop do interneta prek omrežja gostitelja.

V praksi slirp4netns ustvari vmesnik TAP znotraj omrežnega imenskega prostora vsebnika (na primer tap0 z IP 10.0.2.100 in prehodom 10.0.2.2) in usmerja promet prek sklada TCP/IP, implementiranega v uporabniškem prostoru. To je funkcionalno, vendar dodaja nekaj režijskih stroškov in določene omejitve.

Ena od teh omejitev je, da neprivilegirani uporabniki ne morejo uporabljati vrat pod 1024. Parameter sysctl net.ipv4.ip_unprivileged_port_start označuje, od katerih vrat veljajo za "neprivilegirane" (privzeto 1024), čeprav je to mogoče skrbno prilagoditi, če varnostni model to dovoljuje.

V Podmanu 5 je slirp4netns kot privzeti mehanizem brez root-a nadomeščen s pasto . Tudi Pasta deluje v celoti v uporabniškem prostoru, vendar zaradi vmesnika tap in tehnik zero-copy dosega skoraj izvorno omrežno zmogljivost, kar zmanjšuje vpliv na zakasnitev in prepustnost v primerjavi s slirp4netns.

Premostitvena in gostiteljska omrežja v vsebnikih brez korenskih povezav

Tudi ko delamo v nekorenskem načinu, lahko brezkorenske zabojnike povežemo s privzetim mostnim omrežjem »podman« z uporabo `--network=podman`. To izkorišča zmogljivosti netavarka in preslika vrata na gostitelja z `-p`, tako kot v korenskem načinu.

Uporabniško definirana mostna omrežja je mogoče ustvariti tudi v okoljih brez korenskega dostopa . V tem primeru mostovi in ​​povezane naprave niso ustvarjeni v gostiteljevem globalnem omrežnem imenskem prostoru, temveč v uporabnikovem imenskem prostoru, zato ti vmesniki ne bodo vidni z gostitelja s preprostim ukazom `sudo ip a`.

Za pregled teh mostov brez korenov Podman ponuja ukaz `podman unshare --rootless-netns` , ki odpre lupino v uporabnikovem omrežnem imenskem prostoru. Od tam je mogoče opazovati notranje mostove in preveriti neposredno povezljivost z vsebniki.

Ta izolacija ima nenavaden učinek: Morda ni neposredne povezave med gostiteljem in IP-ji teh vsebnikov brez korenskega dostopa.vendar deluje z vrati, preslikanimi na gostiteljev lasten IP-naslov, ki deluje kot vstopna točka za storitev.
Za komunikacijo med vsebniki strežnik DNS, integriran v uporabniško definirano mostno omrežje, omogoča, da se pogovarjajo po imenu, kar močno poenostavi konfiguracijo porazdeljenih aplikacij.

Na drugem koncu je gostiteljsko omrežje (--network=host) , kjer si vsebnik deli omrežni sklad z gostiteljem brez lastnega naslova IP. V tem načinu, če vsebnik brez root-a zažene strežnik na vratih 8080/tcp, bo storitev neposredno na voljo na vratih 8080 gostitelja, s čimer se prihrani preslikava vrat, vendar se zmanjša izolacija.

Podman Desktop, orodja za slikanje in lokalna orkestracija

Za tiste, ki imajo raje nekaj bolj vizualnega, Podman Desktop ponuja grafično okolje za upravljanje vsebnikov, podov, slik in omrežnih konfiguracij na razvojnih strojih, ki deluje kot neposredna alternativa Docker Desktopu, vendar se zanaša na mehanizem brez demonov.

Slike se pridobijo z uporabo ukaza `podman pull`, ki se prenese iz registrov, definiranih v `/etc/containers/registries.conf` . Če je slika določena brez imena registra, jo Podman poskuša najti v konfiguriranem vrstnem redu registra, pri čemer privzeto uporabi oznako `latest`.

Poleg vmesnika Podman CLI lahko skopeo uporabimo kot namensko orodje za upravljanje, pregledovanje in kopiranje slik med registri in lokalnimi repozitoriji. Ukazi, kot so kopiraj, izbriši in sinhroniziraj, nam omogočajo avtomatizacijo sinhronizacije med repozitoriji, označevanje slik za zbiranje smeti in premikanje artefaktov med okolji.

Ko je slika prenesena, vam ukaz `podman run` omogoča zagon vsebnikov z določitvijo transporta in poti (privzeto Docker transport in iskanje v konfiguriranem registru). Običajne možnosti (-d, -p, --name, --pod itd.) pokrivajo tako laboratorijske scenarije kot resnejše uvedbe.

Dnevno upravljanje se zaključi z ukazom `podman ps` za seznam vsebnikov, `podman stop/start` za zaustavitev ali zagon obstoječih primerkov in `podman rm` za odstranitev ustavljenih vsebnikov . Če je bil vsebnik spremenjen in ga želimo pretvoriti v novo sliko, `podman commit` shrani te spremembe pod novim imenom.

Podi in napredni izvedbeni modeli s Podmanom

Podman, ki ga je navdihnil Kubernetes, omogoča združevanje vsebnikov v pode, ki si delijo isti omrežni sklad in določene vire . To je odličen vzorec za stvari, kot so baza podatkov in njen odjemalec ali več mikroservisov, ki morajo komunicirati z nizko zakasnitvijo.

Ukaz `podman pod create` ustvari nov pod in vrne njegov ID, vendar pod privzeto ostane ustavljen, dokler se ne zažene povezan vsebnik ali dokler se izrecno ne zažene z `podman pod start`.

Če želite videti, kateri podi so v sistemu, uporabite ukaz `podman pod ls` , ki bo prikazal tudi vsebnik INFRA, povezan z vsakim od njih. Ta poseben vsebnik zagotavlja delovanje omrežja in drugih skupnih virov poda, zato število vsebnikov ni nikoli nič.

Podman ponuja specifične ukaze za zagon, zaustavitev ali ponovni zagon celotnih podov (podman pod start/stop/restart) , lahko pa delujemo tudi samo na določenem vsebniku znotraj poda, ne da bi spreminjali preostanek, s čimer ohranjamo izolacijo procesov na ravni aplikacije.

Če želite obstoječemu podu dodati več vsebnikov, uporabite `podman run --pod POD_NAME` , pri čemer upoštevajte isto sintakso kot za posamezne vsebnike. Vsebnika ne morete odstraniti iz poda, ne da bi ga uničili, saj je članstvo v podu vezano na njegov življenjski cikel.

Spremljanje se zaključi s podman ps –pod ali posebnimi ukazi za spremljanje procesov vseh vsebnikov v vseh podih , s čimer se hitro prepozna, kaj pripada kateri skupini in kako so storitve porazdeljene.

Kontejnerji, LXC in virtualizacija aplikacij

Čeprav Docker in Podman prevladujeta v pogovoru, nista edini možnosti za kontejnerizacijo v GNU/Linuxu . Rešitve, kot so LXC/LXD, systemd-nspawn in Kata Containers, obravnavajo problem z nekoliko drugačnih zornih kotov.

LXC ponuja zelo lahke sistemske vsebnike z lastnim imenom gostitelja, naslovom IP, datotečnim sistemom in popolnim sistemom init . V kombinaciji z LXD, ki deluje kot hipervizor za vsebnike in virtualne stroje, ponuja izkušnjo, ki je zelo podobna uporabi več lahkih strojev s skoraj golo zmogljivostjo.

Medtem ko se Docker/Podman osredotočata na vsebnike aplikacij, ki so skladni z OCI , se LXC izkaže za najbolj primernega, ko so potrebna trajna okolja z več storitvami in procesi, saj se obnaša kot virtualni stroj, vendar z manj režijskih stroškov in zelo naravno integracijo z jedrom Linuxa.

Z vidika zmogljivosti lahko LXC izvaja podatkovno intenzivne poslovne aplikacije praktično brez posledic , zaradi česar je zmogljiva izbira za delovne obremenitve, občutljive na zakasnitev, ki ne zahtevajo močne izolacije tradicionalnega virtualnega stroja.

Poleg tega so pridobile na veljavi tudi tehnologije, usmerjene v mikro virtualne stroje in izboljšano izolacijo, kot sta Kata Containers , ki vsak pod zažene znotraj majhnega virtualnega stroja z lastnim jedrom, ali gVisor, ki med aplikacijo in Linux vstavi »peskovnik jedra«, napisan v jeziku Go. Obe zmanjšujeta odvisnost od skupnega jedra in se približujeta varnostnemu modelu virtualnih strojev, hkrati pa ohranjata uporabniku prijaznost vsebnikov.

Najboljše prakse za utrjevanje Dockerja in Podmana

Glede na vse zgoraj navedeno je razumen pristop k robustni platformi kontejnerjev delo v plasteh: segmentacija z imenskimi prostori/kontrolnimi skupinami, filtriranje pravilnikov s seccomp in MAC ter strukturna omejitev privilegijev prek rootless načina.

V praksi je priporočljivo, da se po možnosti uvede standardna praksa zagona vsebnikov v nekorenskem načinu , zlasti v večnajemniških okoljih ali znotraj skupnih oblakov. Podman to privzeto omogoča, Docker rootless pa pokriva isto filozofijo, kadar je potrebna združljivost.

Jedro gostitelja mora biti posodobljeno z varnostnimi popravki . Ranljivosti, kot so Dirty COW, Dirty Pipe in druge, so odpravljene s posodobitvami, ki jih je treba namestiti relativno hitro, če ne želimo pustiti odprtih vrat za pobeg vsebnikov.

Drug zelo učinkovit ukrep je uporaba nespremenljivih, na vsebnike usmerjenih distribucij, kot sta openSUSE MicroOS ali Flatcar Linux . Njihov sistem posodabljanja samo za branje (root) in atomski sistem posodabljanja močno zmanjšata površino za napad in olajšata vračanje prejšnjih nastavitev, če gre po popravku kaj narobe.

Glede konfiguracije: v produkciji ni privilegiranih vsebnikov, razen v izjemno nadzorovanih primerih , aplikacij ne izvajajte kot root znotraj vsebnika, kadar koli je to mogoče, uporabljajte datotečne sisteme samo za branje in omejite zmogljivosti na najmanjšo možno mero. Profili SELinux/AppArmor in seccomp, prilagojeni dejanskim klicem aplikacije, so praktično obvezni.

Nenazadnje ne smemo pozabiti na vidik spremljanja med izvajanjem . Orodja, kot so Falco, Sysdig Secure ali Aqua, pomagajo odkriti anomalije, poskuse pobega (kot so nenavaden dostop do /proc ali /sys), netipičen omrežni promet ali sumljive ukaze, kar zagotavlja čas za odziv, preden se napad razširi.

Z združevanjem klasične virtualizacije s KVM, vsebniki, ki jih upravlja Podman (po možnosti v načinu brez root-a), dobro segmentiranimi omrežji in dobrimi praksami utrjevanja je mogoče zgraditi zelo prilagodljivo in precej varno platformo za virtualizacijo. Razumevanje, da je skupno jedro najpomembnejša točka, zanašanje na virtualne stroje ali mikro virtualne stroje, kadar to zahtevajo tveganja ali skladnost s predpisi, in skrbno upravljanje dobavne verige slik predstavlja razliko med laboratorijskim okoljem in infrastrukturo, pripravljeno za produkcijo.