„Podman“, KVM ir konteineriai: praktinis vadovas, kaip saugiai virtualizuoti

Informatec Digital » Ištekliai » „Podman“, KVM ir konteineriai: praktinis vadovas, kaip saugiai virtualizuoti

Pradėjus kurti rimtą konteinerių aplinką „Linux“ sistemoje, iš karto kyla tas pats klausimas: kiek saugu pasikliauti vien konteineriais, o kada patartina pereiti prie KVM arba mikrovirtualių mašinų? Įmonių aplinkoje, kur kartu naudojamos „Docker“, „Podman“, LXC, KVM virtualios mašinos ir įvairūs hipervizoriai, norint išvengti klaidų, labai svarbu gerai suprasti izoliacijos modelį.

Be to, gana sudėtingi scenarijai nėra reti, pavyzdžiui, bandymas naudoti „Docker Desktop“ arba „Podman“ virtualioje mašinoje „VirtualBox“ arba KVM aplinkoje , kur veikia keli virtualizacijos lygiai (įterptieji arba ne), ir lengva susidurti su klaidomis, tokiomis kaip „KVM neįgalintas pagrindiniame kompiuteryje“. Sutvarkykime visus šiuos elementus – konteinerius, virtualias mašinas, „Podman“, KVM, tinklus ir saugumą – ir pažiūrėkime, kaip juos sujungti, kad virtualizacija būtų tikrai saugi ir praktiška.

Klasikinė virtualizacija su KVM ir virtualiomis mašinomis

Visos šios sistemos pagrindas išlieka visiškas operacinių sistemų virtualizavimas naudojant hipervizorius, tokius kaip KVM, Xen arba ESXi . Čia fizinė įranga paleidžia hipervizorių, kuris yra atsakingas už mašinos „padalijimą“ į kelias nepriklausomas virtualias mašinas.

Šiame modelyje kiekviena virtuali mašina paleidžia savo branduolį ir svečio operacinę sistemą , visiškai atskirai nuo pagrindinio kompiuterio. Hipervizorius (pavyzdžiui, KVM, integruotas į „Linux“ branduolį) veikia kaip vartų sargas tarp aparatinės įrangos ir virtualių mašinų ir yra atsakingas už tvirtą jų izoliaciją.

Paprastai kalbame apie dviejų tipų hipervizorius: 1 tipo arba „bare metal“ hipervizorius, kurie veikia tiesiogiai aparatinėje įrangoje, ir 2 tipo hipervizorius, talpinamus esamos operacinės sistemos viršuje. „VirtualBox“ arba „VMware Workstation“ būtų 2 tipo , o KVM, valdomas „libvirt“ „Linux“ serveryje, yra artimesnis 1 tipo scenarijui, net jei jis dalijasi erdve su pačiu pagrindiniu kompiuteriu.

Didžiausias šio metodo privalumas yra tas, kad kiekviena virtualioji mašina turi savo atskirą steko sistemą: branduolį, vartotojų erdvę, paslaugas, tinklą ir saugyklą . Tai suteikia daug lankstumo ir galimybę paleisti skirtingas operacines sistemas ir branduolio versijas tame pačiame fiziniame kompiuteryje.

Šioms virtualizuotoms platformoms valdyti GNU/Linux sistemoje „libvirt“ beveik visada naudojama kaip orkestravimo API , ant kurios palaikomos grafinės ir komandinės eilutės priemonės, arba didesni projektai, tokie kaip „OpenStack“, kuris kuria ištisus debesis, derindamas virtualias mašinas, virtualią erdvę ir konteinerius.

Aparatinės įrangos reikalavimai ir dažniausios KVM problemos

Prieš paleisdami KVM arba naudodami nuo jo priklausomus sprendimus (pvz., kai kurias „Docker Desktop“ arba mikro-VM konfigūracijas), turite įsitikinti, kad procesorius palaiko aparatinės įrangos virtualizaciją („VT-x“ „Intel“ sistemoje arba SVM/AMD-V „AMD“ sistemoje) ir kad ji įjungta BIOS/UEFI.

