Podman, KVM i kontejneri: praktični vodič za sigurnu virtualizaciju

Informatec Digital » Resursi » Podman, KVM i kontejneri: praktični vodič za sigurnu virtualizaciju

Kada počnete postavljati ozbiljno kontejnersko okruženje na Linuxu, odmah se postavlja isto pitanje: u kojoj mjeri je sigurno oslanjati se isključivo na kontejnere i kada je preporučljivo nadograditi na KVM ili mikro-VM-ove? U korporativnim okruženjima, gdje su Docker, Podman, LXC, KVM virtualne mašine i razni hipervizori pomiješani zajedno, dobro razumijevanje modela izolacije ključno je za izbjegavanje grešaka.

Nadalje, donekle složeni scenariji nisu neuobičajeni, poput pokušaja korištenja Docker Desktopa ili Podmana unutar virtualne mašine u VirtualBoxu ili KVM-u , gdje dolazi do izražaja nekoliko nivoa virtualizacije (ugniježđenih ili ne), i lako je naići na greške poput "KVM nije omogućen na hostu". Organizirajmo sve ove dijelove - kontejnere, VM-ove, Podman, KVM, umrežavanje i sigurnost - i pogledajmo kako ih kombinirati da bismo postigli zaista sigurnu i praktičnu virtualizaciju.

Klasična virtualizacija sa KVM-om i virtuelnim mašinama

Temelj cijele ove postavke ostaje potpuna virtualizacija operativnih sistema korištenjem hipervizora kao što su KVM, Xen ili ESXi . Ovdje fizički hardver pokreće hipervizor koji je odgovoran za "dijeljenje" mašine na nekoliko nezavisnih virtuelnih mašina.

U ovom modelu, svaka virtuelna mašina pokreće vlastito jezgro i gostujući operativni sistem , potpuno odvojeno od hosta. Hipervizor (na primjer, KVM, integriran u Linux jezgro) djeluje kao čuvar vrata između hardvera i virtuelnih mašina i odgovoran je za snažnu izolaciju između njih.

Generalno govorimo o dvije vrste hipervizora: hipervizori tipa 1 ili hipervizori bez operativnog sistema, koji se pokreću direktno na hardveru, i hipervizori tipa 2, koji se hostuju na postojećem operativnom sistemu. VirtualBox ili VMware Workstation bi bili tip 2 , dok je KVM kojim upravlja libvirt na Linux serveru bliži scenariju tipa 1, iako dijeli prostor sa samim hostom.

Najveća prednost ovog pristupa je što svaka virtuelna mašina ima svoj kompletan stek: kernel, korisnički prostor, servise, mrežu i pohranu . Ovo pruža veliku fleksibilnost i mogućnost pokretanja različitih operativnih sistema i verzija kernela na istoj fizičkoj mašini.

Za upravljanje ovim virtualiziranim platformama u GNU/Linuxu, libvirt se gotovo uvijek koristi kao orkestracijski API , pored kojeg su podržani grafički alati i alati komandne linije, ili veći projekti poput OpenStacka, koji gradi kompletne oblake kombinirajući virtualne mašine, bare metal i kontejnere.

Hardverski zahtjevi i uobičajeni problemi s KVM-om

Prije pokretanja KVM-a ili korištenja rješenja koja ovise o njemu (kao što su neke Docker Desktop ili micro-VM konfiguracije), morate se uvjeriti da procesor podržava virtualizaciju hardvera (VT-x na Intelu ili SVM/AMD-V na AMD-u) i da je omogućena u BIOS-u/UEFI-ju.

U Linuxu imamo brzu provjeru: ako naredba `grep -E 'svm|vmx' /proc/cpuinfo` ne vrati ništa ili je opcija i dalje onemogućena u firmveru, KVM neće raditi. Nadalje, u scenarijima gdje ćemo pokretati VM-ove unutar drugog VM-a (ugniježđena virtualizacija), hipervizor najvišeg nivoa mora eksplicitno izložiti ta proširenja gostu.

Kada nešto krene po zlu, pojavljuju se tipične poruke, poput zloglasnog Docker Desktop iskačućeg prozora u RHEL-u 9 unutar VirtualBoxa: „KVM nije omogućen na hostu .“ Problem ovdje nije direktno u Dockeru ili RHEL-u, već u tome što VirtualBox VM ne prima potrebna proširenja virtualizacije za pokretanje KVM-a unutar njega.

