Podman, KVM un konteineri: praktisks ceļvedis drošai virtualizācijai

Informatec Digital » Resursi » Podman, KVM un konteineri: praktisks drošas virtualizācijas ceļvedis

Sākot nopietnu konteineru vides iestatīšanu operētājsistēmā Linux, uzreiz rodas viens un tas pats jautājums: cik lielā mērā ir droši paļauties tikai uz konteineriem, un kad ieteicams pāriet uz KVM vai mikrovirtuālajām mašīnām? Korporatīvajā vidē, kur kopā tiek izmantotas Docker, Podman, LXC, KVM virtuālās mašīnas un dažādi hipervizori, laba izolācijas modeļa izpratne ir galvenais, lai izvairītos no kļūdām.

Turklāt diezgan sarežģīti scenāriji nav nekas neparasts, piemēram, mēģinājums izmantot Docker Desktop vai Podman virtuālajā mašīnā VirtualBox vai KVM vidē , kur tiek izmantoti vairāki virtualizācijas līmeņi (ligzdoti vai nē), un ir viegli sastapties ar kļūdām, piemēram, "KVM nav iespējots resursdatorā". Sakārtosim visas šīs daļas — konteinerus, virtuālās mašīnas, Podman, KVM, tīklošanu un drošību — un apskatīsim, kā tās apvienot, lai panāktu patiesi drošu un praktisku virtualizāciju.

Klasiskā virtualizācija ar KVM un virtuālajām mašīnām

Visas šīs sistēmas pamatā joprojām ir pilnīga operētājsistēmu virtualizācija, izmantojot hipervizorus, piemēram, KVM, Xen vai ESXi . Šeit fiziskā aparatūra darbina hipervizoru, kas ir atbildīgs par datora "sadalīšanu" vairākās neatkarīgās virtuālajās mašīnās.

Šajā modelī katra virtuālā mašīna palaiž savu kodolu un viesa operētājsistēmu , pilnīgi atsevišķi no resursdatora. Hipervizors (piemēram, KVM, kas integrēts Linux kodolā) darbojas kā vārtu sargs starp aparatūru un virtuālajām mašīnām un ir atbildīgs par spēcīgu izolāciju starp tām.

Mēs parasti runājam par divu veidu hipervizoriem: 1. tipa jeb tukšiem metāla hipervizoriem, kas darbojas tieši uz aparatūras, un 2. tipa hipervizoriem, kas tiek mitināti virs esošas operētājsistēmas. VirtualBox vai VMware Workstation būtu 2. tips , savukārt KVM, ko pārvalda libvirt Linux serverī, ir tuvāks 1. tipa scenārijam, pat ja tas koplieto vietu ar pašu resursdatoru.

Šīs pieejas lielākā priekšrocība ir tā, ka katrai virtuālajai mašīnai ir savs pilnīgs steks: kodols, lietotāja telpa, pakalpojumi, tīkls un krātuve . Tas nodrošina lielu elastību un iespēju darbināt dažādas operētājsistēmas un kodola versijas vienā fiziskajā datorā.

Lai pārvaldītu šīs virtualizētās platformas GNU/Linux vidē, libvirt gandrīz vienmēr tiek izmantots kā orķestrācijas API , papildus kuram tiek atbalstīti grafiskie un komandrindas rīki vai lielāki projekti, piemēram, OpenStack, kas veido pilnīgus mākoņus, apvienojot virtuālās mašīnas, tukšu metālu un konteinerus.

Aparatūras prasības un bieži sastopamās problēmas ar KVM

Pirms KVM palaišanas vai no tā atkarīgu risinājumu (piemēram, dažu Docker Desktop vai mikro-VM konfigurāciju) izmantošanas jāpārliecinās, vai procesors atbalsta aparatūras virtualizāciju (VT-x Intel procesoros vai SVM/AMD-V AMD procesoros) un vai tā ir iespējota BIOS/UEFI.

Linux sistēmā mums ir ātra pārbaude: ja komanda `grep -E 'svm|vmx' /proc/cpuinfo` neatgriež neko vai šī opcija joprojām ir atspējota programmaparatūrā, KVM nedarbosies. Turklāt scenārijos, kuros mēs darbināsim virtuālās mašīnas citas virtuālās mašīnas iekšpusē (ligzdotā virtualizācija), augstākā līmeņa hipervizoram ir skaidri jāatklāj šie paplašinājumi viesim.