„Linux“ sistemoje turime greitą patikrinimą: jei komanda `grep -E 'svm|vmx' /proc/cpuinfo` negrąžina nieko arba ši parinktis vis dar išjungta programinėje įrangoje, KVM neveiks. Be to, tais atvejais, kai virtualios mašinos bus paleistos kitos virtualios mašinos viduje (įdėtoji virtualizacija), aukščiausio lygio hipervizorius turi aiškiai parodyti šiuos plėtinius svečiui.

Kai kas nors negerai, pasirodo tipiniai pranešimai, pavyzdžiui, liūdnai pagarsėjęs „Docker Desktop“ iššokantis langas RHEL 9 sistemoje „VirtualBox“ viduje: „KVM neįjungtas pagrindiniame kompiuteryje “. Problema čia ne tiesiogiai susijusi su „Docker“ ar RHEL, o su tuo, kad „VirtualBox“ virtualioji mašina negauna reikiamų virtualizacijos plėtinių, kad joje paleistų KVM.

Tokios komandos kaip `modprobe kvm` arba `modprobe kvm_amd / kvm_intel` turėtų įkelti branduolio modulius be klaidų pranešimų. Jei `dmesg` nerodo nieko reikšmingo arba `lsmod | grep kvm` rodo tik gryną `kvm` ir `irqbypass`, o procesoriui būdingų modulių nėra, labai tikėtina, kad aparatinės įrangos virtualizavimas nėra pasiekiamas svečio sistemai arba yra išjungtas programinėje įrangoje.

Tokiais atvejais, net jei svečio aplinkoje įjungtos visos įmanomos funkcijos, jei „VirtualBox“ nesiūlo įdėtosios virtualizacijos arba ji yra neteisingai sukonfigūruota, KVM tiesiog neveiks . Sprendimas apima pagrindinio hipervizoriaus konfigūracijos peržiūrą („VirtualBox“, „VMware“ ir kt.) ir įjungtą įdėtąją virtualizaciją, jei ji yra.

Konteineriai: lengva virtualizacija operacinės sistemos lygmeniu

Skirtingai nuo tradicinių virtualių mašinų, konteineriai siūlo kitokį požiūrį: jie neimuliuoja visos aparatinės įrangos, o pakartotinai naudoja pagrindinį branduolį ir izoliuoja procesus bei išteklius naudodami „Linux“ branduolio funkcijas.

Konteineris iš esmės yra procesų rinkinys, įkapsuliuotas naudojant vardų erdves ir cgroups . Šioje „aplinkoje“ programa mano, kad veikia savo kompiuteryje su savo failų sistema, tinklo sąsajomis ir PID, tačiau iš tikrųjų ji dalijasi branduoliu su pagrindiniu kompiuteriu.

Konteineriai pasižymi beveik natyviu našumu, nes juose nėra antro branduolio ir nėra visiškos aparatinės įrangos emuliacijos . Pridėtinės išlaidos yra minimalios: tik tiek, kiek pakanka vardų erdvėms prijungti, ištekliams apriboti naudojant „cgroups“ ir saugumo politikoms („seccomp“, „AppArmor“, „SELinux“ ir kt.) įgyvendinti.

Tačiau šis dizainas turi reikšmingą pasekmę: visos darbo krūvio apkrovos naudoja tą patį fizinį branduolį . Rimtas to branduolio pažeidžiamumas gali staiga tapti potencialiu pabėgimo vektoriumi visiems tame mazge veikiantiems konteineriams.

Todėl dažnai sakoma, kad konteinerių izoliacija nėra „absoliuti“ kaip virtualios mašinos . Jei kam nors pavyksta išnaudoti kritinę branduolio klaidą, vardų erdvės nustoja būti veiksminga kliūtimi, o ribos tarp konteinerių ir pagrindinių kompiuterių gali būti panaikintos.