Komande poput `modprobe kvm` ili `modprobe kvm_amd / kvm_intel` trebale bi učitati kernel module bez poruka o grešci. Ako `dmesg` ne prikazuje ništa relevantno ili `lsmod | grep kvm` prikazuje samo `kvm` i `irqbypass`, a nedostaju moduli specifični za CPU, vrlo je vjerovatno da virtualizacija hardvera nije dostupna gostujućem sistemu ili je onemogućena u firmveru.

U ovim scenarijima, čak i ako su sve moguće funkcije omogućene unutar gosta, ako VirtualBox ne nudi ugniježđenu virtualizaciju ili je pogrešno konfiguriran, KVM jednostavno neće raditi . Rješenje uključuje pregled konfiguracije hipervizora hosta (VirtualBox, VMware, itd.) i omogućavanje ugniježđene virtualizacije ako je dostupna.

Kontejneri: lagana virtualizacija na nivou operativnog sistema

Za razliku od tradicionalnih virtuelnih mašina, kontejneri nude drugačiji pristup: oni ne emuliraju sav hardver, već ponovo koriste jezgro hosta i izoluju procese i resurse koristeći funkcije Linux jezgra.

Kontejner je u suštini skup procesa enkapsuliranih pomoću imenskih prostora i c-grupa . Unutar ovog "okruženja", aplikacija vjeruje da se izvršava na vlastitoj mašini, sa vlastitim datotečnim sistemom, mrežnim interfejsima i PID-ovima, ali u stvarnosti dijeli kernel sa hostom.

Kontejneri nude gotovo nativne performanse jer nema drugog kernela niti potpune emulacije hardvera . Opterećenje je minimalno: tek toliko da se montiraju imenski prostori, ograniče resursi pomoću cgrupa i sprovode sigurnosne politike (seccomp, AppArmor, SELinux, itd.).

Međutim, ovaj dizajn ima značajnu posljedicu: sva radna opterećenja dijele isto fizičko jezgro . Ozbiljna ranjivost u tom jezgru može iznenada postati potencijalni vektor bijega za sve kontejnere koji rade na tom čvoru.

Zato se često kaže da izolacija kontejnera nije "apsolutna" kao kod virtuelne mašine . Ako neko uspije da iskoristi kritičnu grešku u kernelu, imenski prostori prestaju da budu efikasna barijera, a granice između kontejnera i hostova mogu biti probijene.

Imenski prostori i c-grupe: osnova izolacije kontejnera

U Linuxu, izolacija kontejnera je izgrađena na dva glavna stuba: imenskim prostorima za odvajanje sistemskih prikaza i kontrolnim grupama za ograničavanje i obračun resursa.

Imenski prostori izoluju stvari poput PID-ova, mreže, tačaka montiranja, IPC-a, imena hosta (UTS) i korisnika . Na ovaj način, proces "vidi" samo procese, mrežne interfejse, datotečni sistem i ime hosta svog vlastitog imenskog prostora, dajući mu osjećaj da je na drugom sistemu.

Sa svoje strane, cgroups vam omogućavaju da odredite koliko CPU-a, memorije, diskovnog I/O-a, broja procesa itd. kontejner može potrošiti . Ovo sprečava da nekontrolisano opterećenje preoptereti cijeli host, što je ključno prilikom dijeljenja čvorova između timova ili projekata.

Međutim, ključno je shvatiti da sami imenski prostori i kontrolne grupe nisu potpun sigurnosni sistem . Oni ne sprječavaju iskorištavanje ranjivosti kernela, ne filtriraju sistemske pozive niti upravljaju detaljnim politikama pristupa. Oni su temelj, ali ih je potrebno ojačati.

Razuman način za jačanje okruženja je kombinovanje sistemskih poziva (syscall filtera) sa seccomp-om, MAC politikama (AppArmor ili SELinux) i drastičnim smanjenjem mogućnosti procesa, idealno uz korisničke imenske prostore i rootless način rada kako bi se minimizirala šteta ako neko uspije da pobjegne iz kontejnera.

Sigurnosne prijetnje na kontejnerskim platformama

U stvarnoj kontejnerskoj platformi, površina napada je raspoređena na nekoliko slojeva: kernel i runtime (runc, container, CRI-O), lanac snabdijevanja slikama, konfiguracija kontejnera/orkestratora i osnovna infrastruktura (oblak, pohrana, IAM, mreža).