Kad kaut kas noiet greizi, parādās tipiski ziņojumi, piemēram, bēdīgi slavenais Docker Desktop uznirstošais logs RHEL 9 vidē VirtualBox ietvaros: “KVM nav iespējots resursdatorā .” Problēma šeit nav tieši Docker vai RHEL, bet gan tā, ka VirtualBox VM nesaņem nepieciešamos virtualizācijas paplašinājumus, lai tajā palaistu KVM.

Tādām komandām kā `modprobe kvm` vai `modprobe kvm_amd / kvm_intel` vajadzētu ielādēt kodola moduļus bez kļūdu ziņojumiem. Ja `dmesg` neuzrāda neko atbilstošu vai `lsmod | grep kvm` rāda tikai tukšu `kvm` un `irqbypass`, un trūkst procesoram specifisko moduļu, ļoti iespējams, ka aparatūras virtualizācija netiek pakļauta viessistēmai vai ir atspējota programmaparatūrā.

Šādos gadījumos, pat ja viesa sistēmā ir iespējotas visas iespējamās funkcijas, ja VirtualBox nepiedāvā ligzdotu virtualizāciju vai tā ir nepareizi konfigurēta, KVM vienkārši nedarbosies . Risinājums ietver resursdatora hipervizora konfigurācijas (VirtualBox, VMware utt.) pārskatīšanu un ligzdotās virtualizācijas iespējošanu, ja tāda ir pieejama.

Konteineri: viegla virtualizācija operētājsistēmas līmenī

Atšķirībā no tradicionālajām virtuālajām mašīnām (VM), konteineri piedāvā atšķirīgu pieeju: tie neemulē visu aparatūru, bet gan atkārtoti izmanto resursdatora kodolu un izolē procesus un resursus, izmantojot Linux kodola funkcijas.

Konteiners būtībā ir procesu kopums, kas iekapsulēts, izmantojot vārdtelpas un cgroups . Šajā "vidē" lietojumprogramma uzskata, ka tā darbojas savā datorā ar savu failu sistēmu, tīkla saskarnēm un PID, bet patiesībā tā koplieto kodolu ar resursdatoru.

Konteineri piedāvā gandrīz dabisku veiktspēju, jo tajos nav iesaistīts otrs kodols un nav pilnīgas aparatūras emulācijas . Papildu slodze ir minimāla: tieši tik daudz, lai pievienotu vārdtelpas, ierobežotu resursus ar cgroups un ieviestu drošības politikas (seccomp, AppArmor, SELinux utt.).

Tomēr šim dizainam ir būtiskas sekas: visām darba slodzēm ir viens un tas pats fiziskais kodols . Nopietna ievainojamība šajā kodolā var pēkšņi kļūt par potenciālu izejas vektoru visiem konteineriem, kas darbojas šajā mezglā.

Tāpēc bieži tiek teikts, ka konteineru izolācija nav “absolūta” kā virtuālās mašīnas izolācija . Ja kādam izdodas izmantot kritisku kodola kļūdu, vārdtelpas vairs nav efektīva barjera, un robežas starp konteineriem un resursdatoriem var tikt nojauktas.

Nosaukumtelpas un cgroups: konteineru izolācijas pamats

Linux sistēmā konteineru izolācija ir balstīta uz diviem galvenajiem pīlāriem: vārdtelpām sistēmas skatu atdalīšanai un cgroups resursu ierobežošanai un uzskaitei.

Nosaukumtelpas izolē tādus elementus kā PID, tīklu, pieslēguma punktus, IPC, resursdatora nosaukumu (UTS) un lietotājus . Tādā veidā process "redz" tikai savas vārdtelpas procesus, tīkla saskarnes, failu sistēmu un resursdatora nosaukumu, radot sajūtu, ka tas atrodas citā sistēmā.

Savukārt cgroups ļauj norādīt, cik daudz centrālā procesora, atmiņas, diska ievades/izvades, procesu skaita utt. konteiners var patērēt . Tas novērš nekontrolētu slodzi, kas pārslogo visu resursdatoru, kas ir svarīgi, koplietojot mezglus starp komandām vai projektiem.