Vardų erdvės ir cgroups: konteinerių izoliacijos pagrindas

„Linux“ sistemoje konteinerių izoliacija grindžiama dviem pagrindiniais ramsčiais: vardų erdvėmis, skirtomis atskirti sistemos rodinius , ir cgroups, skirtomis apriboti ir apskaityti išteklius.

Vardų erdvės izoliuoja tokius dalykus kaip PID, tinklas, prijungimo taškai, IPC, pagrindinio kompiuterio pavadinimas (UTS) ir vartotojai . Tokiu būdu procesas „mato“ tik savo vardų erdvės procesus, tinklo sąsajas, failų sistemą ir pagrindinio kompiuterio pavadinimą, todėl susidaro įspūdis, kad jis yra kitoje sistemoje.

Savo ruožtu, „cgroups“ leidžia nurodyti, kiek procesoriaus, atminties, disko įvesties/išvesties, procesų skaičiaus ir kt. gali sunaudoti konteineris . Tai apsaugo nuo nekontroliuojamos viso kompiuterio apkrovos, o tai labai svarbu, kai mazgai dalijami tarp komandų ar projektų.

Vis dėlto labai svarbu suprasti, kad vien vardų erdvės ir cgroups nėra visavertė saugumo sistema . Jos neužkerta kelio branduolio pažeidžiamumų išnaudojimui, nefiltruoja sistemos iškvietimų ir netvarko detalių prieigos politikų. Jos yra pagrindas, tačiau jas reikia sustiprinti.

Protingas būdas sustiprinti aplinką yra derinti syscall filtrus su seccomp, MAC politikomis („AppArmor“ arba „SELinux“) ir drastiškai sumažinti procesų galimybes, idealiu atveju kartu su vartotojų vardų erdvėmis ir rootless režimu, kad būtų sumažinta žala, jei kas nors pavyktų ištrūkti iš konteinerio.

Saugumo grėsmės konteinerių platformose

Realioje konteinerių platformoje atakos paviršius yra paskirstytas per kelis sluoksnius: branduolį ir vykdymo aplinką („runc“, „containerd“, CRI-O), atvaizdų tiekimo grandinę, konteinerio / orkestratoriaus konfigūraciją ir pagrindinę infrastruktūrą (debesų saugyklą, saugyklą, IAM, tinklą).

Įprasti atakų vektoriai apima programinės įrangos pažeidžiamumus branduolyje arba konteinerio vykdymo aplinkoje, nesaugių arba neprižiūrimų atvaizdų naudojimą, konfigūracijos klaidų darymą „Kubernetes“ arba „Docker“ (privilegijuoti konteineriai, pavojingi pagrindinio kompiuterio prijungimai, pernelyg atviri tinklo režimai) ir saugumo spragas registruose arba CI/CD srautuose.

Daugelyje realių incidentų nėra vienos „stebuklingos klaidos“, o veikiau žinomo pažeidžiamumo ir neatsargios konfigūracijos derinys : konteineriai veikia kaip root, naudojama „--privileged“ vėliava, pagrindinės failų sistemos prijungimas prie konteinerio ir „seccomp“ arba MAC adreso nebuvimas.

Prie viso to prisideda ir tiekimo grandinės problema: viešuose duomenų bazės atvaizduose dažnai yra CVE atakų, pasenusių paketų ir prastai kontroliuojamų priklausomybių . Kenkėjiškai programai gana lengva praslysti arba pažeista biblioteka gali likti neveikli, kol susidarys tinkamos sąlygos jai vykdyti.

Todėl gamybinėje aplinkoje tai nėra neprivaloma: turite nuskaityti atvaizdus, ​​ar nėra pažeidžiamumų, naudodami tokius įrankius kaip „Trivy“, „Clair“ ar „Grype“ , kontroliuoti, kurie registrai naudojami („Harbor“, „Quay“, GHCR su politikomis) ir pasirašyti / patikrinti atvaizdus prieš juos diegdami klasteryje.