Uobičajeni vektori napada uključuju softverske ranjivosti u kernelu ili okruženju za izvršavanje kontejnera, korištenje nesigurnih ili neodržavanih slika, pravljenje konfiguracijskih grešaka u Kubernetes-u ili Docker-u (privilegovani kontejneri, opasna montiranja hosta, pretjerano otvoreni mrežni režimi) i sigurnosne propuste u registrima ili CI/CD cjevovodima.

U mnogim incidentima iz stvarnog svijeta, ne postoji jedan "magični bag", već kombinacija poznate ranjivosti i loše konfiguracije : kontejneri se pokreću kao root, korištenje zastavice --privileged, montiranje host datotečnog sistema unutar kontejnera i odsustvo seccomp-a ili MAC-a.

Svemu ovome se dodaje i problem lanca snabdijevanja: javne slike često sadrže CVE-ove, zastarjele pakete i loše kontrolirane zavisnosti . Relativno je lako da se zlonamjerni softver provuče ili da kompromitovana biblioteka ostane neaktivna dok se ne steknu uslovi za njeno izvršavanje.

Stoga, u produkciji to nije opcionalno: morate skenirati slike na ranjivosti pomoću alata poput Trivy, Clair ili Grype , kontrolirati koji se registri koriste (Harbor, Quay, GHCR s pravilima) i potpisati/provjeriti slike prije nego što ih instalirate u klaster.

Docker vs Podman: Utjecaj na model prijetnji

U svijetu kontejnera aplikacija, Docker i Podman pokrivaju slične funkcije, ali njihova arhitektura se znatno razlikuje, a to mijenja sigurnosni model s kojim radimo na hostu.

Docker, u svom klasičnom root modu, oslanja se na centralni daemon (dockerd) koji se pokreće kao root . CLI komunicira s ovim daemonom putem /var/run/docker.sock ili putem TCP-a, i upravo taj privilegirani proces kreira i uništava kontejnere, upravlja slikama, mrežama i volumenima, te komunicira s registrima.

To znači da svako ko ima pristup Docker socketu praktično ima root pristup hostu , jer može pokretati privilegovane kontejnere, montirati proizvoljne datotečne sisteme i mijenjati kritičnu konfiguraciju. Daemon efektivno postaje jedinstvena tačka otkaza.

S druge strane, Podman je rođen s idejom da bude kontejnerski mehanizam bez demona koji je što više "izvorniji" Linuxu . Ne postoji trajni centralni proces; kontejnerima upravlja korisnik ili systemd, a integracija s ovim potonjim omogućava kontrolu kontejnera putem servisnih jedinica.

Ovaj pristup se bolje poklapa sa Unix modelom "svaki proces pripada korisniku koji ga pokreće" i izbjegava oslanjanje na daemon sa visokim privilegijama . Nadalje, Podman nudi kompatibilnost sa Docker naredbama, pojednostavljujući migraciju (možete čak i koristiti alias `docker=podman` u okruženjima gdje ne želite instalirati Docker CE).

Rootless način rada i korisnički imenski prostori

Jedan od glavnih praktičnih napredaka u smanjenju utjecaja potencijalnog izlaza iz kontejnera je rootless način rada u kombinaciji s korisničkim imenskim prostorima . Pitanje na koje se ovim pokušava odgovoriti je: "Šta se događa ako kontejner ipak izađe iz sistema?"

Korisnički imenski prostori vam omogućavaju da premirate UID kontejnera 0 na neprivilegovani UID na hostu . Drugim riječima, unutar kontejnera aplikacija vjeruje da je root, ali iz perspektive hosta, taj proces je zapravo običan korisnik sa dodijeljenim rasponom subuid/subgid.

Na ovaj način, čak i ako napadač dobije root privilegije unutar kontejnera i uspije povezati kernel ili runtime exploit, po povratku na host to čini kao neprivilegovani korisnik . Ne može prepisati root binarne datoteke, montirati osjetljive datotečne sisteme ili manipulisati uređajima na kojima nema potrebne privilegije.

Podman je od početka dizajniran imajući na umu ovaj model: kontejnerizacija bez roota po defaultu kad god je to moguće , korištenje SELinux/AppArmor-a i cgroups čak i bez roota, te snažan naglasak na minimiziranju strukturnih privilegija.

Docker sada nudi i pravi root-less način rada , gdje se dockerd i kontejneri nalaze unutar korisničkog imenskog prostora, za razliku od starijeg userns-remap-a gdje je daemon ostao root. Sa sigurnosne tačke gledišta, ovo sprečava da exploit protiv dockerda automatski odobri root pristup hostu.

Kontejnerske mreže s Podmanom: bridge, host, macvlan i rootless interfejsi