Tomēr ir svarīgi saprast, ka vārdtelpas un cgroups vien nav pilnīga drošības sistēma . Tās neaizkavē kodola ievainojamību izmantošanu, nefiltrē sistēmas izsaukumus un nepārvalda detalizētas piekļuves politikas. Tās ir pamats, taču tās ir jāpastiprina.

Saprātīgākais veids, kā nostiprināt vidi, ir apvienot syscall filtrus ar seccomp, MAC politikām (AppArmor vai SELinux) un krasi samazināt procesu iespējas, ideālā gadījumā kopā ar lietotāju vārdtelpām un bezsaknes režīmu, lai samazinātu kaitējumu, ja kādam izdodas izkļūt no konteinera.

Drošības apdraudējumi konteineru platformās

Reālā konteineru platformā uzbrukuma virsma ir sadalīta vairākos slāņos: kodolā un izpildlaikā (runc, containerd, CRI-O), attēlu piegādes ķēdē, konteinera/orkestratora konfigurācijā un pamatā esošajā infrastruktūrā (mākonī, krātuvē, IAM, tīklā).

Biežāk sastopamie uzbrukumu vektori ietver programmatūras ievainojamības kodola vai konteinera izpildlaikā, nedrošu vai neuzturētu attēlu izmantošanu, konfigurācijas kļūdu pieļaušanu Kubernetes vai Docker (privileģēti konteineri, bīstami resursdatora pieslēgumi, pārmērīgi atvērti tīkla režīmi) un drošības trūkumus reģistros vai CI/CD cauruļvados.

Daudzos reālās pasaules incidentos nav vienas "maģiskas kļūdas", bet gan zināmu ievainojamību un nepietiekamas konfigurācijas kombinācija : konteineri, kas darbojas kā root lietotājs, --privileged karodziņa izmantošana, resursdatora failu sistēmas pievienošana konteineram un seccomp vai MAC adreses neesamība.

Tam visam klāt nāk piegādes ķēdes problēma: publiski pieejamie bāzes attēli bieži satur CVE, novecojušas pakotnes un slikti kontrolētas atkarības . Ļaunprogrammatūrai ir samērā viegli iekļūt vai kompromitētai bibliotēkai palikt neaktīvai, līdz rodas piemēroti apstākļi tās izpildei.

Tāpēc ražošanas vidē tas nav neobligāti: attēli ir jāskenē, lai noteiktu ievainojamības, izmantojot tādus rīkus kā Trivy, Clair vai Grype , jākontrolē, kuri reģistri tiek izmantoti (Harbor, Quay, GHCR ar politikām), un attēli jāparaksta/jāpārbauda pirms to izvietošanas klasterī.

Docker pret Podman: ietekme uz draudu modeli

Lietojumprogrammu konteineru pasaulē Docker un Podman aptver līdzīgas funkcijas, taču to arhitektūra ievērojami atšķiras, un tas maina drošības modeli, ar kuru mēs strādājam resursdatorā.

Docker savā klasiskajā root režīmā paļaujas uz centrālo dēmonu (dockerd), kas darbojas kā root lietotājs . CLI sazinās ar šo dēmonu, izmantojot /var/run/docker.sock vai TCP, un tieši šis privileģētais process izveido un iznīcina konteinerus, pārvalda attēlus, tīklus un sējumus, kā arī mijiedarbojas ar reģistriem.

Tas nozīmē, ka ikvienam, kam ir piekļuve Docker ligzdai, praktiski ir root piekļuve resursdatoram , jo ​​viņi var palaist privileģētus konteinerus, pievienot patvaļīgas failu sistēmas un modificēt kritisku konfigurāciju. Dēmons faktiski kļūst par vienīgo kļūmes punktu.

Savukārt Podman radās ar ideju būt par konteineru dzinēju bez dēmoniem, kas ir pēc iespējas "dzimts" Linux vidē . Nav pastāvīga centrāla procesa; konteinerus kontrolē lietotājs vai systemd, un integrācija ar pēdējo ļauj kontrolēt konteinerus, izmantojot pakalpojumu vienības.

Šī pieeja labāk atbilst Unix modelim, kurā "katrs process pieder lietotājam, kurš to palaiž", un ļauj izvairīties no paļaušanās uz augstu privilēģiju dēmonu . Turklāt Podman piedāvā saderību ar Docker komandām, vienkāršojot migrāciju (vidēs, kurās nevēlaties instalēt Docker CE, varat pat izmantot aizstājvārdu `docker=podman`).