„Docker“ ir „Podman“: poveikis grėsmės modeliui

Programų konteinerių pasaulyje „Docker“ ir „Podman“ atlieka panašias funkcijas, tačiau jų architektūra labai skiriasi, ir tai keičia saugumo modelį, su kuriuo dirbame pagrindiniame kompiuteryje.

„Docker“, klasikiniu root režimu, remiasi centriniu demonu („dockerd“), kuris veikia kaip root . CLI bendrauja su šiuo demonu per /var/run/docker.sock arba per TCP, ir būtent šis privilegijuotas procesas sukuria ir naikina konteinerius, tvarko atvaizdus, ​​tinklus ir tomus bei sąveikauja su registrais.

Tai reiškia, kad kiekvienas, turintis prieigą prie „Docker“ lizdo, praktiškai turi root prieigą prie pagrindinio kompiuterio , nes gali paleisti privilegijuotus konteinerius, prijungti bet kokias failų sistemas ir modifikuoti svarbią konfigūraciją. Demonas iš esmės tampa vieninteliu gedimo tašku.

Kita vertus, „Podman“ gimė turint idėją būti konteinerių varikliu be demonų, kuris būtų kuo labiau „gimtoji“ „Linux“ sistema . Nėra jokio nuolatinio centrinio proceso; konteinerius valdo vartotojas arba „systemd“, o integracija su pastaruoju leidžia konteinerius valdyti per aptarnavimo vienetus.

Šis metodas geriau atitinka „Unix“ modelį, kai „kiekvienas procesas priklauso jį paleidžiančiam vartotojui“, ir leidžia išvengti priklausomybės nuo didelių privilegijų demono . Be to, „Podman“ suderinamas su „Docker“ komandomis, todėl perkėlimas yra paprastesnis (aplinkose, kuriose nenorite diegti „Docker CE“, galite netgi naudoti slapyvardį „docker=podman“).

Šakninis režimas ir vartotojo vardų erdvės

Vienas iš svarbiausių praktinių patobulinimų, siekiant sumažinti galimo konteinerio pabėgimo poveikį, yra rootless režimas kartu su vartotojų vardų erdvėmis . Šiuo sprendimu siekiama atsakyti į klausimą: „Kas nutinka, jei konteineris pabėga?“

Vartotojų vardų erdvės leidžia susieti konteinerio UID 0 su neprivilegijuotu UID pagrindiniame kompiuteryje . Kitaip tariant, konteinerio viduje programa mano, kad ji yra root, bet iš pagrindinio kompiuterio perspektyvos tas procesas iš tikrųjų yra įprastas vartotojas su priskirtu subuid/subgid diapazonu.

Tokiu būdu, net jei užpuolikas gauna root teises konteineryje ir sugeba prijungti branduolį arba vykdymo laiko spragą, grįžęs į pagrindinį kompiuterį, jis tai daro kaip neprivilegijuotas vartotojas . Jis negali perrašyti root dvejetainių failų, prijungti jautrių failų sistemų ar manipuliuoti įrenginiais, kuriuose neturi reikiamų teisių.

„Podman“ buvo sukurtas nuo pat pradžių atsižvelgiant į šį modelį: kai tik įmanoma, pagal numatytuosius nustatymus naudoti be root teisių konteinerizavimą , naudoti SELinux/AppArmor ir cgroups net ir neturint root teisių ir daug dėmesio skirti struktūrinių privilegijų mažinimui.

„Docker“ dabar taip pat siūlo tikrą root neturintį režimą , kuriame „dockerd“ ir konteineriai yra vartotojo vardų erdvėje, kitaip nei senesnėje „userns-remap“ versijoje, kur demonas liko root. Saugumo požiūriu tai neleidžia išnaudoti spragų prieš „dockerd“ ir automatiškai suteikti root prieigos prie pagrindinio kompiuterio.

Konteinerių tinklai su „Podman“: tilto, pagrindinio kompiuterio, „Macvlan“ ir bešaknės sąsajos