Još jedan važan element za sigurnost i praktično funkcionisanje je sloj kontejnerske mreže . Podman nudi različite mehanizme za obezbjeđivanje povezivosti, s posebnom pažnjom na scenarije bez pristupa root-u.

Podman 4 je predstavio netavark, mrežni drajver koji prati CNI model kako bi kontejnerima pružio IP adrese na bridge mrežama, macvlan-ovima itd. S netavarkom, root kontejneri se obično podrazumijevano povezuju na mrežu pod nazivom "podman" povezanu s Linux bridgeom (podman0) na hostu, s adresom 10.88.0.0/16.

Ova zadana mostna mreža pruža osnovnu internetsku povezivost putem SNAT pravila i omogućava vam da izložite kontejnerske portove hostu koristeći `-po --publish`, što generira DNAT pravila u iptables/nftables. Radi kompatibilnosti s Dockerom, ova mreža ne koristi interni DNS server.

Također možemo kreirati korisnički definirane mostne mreže , koje izoliraju grupe kontejnera jedne od drugih i pružaju interni DNS. Ovo omogućava kontejnerima da se razlučuju po imenu unutar svoje privatne mreže, olakšava odvajanje servisa koji ne bi trebali moći vidjeti jedan drugog i daje veću kontrolu nad MTU-om, zaštitnim zidovima i drugim funkcijama.

U naprednijim okruženjima, moguće je koristiti macvlan ili ipvlan mreže za direktno povezivanje kontejnera sa fizičkom mrežom hosta. Macvlan omogućava kontejnerima da međusobno komuniciraju, dok ipvlan teži da ih više izoluje; ovo su korisne opcije u implementacijama gdje ostatak mreže treba da vidi svaki kontejner kao pravi host.

Rootless mreže: slirp4netns i pasta

Kada korisnik nije root, stvari se komplikuju: korisnik bez privilegija ne može slobodno mijenjati globalni mrežni imenski prostor ili kreirati proizvoljne interfejse, pa Podman mora pribjeći rješenjima korisničkog prostora kako bi osigurao povezanost.

Tu nastupa slirp4netns , klasični mehanizam koji koristi Podman rootless . Ovaj projekat stvara izolovano mrežno okruženje unutar kontejnera i koristi kernelov slirp modul za izvođenje prevođenja adresa (NAT) i omogućavanje kontejneru pristup internetu putem mreže hosta.

U praksi, slirp4netns kreira TAP interfejs unutar imenskog prostora mreže kontejnera (na primjer, tap0 sa IP adresom 10.0.2.100 i gateway-om 10.0.2.2) i usmjerava promet putem TCP/IP steka implementiranog u korisničkom prostoru. Funkcionalno je, ali dodaje neke opterećenja i određena ograničenja.

Jedno od ovih ograničenja je da neprivilegovani korisnici ne mogu koristiti portove ispod 1024. Parametar sysctl-a net.ipv4.ip_unprivileged_port_start označava od kojeg porta se smatraju "neprivilegovanim" (podrazumevano, 1024), iako se ovo može pažljivo podesiti ako sigurnosni model to dozvoljava.

U Podmanu 5, slirp4netns je zamijenjen pastom kao zadanim mehanizmom bez roota . Pasta također radi u potpunosti u korisničkom prostoru, ali zahvaljujući tap interfejsu i tehnikama nulte kopije, postiže gotovo nativne mrežne performanse, smanjujući utjecaj na latenciju i propusnost u usporedbi sa slirp4netns.

Mreže za premošćivanje i hostovanje u kontejnerima bez roota

Čak i kada radimo u ne-root modu, možemo povezati rootless kontejnere na zadanu "podman" bridge mrežu koristeći `--network=podman`. Ovo koristi prednosti netavark-ovih mogućnosti i mapira portove na host sa `-p`, baš kao u root modu.

Također je moguće kreirati korisnički definirane mostne mreže u okruženjima bez root-a . U ovom slučaju, mostovi i pridruženi uređaji se ne kreiraju u globalnom mrežnom imenskom prostoru hosta, već u korisničkom imenskom prostoru, tako da ovi interfejsi neće biti vidljivi s hosta jednostavnom naredbom `sudo ip a`.

Za pregled ovih rootless mostova, Podman nudi naredbu `podman unshare --rootless-netns` , koja otvara ljusku u korisničkom mrežnom imenskom prostoru. Odatle se mogu posmatrati interni mostovi i provjeriti direktna povezanost s kontejnerima.