Bezsaknes režīms un lietotāju nosaukumtelpas

Viens no galvenajiem praktiskajiem sasniegumiem potenciāla konteinera aizbēgšanas ietekmes mazināšanā ir bezsaknes režīms apvienojumā ar lietotāju vārdtelpām . Jautājums, uz kuru šī metode cenšas atbildēt, ir: "Kas notiek, ja konteiners patiešām aizbēg?"

Lietotāju nosaukumtelpas ļauj pārkartēt konteinera UID 0 uz neprivileģētu UID resursdatorā . Citiem vārdiem sakot, konteinera iekšienē lietojumprogramma uzskata, ka tā ir root, bet no resursdatora viedokļa šis process patiesībā ir parasts lietotājs ar piešķirtu subuid/subgid diapazonu.

Tādā veidā, pat ja uzbrucējs iegūst root privilēģijas konteinera iekšienē un viņam izdodas ķēdē savienot kodolu vai izpildlaika ievainojamību, atgriežoties resursdatorā, viņš to dara kā lietotājs bez privilēģijām . Viņš nevar pārrakstīt root bināros failus, pievienot sensitīvas failu sistēmas vai manipulēt ar ierīcēm, kurās viņam nav nepieciešamo privilēģiju.

Podman tika izstrādāts jau no paša sākuma, ņemot vērā šo modeli: bezsakņu konteinerizācija pēc noklusējuma, kad vien iespējams , SELinux/AppArmor un cgroups izmantošana pat bez saknes un spēcīgs uzsvars uz strukturālo privilēģiju samazināšanu.

Docker tagad piedāvā arī patiesu bezsaknes režīmu , kurā dockerd un konteineri atrodas lietotāja vārdtelpā, atšķirībā no vecākās userns-remap versijas, kurā dēmons palika root. No drošības viedokļa tas neļauj izmantot ievainojamību pret dockerd, piešķirot automātisku root piekļuvi resursdatoram.

Konteineru tīkli ar Podman: tilta, resursdatora, MacVlan un bezsakņu saskarnes

Vēl viens svarīgs drošības un praktiskas darbības elements ir konteineru tīkla slānis . Podman piedāvā dažādus mehānismus savienojamības nodrošināšanai, īpašu uzmanību pievēršot sakņu neesamības scenārijiem.

Podman 4 ieviesa netavark — tīkla draiveri, kas seko CNI modelim , lai nodrošinātu konteinerus ar IP adresēm tiltu tīklos, MacVlan tīklos utt. Izmantojot netavark, root konteineri parasti pēc noklusējuma izveido savienojumu ar tīklu, ko sauc par “podman”, kas saistīts ar Linux tiltu (podman0) resursdatorā ar adresi 10.88.0.0/16.

Šis noklusējuma tilta tīkls nodrošina pamata interneta savienojumu, izmantojot SNAT noteikumus , un ļauj jums atvērt konteinera portus resursdatoram, izmantojot `-po --publish`, kas ģenerē DNAT noteikumus iptables/nftables. Docker saderības labad šajā tīklā netiek darbināts iekšējs DNS serveris.

Mēs varam arī izveidot lietotāja definētus tiltu tīklus , kas izolē konteineru grupas vienu no otras un nodrošina iekšējo DNS. Tas ļauj konteineriem atrisināt problēmas pēc nosaukuma savā privātajā tīklā, atvieglo pakalpojumu atdalīšanu, kuriem nevajadzētu redzēt vienam otru, un sniedz lielāku kontroli pār MTU, ugunsmūriem un citām funkcijām.

Sarežģītākās vidēs konteinerus var tieši savienot ar resursdatora fizisko tīklu, izmantojot MacVlan vai IPVLAN tīklus. MacVlan ļauj konteineriem sazināties savā starpā, savukārt IPVLAN tos vairāk izolē; šīs ir noderīgas iespējas izvietojumos, kur katram konteineram pārējam tīklam jābūt redzamam kā reālam resursdatoram.

Bezsakņu tīkli: slirp4netns un pasta