Kitas svarbus saugumo ir praktinio veikimo elementas yra konteinerių tinklo sluoksnis . „Podman“ siūlo įvairius mechanizmus ryšio užtikrinimui, ypatingą dėmesį skiriant scenarijams be šaknų.

„Podman 4“ pristatė „netavark“ – tinklo tvarkyklę, kuri, vadovaudamasi CNI modeliu, suteikia konteineriams IP adresus tiltų tinkluose, „Macvlan“ tinkluose ir kt. Naudojant „netavark“, rootful konteineriai paprastai pagal numatytuosius nustatymus prisijungia prie tinklo, vadinamo „podman“, susieto su „Linux“ tiltu (podman0) pagrindiniame kompiuteryje, kurio adresas yra 10.88.0.0/16.

Šis numatytasis tilto tinklas užtikrina pagrindinį interneto ryšį per SNAT taisykles ir leidžia jums atskleisti konteinerio prievadus pagrindiniam kompiuteriui naudojant `-po --publish`, kuris generuoja DNAT taisykles iptables/nftables. Dėl suderinamumo su Docker šis tinklas nenaudoja vidinio DNS serverio.

Taip pat galime kurti vartotojo apibrėžtus tiltų tinklus , kurie izoliuoja konteinerių grupes viena nuo kitos ir teikia vidinį DNS. Tai leidžia konteineriams privačiame tinkle spręsti pagal pavadinimą, lengviau atskirti paslaugas, kurios neturėtų matyti viena kitos, ir suteikia daugiau MTU, užkardų ir kitų funkcijų valdymo galimybių.

Sudėtingesnėse aplinkose konteineriams tiesiogiai prie fizinio kompiuterio tinklo prijungti galima naudoti „Macvlan“ arba „ipvlan“ tinklus . „Macvlan“ leidžia konteineriams bendrauti tarpusavyje, o „ipvlan“ linkęs juos labiau izoliuoti; tai naudingos parinktys diegimuose, kai kiekvienas konteineris turi būti matomas kaip tikras kompiuteris likusioje tinklo dalyje.

Bešakniai tinklai: slirp4netns ir pasta

Kai vartotojas nėra root, viskas tampa sudėtinga: vartotojas be privilegijų negali laisvai modifikuoti pasaulinės tinklo vardų erdvės ar kurti savavališkų sąsajų, todėl „Podman“ turi griebtis vartotojo erdvės sprendimų, kad užtikrintų ryšį.

Čia praverčia „slirp4netns“ – klasikinis mechanizmas, kurį naudoja „Podman rootless“ . Šis projektas sukuria izoliuotą tinklo aplinką konteineryje ir naudoja branduolio „slirp“ modulį adresų vertimui (NAT) atlikti ir leisti konteineriui pasiekti internetą per pagrindinio kompiuterio tinklą.

Praktiškai „slirp4netns“ sukuria TAP sąsają konteinerio tinklo vardų erdvėje (pavyzdžiui, „tap0“ su IP adresu 10.0.2.100 ir šliuzu 10.0.2.2) ir nukreipia srautą per TCP/IP protokolų rinkinį, įdiegtą vartotojo erdvėje. Tai funkcionalu, tačiau prideda tam tikrų papildomų išlaidų ir apribojimų.

Vienas iš šių apribojimų yra tas, kad neprivilegijuoti vartotojai negali naudoti prievadų, mažesnių nei 1024. „sysctl“ parametras „net.ipv4.ip_unprivileged_port_start“ žymi, iš kurio prievado jie laikomi „neprivilegijuotais“ (pagal numatytuosius nustatymus – 1024), nors tai galima atsargiai koreguoti, jei tai leidžia saugumo modelis.