Ova izolacija ima neobičan efekat: Možda ne postoji direktna povezanost od hosta do IP adresa tih root-less kontejnera.ali radi s portovima mapiranim na IP adresu samog hosta, koji djeluju kao ulazna tačka za servis.
Za komunikaciju između kontejnera, DNS server integriran u korisnički definiranu mostnu mrežu im omogućava da se koriste imenom, što znatno pojednostavljuje konfiguraciju distribuiranih aplikacija.

Na drugom kraju je mreža hosta (--network=host) , gdje kontejner dijeli mrežni stek s hostom bez vlastite IP adrese. U ovom načinu rada, ako kontejner bez root-a pokrene server na portu 8080/tcp, usluga će biti direktno dostupna na portu 8080 hosta, čime se štedi mapiranje portova, ali smanjuje izolacija.

Podman Desktop, alati za obradu slika i lokalna orkestracija

Za one koji preferiraju nešto vizualnije, Podman Desktop pruža grafičko okruženje za upravljanje kontejnerima, podovima, slikama i mrežnim konfiguracijama na razvojnim mašinama, djelujući kao direktna alternativa Docker Desktopu, ali se oslanjajući na daemonless engine.

Slike se dobijaju korištenjem naredbe `podman pull`, koja preuzima iz registara definiranih u `/etc/containers/registries.conf` . Ako je slika navedena bez naziva registra, Podman pokušava da je pronađe unutar konfiguriranog redoslijeda registra, koristeći oznaku `latest` prema zadanim postavkama.

Pored Podman CLI-ja, možemo koristiti skopeo kao namjenski alat za upravljanje, pregled i kopiranje slika između registara i lokalnih repozitorija. Naredbe poput kopiranja, brisanja i sinhronizacije omogućavaju nam automatizaciju sinhronizacije između repozitorija, označavanje slika za sakupljanje smeća i premještanje artefakata između okruženja.

Nakon što se slika preuzme, `podman run` vam omogućava pokretanje kontejnera određivanjem transporta i putanje (podrazumevano, Docker transport i pretraživanje u konfigurisanom registru). Uobičajene opcije (-d, -p, --name, --pod, itd.) pokrivaju i laboratorijske scenarije i ozbiljnije implementacije.

Dnevno upravljanje se obavlja pomoću `podman ps` za listanje kontejnera, `podman stop/start` za zaustavljanje ili pokretanje postojećih instanci i `podman rm` za uklanjanje zaustavljenih kontejnera . Ako je kontejner modificiran i želimo ga pretvoriti u novu sliku, `podman commit` sprema te promjene pod novim imenom.

Podovi i napredni modeli izvršenja sa Podmanom

Inspirisan Kubernetes-om, Podman vam omogućava grupisanje kontejnera u podove koji dijele isti mrežni stek i određene resurse . To je savršen obrazac za stvari poput baze podataka i njenog klijenta ili više mikroservisa koji trebaju komunicirati s malom latencijom.

Naredba `podman pod create` kreira novi pod i vraća njegov ID, ali pod po defaultu ostaje zaustavljen dok se ne pokrene pridruženi kontejner ili se eksplicitno ne pokrene sa `podman pod start`.

Da biste vidjeli koji se podovi nalaze na sistemu, koristite naredbu `podman pod ls` , koja će također prikazati INFRA kontejner povezan sa svakim od njih. Ovaj poseban kontejner održava mrežu i druge dijeljene resurse poda u radu, tako da broj kontejnera nikada nije nula.

Podman nudi specifične naredbe za pokretanje, zaustavljanje ili ponovno pokretanje cijelih podova (podman pod start/stop/restart) , ali također možemo djelovati samo na određeni kontejner unutar poda bez mijenjanja ostatka, održavajući izolaciju procesa na nivou aplikacije.

Da biste dodali više kontejnera postojećem podu, koristite `podman run --pod POD_NAME` , slijedeći istu sintaksu kao i za pojedinačne kontejnere. Ne možete ukloniti kontejner iz poda bez njegovog uništavanja, jer je članstvo u podu vezano za njegov životni ciklus.

Praćenje se završava pomoću podman ps –pod ili specifičnih naredbi za praćenje procesa svih kontejnera u svim podovima , brzo identifikujući šta pripada kojoj grupi i kako su servisi distribuirani.

Kontejneri, LXC i virtualizacija aplikacija