Ja lietotājs nav root lietotājs, lietas kļūst sarežģītas: lietotājs bez privilēģijām nevar brīvi modificēt globālā tīkla vārdtelpu vai izveidot patvaļīgas saskarnes, tāpēc Podmanam ir jāizmanto lietotāja telpas risinājumi, lai nodrošinātu savienojamību.

Šeit noder slirp4netns — klasiskais mehānisms, ko izmanto Podman bezsaistes pieeja . Šis projekts konteinera ietvaros izveido izolētu tīkla vidi un izmanto kodola slirp moduli, lai veiktu adrešu tulkošanu (NAT) un ļautu konteineram piekļūt internetam caur resursdatora tīklu.

Praksē slirp4netns izveido TAP saskarni konteinera tīkla vārdtelpā (piemēram, tap0 ar IP adresi 10.0.2.100 un vārteju 10.0.2.2) un maršrutē datplūsmu, izmantojot TCP/IP steku, kas ieviests lietotāja telpā. Tas ir funkcionāls, taču rada zināmas papildu izmaksas un ierobežojumus.

Viens no šiem ierobežojumiem ir tas, ka neprivileģēti lietotāji nevar izmantot portus, kas ir zemāki par 1024. sysctl parametrs net.ipv4.ip_unprivileged_port_start norāda, no kura porta tie tiek uzskatīti par "neprivileģētiem" (pēc noklusējuma 1024), lai gan to var rūpīgi pielāgot, ja drošības modelis to atļauj.

Podman 5 versijā slirp4netns ir aizstāts ar pasta kā noklusējuma bezsakņu mehānismu . Arī Pasta darbojas pilnībā lietotāja telpā, taču, pateicoties pieskāriena saskarnei un nulles kopēšanas tehnoloģijām, tā sasniedz gandrīz vietējo tīkla veiktspēju, samazinot ietekmi uz latentumu un caurlaidspēju salīdzinājumā ar slirp4netns.

Tiltu un mitināšanas tīkli sakņu nesaturošos konteineros

Pat strādājot bez root piekļuves, mēs varam savienot konteinerus bez root piekļuves noklusējuma "podman" tilta tīklam, izmantojot `--network=podman`. Tas izmanto netavark iespējas un kartē portus resursdatoram ar `-p`, tāpat kā root piekļuves režīmā.

Lietotāja definētus tiltu tīklus ir iespējams izveidot arī bezsakņu vidēs . Šajā gadījumā tilti un saistītās ierīces netiek izveidotas resursdatora globālajā tīkla vārdtelpā, bet gan lietotāja vārdtelpā, tāpēc šīs saskarnes nebūs redzamas resursdatorā ar vienkāršu komandu `sudo ip a`.

Lai pārbaudītu šos bezsakņu tiltus, Podman piedāvā komandu `podman unshare --rootless-netns` , kas atver čaulu lietotāja tīkla vārdtelpā. No turienes var novērot iekšējos tiltus un pārbaudīt tiešu savienojamību ar konteineriem.

Šai izolācijai ir interesanta ietekme: Iespējams, ka no resursdatora nav tieša savienojuma ar šo saknes nepieejamo konteineru IP adresēm.taču tas darbojas ar portiem, kas piesaistīti resursdatora paša IP adresei un darbojas kā pakalpojuma ieejas punkts.
Saziņai starp konteineriem DNS serveris, kas integrēts lietotāja definētā tilta tīklā, ļauj tiem runāt pēc nosaukuma, kas ievērojami vienkāršo izkliedēto lietojumprogrammu konfigurēšanu.

Otrā galā ir resursdatora tīkls (--network=host) , kur konteiners koplieto tīkla steku ar resursdatoru bez savas IP adreses. Šajā režīmā, ja konteiners bez saknes startē serveri 8080/tcp portā, pakalpojums būs tieši pieejams resursdatora 8080. portā, tādējādi saglabājot portu kartēšanu, bet samazinot izolāciju.

Podman Desktop, attēlveidošanas rīki un lokālā orķestrēšana

Tiem, kas dod priekšroku kaut kam vizuālākam, Podman Desktop nodrošina grafisku vidi konteineru, podu, attēlu un tīkla konfigurāciju pārvaldībai izstrādes iekārtās, darbojoties kā tieša alternatīva Docker Desktop, bet paļaujoties uz bezdēmonu dzinēju.