„Podman 5“ versijoje „slirp4netns“ pakeičiamas „pasta“ kaip numatytasis bešaknis mechanizmas . „Pasta“ taip pat veikia visiškai vartotojo erdvėje, tačiau dėl „tap“ sąsajos ir nulinio kopijavimo technologijų pasiekia beveik natyvų tinklo našumą, sumažindamas poveikį delsai ir pralaidumui, palyginti su „slirp4netns“.

Tiltų ir prieglobos tinklai rootless konteineriuose

Net ir dirbdami ne root režimu, galime prijungti root neturinčius konteinerius prie numatytojo „podman“ tilto tinklo naudodami `--network=podman`. Tai išnaudoja „netavark“ galimybes ir susieja prievadus su pagrindiniu kompiuteriu naudojant `-p`, kaip ir root režimu.

Taip pat galima kurti vartotojo apibrėžtus tiltų tinklus aplinkose be šaknų . Tokiu atveju tiltai ir susiję įrenginiai kuriami ne pagrindinio kompiuterio globalioje tinklo vardų erdvėje, o vartotojo vardų erdvėje, todėl šios sąsajos nebus matomos iš pagrindinio kompiuterio naudojant paprastą komandą „sudo ip a“.

Norint patikrinti šiuos bešaknius tiltus, „Podman“ siūlo komandą „podman unshare --rootless-netns“ , kuri atidaro apvalkalą vartotojo tinklo vardų erdvėje. Iš ten galima stebėti vidinius tiltus ir patikrinti tiesioginį ryšį su konteineriais.

Ši izoliacija turi įdomų poveikį: Gali nebūti tiesioginio ryšio iš pagrindinio kompiuterio į tų bešaknių konteinerių IP adresus.tačiau jis veikia su prievadais, susietais su paties kompiuterio IP adresu, kurie veikia kaip įėjimo taškas į paslaugą.
Ryšiui tarp konteinerių užtikrinti į vartotojo apibrėžtą tiltų tinklą integruotas DNS serveris leidžia jiems kalbėti vardais, o tai labai supaprastina paskirstytų programų konfigūravimą.

Kitame gale yra pagrindinio kompiuterio tinklas (--network=host) , kuriame konteineris dalijasi tinklo steką su pagrindiniu kompiuteriu be savo IP adreso. Šiuo režimu, jei root neturintis konteineris paleidžia serverį 8080/tcp prievadu, paslauga bus tiesiogiai pasiekiama pagrindinio kompiuterio 8080 prievade, taip išsaugant prievadų susiejimą, bet sumažinant izoliaciją.

„Podman Desktop“, vaizdo gavimo įrankiai ir vietinis orkestravimas

Tiems, kurie renkasi kažką vizualesnio, „Podman Desktop“ suteikia grafinę aplinką konteineriams, pod'ams, vaizdams ir tinklo konfigūracijoms valdyti kūrimo mašinose, veikdama kaip tiesioginė „Docker Desktop“ alternatyva, tačiau pasikliaudama bedūmiu varikliu.

Vaizdai gaunami naudojant „podman pull“, kuris atsisiunčiamas iš registrų, apibrėžtų faile `/etc/containers/registries.conf` . Jei vaizdas nurodytas be registro pavadinimo, „Podman“ bando jį rasti sukonfigūruotoje registro eilėje, pagal numatytuosius nustatymus naudodama žymę `latest`.

Be „Podman“ komandinės eilutės sąsajos, „skopeo“ galime naudoti kaip specialų įrankį vaizdams tvarkyti, tikrinti ir kopijuoti tarp registrų ir vietinių saugyklų. Tokios komandos kaip „kopijuoti“, „ištrinti“ ir „sinchronizuoti“ leidžia automatizuoti saugyklų sinchronizavimą, pažymėti vaizdus šiukšlių surinkimui ir perkelti artefaktus tarp aplinkų.

Atsisiuntus atvaizdą, „podman run“ leidžia paleisti konteinerius nurodant transportą ir kelią (pagal numatytuosius nustatymus tai „Docker“ transportavimas ir paieška sukonfigūruotame registre). Įprastos parinktys (-d, -p, --name, --pod ir kt.) apima tiek laboratorinius scenarijus, tiek rimtesnius diegimus.