Iako Docker i Podman dominiraju razgovorom, oni nisu jedine opcije kontejnerizacije u GNU/Linuxu . Rješenja poput LXC/LXD, systemd-nspawn i Kata Containers rješavaju problem iz malo drugačijih uglova.

LXC pruža vrlo lagane sistemske kontejnere, sa vlastitim imenom hosta, IP adresom, datotečnim sistemom i kompletnim init sistemom . U kombinaciji sa LXD-om, koji djeluje kao hipervizor za kontejnere i virtuelne mašine, pruža iskustvo vrlo blisko posjedovanju više laganih mašina sa gotovo potpuno osnovnim performansama.

Dok se Docker/Podman fokusiraju na OCI-kompatibilne kontejnere aplikacija , LXC se ističe kada su potrebna perzistentna okruženja s više servisa i procesa, ponašajući se kao VM, ali s manje opterećenja i vrlo prirodnom integracijom s Linux kernelom.

Sa stanovišta performansi, LXC može pokretati poslovne aplikacije koje intenzivno koriste podatke praktično bez ikakvih problema , što ga čini moćnim izborom za radna opterećenja osjetljiva na latenciju koja ne zahtijevaju snažnu izolaciju tradicionalne virtuelne mašine.

Uz ovo, tehnologije usmjerene ka mikro-VM-ovima i poboljšanoj izolaciji također su dobile na popularnosti, kao što su Kata Containers , koji pokreće svaki pod unutar male virtualne mašine sa svojim vlastitim kernelom, ili gVisor, koji ubacuje "kernel sandbox" napisan u Go-u između aplikacije i Linuxa. Obje smanjuju ovisnost o dijeljenom kernelu i približavaju se sigurnosnom modelu VM-ova, a istovremeno održavaju jednostavnost korištenja kontejnera.

Najbolje prakse za jačanje Dockera i Podmana

Uzimajući u obzir sve navedeno, razuman pristup robusnoj kontejnerskoj platformi je rad u slojevima: segmentacija s imenskim prostorima/cgrupama, politike filtriranja sa seccomp i MAC, te strukturno ograničavanje privilegija putem rootless moda.

U praksi je preporučljivo usvojiti standardnu ​​praksu pokretanja kontejnera u ne-root modu kad god je to moguće , posebno u okruženjima s više zakupaca ili unutar dijeljenih oblaka. Podman to omogućava po defaultu, a Docker rootless pokriva istu filozofiju kada je potrebna kompatibilnost.

Jezgro hosta mora biti ažurirano sigurnosnim zakrpama . Ranjivosti poput Dirty COW, Dirty Pipe i drugih rješavaju se ažuriranjima koja se moraju primijeniti relativno brzo ako ne želimo ostaviti vrata otvorena za izlaze iz kontejnera.

Još jedna vrlo efikasna mjera je korištenje nepromjenjivih, kontejnerski orijentiranih distribucija, kao što su openSUSE MicroOS ili Flatcar Linux . Njihov sistem samo za čitanje root i atomski sistem ažuriranja uveliko smanjuju površinu napada i olakšavaju vraćanje na prethodno stanje ako nešto krene po zlu nakon zakrpe.

Što se tiče konfiguracije: nema privilegovanih kontejnera u produkciji osim u izuzetno kontrolisanim slučajevima , ne pokretati aplikacije kao root unutar kontejnera, koristiti datotečne sisteme samo za čitanje kad god je to moguće i ograničiti mogućnosti na minimum. SELinux/AppArmor i seccomp profili prilagođeni stvarnim pozivima aplikacije su praktično obavezni.

Konačno, ne smijemo zaboraviti aspekt praćenja tokom izvođenja napada . Alati poput Falco, Sysdig Secure ili Aqua pomažu u otkrivanju anomalija, pokušaja bijega (kao što je neobičan pristup /proc ili /sys), atipičnog mrežnog prometa ili sumnjivih naredbi, pružajući vrijeme za reakciju prije nego što napad uzme maha.

Kombiniranjem klasične virtualizacije s KVM-om, kontejnerima kojima upravlja Podman (po mogućnosti u rootless modu), dobro segmentiranim mrežama i robusnim praksama osiguranja, može se izgraditi vrlo fleksibilna i prilično sigurna platforma za virtualizaciju. Razumijevanje da je dijeljeni kernel najkritičnija tačka, oslanjanje na VM-ove ili mikro-VM-ove kada to zahtijeva rizik ili usklađenost s propisima, te pažljivo upravljanje lancem snabdijevanja slikama čini svu razliku između laboratorijskog okruženja i infrastrukture spremne za produkciju.