Attēli tiek iegūti, izmantojot `podman pull`, kas lejupielādē no reģistriem, kas definēti `/etc/containers/registries.conf` failā . Ja attēls ir norādīts bez reģistra nosaukuma, Podman mēģina to atrast konfigurētajā reģistra secībā, pēc noklusējuma izmantojot tagu `latest`.

Papildus Podman komandrindas saskarnei mēs varam izmantot skopeo kā īpašu rīku attēlu pārvaldībai, pārbaudei un kopēšanai starp reģistriem un lokālajām krātuvēm. Tādas komandas kā copy, delete un sync ļauj automatizēt sinhronizāciju starp krātuvēm, atzīmēt attēlus atkritumu savākšanai un pārvietot artefaktus starp vidēm.

Kad attēls ir lejupielādēts, `podman run` ļauj startēt konteinerus, norādot transportu un ceļu (pēc noklusējuma tas ir Docker transports un meklēšana konfigurētajā reģistrā). Parastās opcijas (-d, -p, --name, --pod utt.) aptver gan laboratorijas scenārijus, gan nopietnākas izvietošanas.

Ikdienas pārvaldība tiek veikta ar komandu `podman ps` konteineru saraksta izveidei, komandu `podman stop/start` esošo instanču apturēšanai vai palaišanai un komandu `podman rm` apturēto konteineru noņemšanai . Ja konteiners ir modificēts un mēs vēlamies to pārveidot par jaunu attēlu, komanda `podman commit` saglabā šīs izmaiņas ar jaunu nosaukumu.

Pods un uzlaboti izpildes modeļi ar Podman

Iedvesmojoties no Kubernetes, Podman ļauj grupēt konteinerus podos, kas koplieto vienu un to pašu tīkla steku un noteiktus resursus . Tas ir ideāls modelis tādām lietām kā datubāze un tās klients vai vairāki mikropakalpojumi, kuriem nepieciešams sazināties ar zemu latentumu.

Komanda `podman pod create` izveido jaunu podu un atgriež tā ID, bet pēc noklusējuma pods paliek apturēts, līdz tiek startēts saistītais konteiners vai tas tiek skaidri palaists ar `podman pod start`.

Lai redzētu, kuri podi atrodas sistēmā, izmantojiet `podman pod ls` , kas parādīs arī ar katru no tiem saistīto INFRA konteineru. Šis īpašais konteiners nodrošina tīkla un citu poda koplietoto resursu darbību, tāpēc konteineru skaits nekad nav nulle.

Podman piedāvā īpašas komandas, lai startētu, apturētu vai restartētu veselus podus (podman pod start/stop/restart) , taču mēs varam arī darboties tikai ar konkrētu konteineru podā, nemainot pārējo, saglabājot procesa izolāciju lietojumprogrammas līmenī.

Lai esošam podam pievienotu vēl konteinerus, izmantojiet `podman run --pod POD_NAME` , ievērojot to pašu sintaksi kā atsevišķiem konteineriem. Konteineru nevar noņemt no poda, to neiznīcinot, jo poda dalība ir saistīta ar tā dzīves ciklu.

Uzraudzība tiek veikta ar podman ps –pod vai īpašām komandām, lai uzraudzītu visu konteineru procesus visos podos , ātri identificējot, kas pieder pie kuras grupas un kā pakalpojumi tiek izplatīti.

Konteineri, LXC un lietojumprogrammu virtualizācija

Lai gan Docker un Podman dominē sarunās, tās nav vienīgās konteinerizācijas iespējas GNU/Linux vidē . Tādi risinājumi kā LXC/LXD, systemd-nspawn un Kata Containers risina problēmu no nedaudz atšķirīgiem skatpunktiem.

LXC nodrošina ļoti vieglus sistēmas konteinerus ar savu resursdatora nosaukumu, IP adresi, failu sistēmu un pilnīgu init sistēmu . Apvienojumā ar LXD, kas darbojas kā hipervizors konteineriem un virtuālajām mašīnām, tas nodrošina pieredzi, kas ir ļoti līdzīga vairāku vieglu mašīnu lietošanai ar gandrīz pilnīgu veiktspēju.