Kasdienis valdymas atliekamas naudojant komandą „podman ps“, skirtą konteinerių sąrašui pateikti, komandą „podman stop/start“, skirtą esamų egzempliorių sustabdymui arba paleidimui, ir komandą „podman rm“, skirtą sustabdytų konteinerių pašalinimui . Jei konteineris buvo modifikuotas ir norime jį konvertuoti į naują atvaizdą, komanda „podman commit“ išsaugo šiuos pakeitimus nauju pavadinimu.

Pods ir pažangūs vykdymo modeliai su Podman

Įkvėptas „Kubernetes“, „Podman“ leidžia grupuoti konteinerius į podus, kurie dalijasi tuo pačiu tinklo steku ir tam tikrais ištekliais . Tai puikus modelis tokiems dalykams kaip duomenų bazė ir jos klientas arba kelios mikropaslaugos, kurioms reikia mažo delsos laiko.

Komanda `podman pod create` sukuria naują ankštį ir grąžina jos ID, tačiau pagal numatytuosius nustatymus ankštis lieka sustabdyta, kol nepaleidžiamas susijęs konteineris arba ji aiškiai paleidžiama naudojant `podman pod start`.

Norėdami pamatyti, kurie ankštys yra sistemoje, naudokite `podman pod ls` , kuris taip pat pateiks su kiekvienu iš jų susietą INFRA konteinerį. Šis specialus konteineris palaiko tinklo ir kitų bendrinamų ankšties išteklių veikimą, todėl konteinerių skaičius niekada nėra nulis.

„Podman“ siūlo konkrečias komandas, skirtas paleisti, sustabdyti arba paleisti iš naujo visus ankštis („podman pod start/stop/restart“) , tačiau mes taip pat galime veikti tik su konkrečiu konteineriu ankštyje, nekeisdami likusios dalies, išlaikydami proceso izoliaciją programos lygmeniu.

Norėdami pridėti daugiau konteinerių prie esamo konteinerio, naudokite `podman run --pod POD_NAME` , vadovaudamiesi ta pačia sintakse kaip ir atskiriems konteineriams. Negalite pašalinti konteinerio iš konteinerio jo nesunaikindami, nes konteinerio narystė yra susieta su jo gyvavimo ciklu.

Stebėjimas atliekamas naudojant „podman ps –pod“ arba specialias komandas, skirtas stebėti visų konteinerių, esančių visuose „ankštyse“, procesus , greitai nustatant, kas priklauso kuriai grupei ir kaip paskirstomos paslaugos.

Konteineriai, LXC ir programų virtualizacija

Nors „Docker“ ir „Podman“ dominuoja pokalbyje, tai nėra vienintelės konteinerizavimo parinktys GNU/Linux sistemoje . Tokie sprendimai kaip „LXC/LXD“, „systemd-nspawn“ ir „Kata Containers“ problemą sprendžia šiek tiek skirtingais aspektais.

LXC teikia labai lengvus sistemos konteinerius su savo pagrindinio kompiuterio pavadinimu, IP adresu, failų sistema ir visa inicijavimo sistema . Kartu su LXD, kuris veikia kaip konteinerių ir virtualių mašinų hipervizorius, jis suteikia patirtį, labai panašią į kelių lengvų mašinų naudojimą beveik be operacinės sistemos.

Nors „Docker“ / „Podman“ daugiausia dėmesio skiria OCI suderinamiems programų konteineriams , LXC sužiba, kai reikalingos nuolatinės aplinkos su keliomis paslaugomis ir procesais, veikiančios kaip virtuali mašina, tačiau su mažesnėmis pridėtinėmis sąnaudomis ir labai natūraliai integruojančios su „Linux“ branduoliu.