Kamēr Docker/Podman koncentrējas uz OCI saderīgiem lietojumprogrammu konteineriem , LXC izceļas, kad ir nepieciešamas pastāvīgas vides ar vairākiem pakalpojumiem un procesiem, darbojoties kā virtuālā mašīna (VM), bet ar mazākām papildu izmaksām un ļoti dabisku integrāciju ar Linux kodolu.

No veiktspējas viedokļa LXC var darbināt datu ietilpīgas uzņēmuma lietojumprogrammas praktiski bez soda , padarot to par spēcīgu izvēli latentuma jutīgām darba slodzēm, kurām nav nepieciešama tradicionālās virtuālās mašīnas stingra izolācija.

Līdztekus tam ir ieguvušas popularitāti arī tehnoloģijas, kas paredzētas mikrovirtuālajām mašīnām un uzlabotai izolācijai, piemēram, Kata Containers , kas katru podu palaiž nelielā virtuālajā mašīnā ar savu kodolu, vai gVisor, kas starp lietojumprogrammu un Linux ievieto Go valodā rakstītu "kodola smilškasti". Abas samazina atkarību no koplietotā kodola un tuvojas virtuālo mašīnu drošības modelim, vienlaikus saglabājot konteineru lietotājdraudzīgumu.

Docker un Podman sacietēšanas labākā prakse

Ņemot vērā visu iepriekš minēto, saprātīga pieeja stabilai konteineru platformai ir strādāt slāņos: segmentācija ar vārdtelpām/cgroups, filtrēšanas politikas ar seccomp un MAC, kā arī strukturāla privilēģiju ierobežošana, izmantojot bezsaknes režīmu.

Praksē ieteicams izmantot standarta praksi, kad vien iespējams, darbinot konteinerus bez root piekļuves , īpaši vairāku nomnieku vidēs vai koplietotos mākoņos. Podman to nodrošina pēc noklusējuma, un Docker bezroot piekļuves nodrošina to pašu filozofiju, ja nepieciešama saderība.

Resursdatora kodolam ir jābūt atjauninātam ar drošības ielāpiem . Tādas ievainojamības kā Dirty COW, Dirty Pipe un citas tiek novērstas ar atjauninājumiem, kas jāievieš relatīvi ātri, ja nevēlamies atstāt durvis atvērtas konteineru aizbēgšanām.

Vēl viens ļoti efektīvs līdzeklis ir izmantot nemaināmus, uz konteineru orientētus izplatījumus, piemēram, openSUSE MicroOS vai Flatcar Linux . To tikai lasāmā saknes piekļuve un atomārā atjauninājumu sistēma ievērojami samazina uzbrukuma virsmu un atvieglo atcelšanu, ja pēc ielāpa instalēšanas kaut kas noiet greizi.

Attiecībā uz konfigurāciju: ražošanas vidē nedrīkst izmantot privilēģētus konteinerus, izņemot ārkārtīgi kontrolētus gadījumus , nedrīkst palaist lietojumprogrammas kā root konteinera ietvaros, kad vien iespējams, jāizmanto tikai lasāmas failu sistēmas un jāierobežo iespējas līdz minimumam. SELinux/AppArmor un seccomp profili, kas pielāgoti lietojumprogrammas faktiskajiem izsaukumiem, ir praktiski obligāti.

Visbeidzot, nedrīkst aizmirst par izpildlaika uzraudzību . Tādi rīki kā Falco, Sysdig Secure vai Aqua palīdz atklāt anomālijas, glābšanās mēģinājumus (piemēram, neparastu piekļuvi /proc vai /sys), netipisku tīkla trafiku vai aizdomīgas komandas, dodot laiku reaģēt, pirms uzbrukums notiek.

Apvienojot klasisko virtualizāciju ar KVM, Podman pārvaldītiem konteineriem (vēlams bezsaknes režīmā), labi segmentētiem tīkliem un robustām aizsardzības praksēm, var izveidot ļoti elastīgu un diezgan drošu virtualizācijas platformu. Izpratne par to, ka koplietotais kodols ir vissvarīgākais punkts, paļaušanās uz virtuālajām mašīnām (VM) vai mikrovirtuālajām mašīnām, kad to prasa risks vai atbilstība normatīvajiem aktiem, un rūpīga attēlu piegādes ķēdes pārvaldība rada būtisku atšķirību starp laboratorijas vidi un ražošanai gatavu infrastruktūru.