Kalbant apie našumą, LXC gali paleisti daug duomenų reikalaujančias įmonės programas praktiškai be jokių nuostolių , todėl tai yra puikus pasirinkimas darbo krūviams, kuriems būdingas delsos laikas ir kuriems nereikia tradicinės virtualios mašinos stiprios izoliacijos.

Be to, populiarėja ir technologijos, skirtos mikrovirtualioms kompiuteriams ir patobulintai izoliacijai, tokios kaip „Kata Containers“ , kuri kiekvieną ankštį paleidžia mažoje virtualioje mašinoje su savo branduoliu, arba „gVisor“, kuri tarp programos ir „Linux“ įterpia „branduolio smėlio dėžę“, parašytą „Go“ kalba. Abi sumažina priklausomybę nuo bendro branduolio ir priartėja prie virtualių mašinų saugumo modelio, išlaikydamos konteinerių patogumą vartotojui.

Geriausia Docker ir Podman kietinimo praktika

Atsižvelgiant į visa tai, kas išdėstyta pirmiau, pagrįstas požiūris į patikimą konteinerių platformą yra dirbti sluoksniais: segmentavimas naudojant vardų erdves / cgroups, filtravimo politikos naudojant seccomp ir MAC bei struktūrinis privilegijų apribojimas naudojant rootless režimą.

Praktiškai patartina laikytis standartinės praktikos – konteinerius paleisti ne root režimu, kai tik įmanoma , ypač daugelio nuomininkų aplinkoje arba bendrinamuose debesyse. „Podman“ tai palengvina pagal numatytuosius nustatymus, o „Docker rootless“ taiko tą pačią filosofiją, kai reikalingas suderinamumas.

Pagrindinio kompiuterio branduolys turi būti nuolat atnaujinamas diegiant saugos pataisas . Tokios pažeidžiamos vietos kaip „Dirty COW“, „Dirty Pipe“ ir kitos yra sprendžiamos atnaujinimais, kuriuos reikia įdiegti gana greitai, jei nenorime palikti atvirų durų konteinerių pabėgimams.

Kita labai veiksminga priemonė – naudoti nekintamus, konteineriams pritaikytus distribucinius paketus, tokius kaip „openSUSE MicroOS“ arba „Flatcar Linux“ . Jų tik skaitymui skirta šakninė ir atominių atnaujinimų sistema gerokai sumažina atakų paviršių ir palengvina ankstesnių pakeitimų taikymą, jei po pataisos kas nors nepavyksta.

Dėl konfigūracijos: gamybinėje aplinkoje nenaudokite privilegijuotų konteinerių, išskyrus itin kontroliuojamus atvejus , neleiskite programų kaip root konteinerio viduje, kai tik įmanoma, naudokite tik skaitymui skirtas failų sistemas ir apribokite galimybes iki minimumo. SELinux/AppArmor ir seccomp profiliai, pritaikyti prie faktinių programos iškvietimų, yra praktiškai privalomi.

Galiausiai, neturime pamiršti ir vykdymo laiko stebėjimo aspekto . Tokios priemonės kaip „Falco“, „Sysdig Secure“ arba „Aqua“ padeda aptikti anomalijas, pabėgimo bandymus (pvz., neįprastą prieigą prie /proc arba /sys), netipinį tinklo srautą arba įtartinas komandas, suteikdamos laiko reaguoti prieš atakai įsitvirtinant.

Derinant klasikinę virtualizaciją su KVM, „Podman“ valdomais konteineriais (pageidautina bešakniu režimu), gerai segmentuotais tinklais ir geromis apsaugos nuo pažeidimų praktikomis, galima sukurti labai lanksčią ir gana saugią virtualizacijos platformą. Supratimas, kad bendras branduolys yra svarbiausias taškas, pasikliauti virtualiomis mašinomis arba mikrovirtualiomis mašinomis, kai to reikalauja rizika ar atitiktis reglamentams, ir kruopštus vaizdų tiekimo grandinės valdymas lemia skirtumą tarp laboratorinės aplinkos ir gamybai paruoštos infrastruktūros.