- Kontit jakavat ytimen isännän kanssa, joten niiden eristäminen riippuu nimiavaruuksista, cgroup-ryhmistä ja järjestelmän koventamisen ominaisuuksista.
- Podman tarjoaa lisäturvaa verrattuna klassiseen Dockeriin välttämällä keskitetyn juuridaemonin ja helpottamalla juuritonta suorittamista.
- Podmanin silta-, isäntä- ja juurettomat verkot (slirp4netns, paste) mahdollistavat yhdistettävyyden ja eristäytymisen välisen tasapainon säätämisen.
- KVM:n, konttien ja parhaiden käytäntöjen (rootless, MAC, seccomp, kuvien skannaus) yhdistäminen tarjoaa vankan alustan tuotantoympäristöille.
Kun Linuxissa aletaan perustaa vakavaa konttiympäristöä, sama kysymys herää heti: missä määrin on turvallista luottaa pelkästään kontteihin, ja milloin on suositeltavaa päivittää KVM:ään tai mikro-virtuaalikoneisiin? Yritysympäristöissä, joissa Docker, Podman, LXC, KVM-virtuaalikoneet ja erilaiset hypervisorit ovat sekaisin, eristysmallin vankka ymmärtäminen on avain virheiden välttämiseen.
Lisäksi jonkin verran monimutkaiset skenaariot eivät ole harvinaisia, kuten Docker Desktopin tai Podmanin käyttö virtuaalikoneessa VirtualBoxissa tai KVM:ssä , joissa on useita virtualisointitasoja (sisäkkäisiä tai ei), ja on helppo kohdata virheitä, kuten "KVM ei ole käytössä isännässä". Järjestetään kaikki nämä osat – säilöt, virtuaalikoneet, Podman, KVM, verkko ja tietoturva – ja katsotaan, miten ne yhdistetään todella turvallisen ja käytännöllisen virtualisoinnin saavuttamiseksi.
Klassinen virtualisointi KVM:llä ja virtuaalikoneilla
Koko tämän järjestelmän perustana on edelleen käyttöjärjestelmien täydellinen virtualisointi hypervisoreilla, kuten KVM, Xen tai ESXi . Tässä fyysisessä laitteistossa käytetään hypervisoria, joka vastaa koneen "jakamisesta" useisiin itsenäisiin virtuaalikoneisiin.
Tässä mallissa jokainen virtuaalikone käynnistää oman ytimen ja vieraskäyttöjärjestelmänsä täysin erillään isännästä. Hypervisor (esimerkiksi Linux-ytimeen integroitu KVM) toimii portinvartijana laitteiston ja virtuaalikoneiden välillä ja vastaa niiden välisestä vahvasta eristyksestä.
Yleensä puhutaan kahdentyyppisistä hypervisoreista: tyypin 1 eli paljaista metallihypervisoreista, jotka toimivat suoraan laitteistolla, ja tyypin 2 hypervisoreista, jotka isännöidään olemassa olevan käyttöjärjestelmän päällä. VirtualBox tai VMware Workstation olisivat tyyppiä 2 , kun taas libvirtin hallinnoima KVM Linux-palvelimella on lähempänä tyyppiä 1, vaikka se jakaakin tilaa isännän itsensä kanssa.
Tämän lähestymistavan suurin etu on, että jokaisella virtuaalikoneella on oma täydellinen pinonsa: ydin, käyttäjätila, palvelut, verkko ja tallennustila . Tämä tarjoaa paljon joustavuutta ja mahdollisuuden käyttää eri käyttöjärjestelmiä ja ydinversioita samalla fyysisellä koneella.
Näiden virtualisoitujen alustojen hallintaan GNU/Linuxissa libvirtiä käytetään lähes aina orkestrointi-API:na , jonka lisäksi tuetaan graafisia ja komentorivityökaluja, tai suurempia projekteja, kuten OpenStackia, joka rakentaa kokonaisia pilvipalveluita yhdistämällä virtuaalikoneita, paljaita metalliympäristöjä ja kontteja.
KVM:n laitteistovaatimukset ja yleiset ongelmat
Ennen KVM:n suorittamista tai siitä riippuvien ratkaisujen (kuten joidenkin Docker Desktopin tai mikro-VM-kokoonpanojen) käyttöä sinun on varmistettava, että suoritin tukee laitteistovirtualisointia (VT-x Intelillä tai SVM/AMD-V AMD:llä) ja että se on käytössä BIOSissa/UEFI:ssä.
Linuxissa on nopea tarkistus: jos komento `grep -E 'svm|vmx' /proc/cpuinfo` palauta mitään tai asetus on edelleen poistettu käytöstä laiteohjelmistossa, KVM ei toimi. Lisäksi tilanteissa, joissa virtuaalikoneita suoritetaan toisen virtuaalikoneen sisällä (sisäkkäinen virtualisointi), ylimmän tason hypervisorin on eksplisiittisesti avattava kyseiset laajennukset vierasversiolle.
Kun jokin menee pieleen, näkyviin tulee tyypillisiä viestejä, kuten pahamaineinen Docker Desktop -ponnahdusikkuna RHEL 9:ssä VirtualBoxin sisällä: ”KVM ei ole käytössä isännässä .” Ongelma ei ole tässä suoraan Dockerissa tai RHEL:ssä, vaan pikemminkin siinä, että VirtualBox-virtuaalikone ei saa tarvittavia virtualisointilaajennuksia KVM:n suorittamiseen siinä.
Komentojen, kuten `modprobe kvm` tai `modprobe kvm_amd / kvm_intel`, pitäisi ladata ytimen moduulit ilman virheilmoituksia. Jos `dmesg` ei näytä mitään olennaista tai `lsmod | grep kvm` näyttää vain tyhjän `kvm`- ja `irqbypass`-komennon, ja suoritinkohtaiset moduulit puuttuvat, on hyvin todennäköistä, että laitteistovirtualisointia ei ole saatavilla vierasjärjestelmälle tai se on poistettu käytöstä laiteohjelmistossa.
Näissä tilanteissa, vaikka kaikki mahdolliset ominaisuudet olisivat käytössä vierasympäristössä, KVM ei yksinkertaisesti toimi, jos VirtualBox ei tarjoa sisäkkäistä virtualisointia tai se on määritetty väärin . Ratkaisuun kuuluu isäntähypervisorin (VirtualBox, VMware jne.) kokoonpanon tarkistaminen ja sisäkkäisen virtualisoinnin käyttöönotto, jos se on saatavilla.
Kontit: kevyt virtualisointi käyttöjärjestelmätasolla
Perinteisistä virtuaalikoneista poiketen kontit tarjoavat erilaisen lähestymistavan: ne eivät emuloi kaikkea laitteistoa, vaan käyttävät uudelleen isäntäydintä ja eristävät prosessit ja resurssit Linux-ytimen funktioiden avulla.
Kontti on pohjimmiltaan joukko prosesseja, jotka on kapseloitu nimiavaruuksiin ja cgroup-ryhmiin . Tässä "ympäristössä" sovellus luulee toimivansa omalla koneellaan, jolla on oma tiedostojärjestelmänsä, verkkoliittymänsä ja PID-tunnuksensa, mutta todellisuudessa se jakaa ytimen isännän kanssa.
Kontit tarjoavat lähes natiivin suorituskyvyn, koska niissä ei ole mukana toista ydintä eikä täyttä laitteistoemulointia . Lisäkustannukset ovat minimaaliset: juuri sen verran, että ne riittävät nimiavaruuksien liittämiseen, resurssien rajoittamiseen cgroups-ryhmillä ja suojauskäytäntöjen (seccomp, AppArmor, SELinux jne.) valvomiseen.
Tällä suunnittelulla on kuitenkin merkittävä seuraus: kaikki työkuormet käyttävät samaa fyysistä ydintä . Vakava haavoittuvuus kyseisessä ytimessä voi yhtäkkiä muuttua mahdolliseksi pakokeinoksi kaikille kyseisellä solmulla toimiville säilöille.
Siksi usein sanotaan, että säilön eristäminen ei ole "absoluuttista" kuten virtuaalikoneen . Jos joku onnistuu hyödyntämään kriittistä ytimen virhettä, nimiavaruudet lakkaavat olemasta tehokas este, ja säilön ja isäntien väliset rajat voivat hämärtyä.
Nimiavaruudet ja cgroups: säilön eristämisen perusta
Linuxissa säilön eristäminen perustuu kahteen pääpilariin: nimiavaruuksiin järjestelmänäkymien erottamiseksi ja cgroup-ryhmiin resurssien rajoittamiseksi ja huomioimiseksi.
Nimiavaruudet eristävät asioita, kuten PID:t, verkon, liitoskohdat, IPC:n, isäntänimen (UTS) ja käyttäjät . Tällä tavoin prosessi "näkee" vain oman nimiavaruutensa prosessit, verkkoliittymät, tiedostojärjestelmän ja isäntänimen, mikä antaa sille vaikutelman, että se on eri järjestelmässä.
Cgroups puolestaan mahdollistaa kontin kuluttaman prosessorin, muistin, levy-I/O:n, prosessien määrän jne. määrittämisen . Tämä estää hallitsemattoman kuormituksen ylikuormittamasta koko isäntäkonetta, mikä on olennaista jaettaessa solmuja tiimien tai projektien välillä.
On kuitenkin tärkeää ymmärtää, että pelkkä nimiavaruus ja cgroup-ryhmä eivät ole täydellinen tietoturvajärjestelmä . Ne eivät estä ytimen haavoittuvuuksien hyödyntämistä, suodata järjestelmäkutsuja tai hallitse yksityiskohtaisia käyttöoikeuskäytäntöjä. Ne ovat perusta, mutta niitä on vahvistettava.
Järkevä tapa koventaa ympäristöä on yhdistää syscall-suodattimet seccompiin, MAC-käytäntöihin (AppArmor tai SELinux) ja prosessien ominaisuuksien rajuun vähentämiseen, mieluiten yhdessä käyttäjätunnusavaruuksien ja pääkäyttäjättömän tilan kanssa vahinkojen minimoimiseksi, jos joku onnistuu pakenemaan säilöstä.
Konttialustojen tietoturvauhkat
Todellisessa konttiympäristössä hyökkäyspinta jakautuu useille tasoille: ytimeen ja ajonaikaiseen ympäristöön (runc, containerd, CRI-O), levykuvan toimitusketjuun, kontti-/orkestrointikokoonpanoon ja taustalla olevaan infrastruktuuriin (pilvi, tallennustila, IAM, verkko).
Yleisiä hyökkäysvektoreita ovat ohjelmistohaavoittuvuudet ytimessä tai säilössä, suojaamattomien tai ylläpitämättömien levykuvien käyttö, määritysvirheet Kubernetesissa tai Dockerissa (etuoikeutetut säilöt, vaaralliset isäntälaitteiden liitokset, liian avoimet verkkotilat) sekä tietoturva-avut rekistereissä tai CI/CD-putkissa.
Monissa tosielämän ongelmissa ei ole yhtä ainoaa "taikavirhettä", vaan pikemminkin yhdistelmä tunnettuja haavoittuvuuksia ja löyhää konfigurointia : root-käyttäjänä toimivat säilöt, --privileged-lipun käyttö, isäntätiedostojärjestelmän liittäminen säilön sisälle ja seccompin tai MAC-osoitteen puuttuminen.
Kaiken tämän lisäksi on toimitusketjun ongelma: julkisissa perustiedostoissa on usein CVE-haavoittuvuuksia, vanhentuneita paketteja ja huonosti hallittuja riippuvuuksia . Haittaohjelmien on suhteellisen helppo päästä läpi tai vaarantunut kirjasto voi pysyä lepotilassa, kunnes olosuhteet ovat oikeat sen suorittamiselle.
Siksi tuotannossa se ei ole valinnaista: sinun on tarkistettava levykuvat haavoittuvuuksien varalta työkaluilla, kuten Trivy, Clair tai Grype , hallittava käytettäviä rekistereitä (Harbor, Quay, GHCR käytäntöineen) ja allekirjoitettava/vahvistettava levykuvat ennen niiden käyttöönottoa klusterissa.
Docker vs. Podman: Vaikutus uhkamalliin
Sovelluskonttien maailmassa Docker ja Podman kattavat samankaltaisia toimintoja, mutta niiden arkkitehtuuri eroaa huomattavasti, ja se muuttaa isännässä käytettävää tietoturvamallia .
Docker klassisessa root-tilassaan käyttää keskitettyä daemonia (dockerd), joka toimii root-käyttäjänä . CLI kommunikoi tämän daemonin kanssa /var/run/docker.sock-tiedoston tai TCP:n kautta, ja tämä etuoikeutettu prosessi luo ja tuhoaa säilöjä, hallitsee levykuvia, verkkoja ja taltioita sekä on vuorovaikutuksessa rekistereiden kanssa.
Tämä tarkoittaa, että kenellä tahansa, jolla on pääsy Docker-sockettiin, on käytännössä pääkäyttäjän oikeudet isäntäkoneeseen , koska he voivat käynnistää etuoikeutettuja säilöjä, liittää mielivaltaisia tiedostojärjestelmiä ja muokata kriittisiä kokoonpanoja. Daemonista tulee käytännössä ainoa vikaantumispiste.
Podman puolestaan syntyi ajatuksella olla daemon-vapaa konttimoottori, joka on mahdollisimman "natiivi" Linuxille . Siinä ei ole pysyvää keskitettyä prosessia; kontteja ohjaa käyttäjä tai systemd, ja integrointi jälkimmäisen kanssa mahdollistaa konttien hallinnan palveluyksiköiden kautta.
Tämä lähestymistapa on paremmin linjassa Unix-mallin kanssa, jossa "jokainen prosessi kuuluu käyttäjälle, joka sen käynnistää", ja siinä vältetään korkean käyttöoikeuden omaavan daemonin käyttö . Lisäksi Podman tarjoaa yhteensopivuuden Docker-komentojen kanssa, mikä yksinkertaistaa migraatiota (voit jopa käyttää aliasta `docker=podman` ympäristöissä, joissa et halua asentaa Docker CE:tä).
Rootless-tila ja käyttäjätunnusavaruudet
Yksi merkittävimmistä käytännön edistysaskeleista mahdollisen säilön pakokoodin vaikutusten vähentämisessä on juuriton tila yhdistettynä käyttäjän nimiavaruuksiin . Tämän tarkoituksena on vastata kysymykseen: "Mitä tapahtuu, jos säilö pakokoodin saa?"
Käyttäjänimiavaruudet mahdollistavat säilön UID 0:n uudelleenmäärittämisen isännän etuoikeuttamattomaan UID:hen . Toisin sanoen säilön sisällä sovellus luulee olevansa pääkäyttäjä, mutta isännän näkökulmasta prosessi on itse asiassa tavallinen käyttäjä, jolla on määritetty subuid/subgid-alue.
Tällä tavoin, vaikka hyökkääjä saisikin pääkäyttäjän oikeudet säilön sisällä ja onnistuisi ketjuttamaan ytimen tai ajonaikaisen hyökkäyksen, hän tekee sen palattuaan isäntäkoneeseen etuoikeuttamattomana käyttäjänä . Hän ei voi korvata pääkäyttäjän tiedostoja, liittää arkaluonteisia tiedostojärjestelmiä tai manipuloida laitteita, joilla hänellä ei ole tarvittavia oikeuksia.
Podman suunniteltiin alusta alkaen tämä malli mielessä: rootless-konttikäyttö oletuksena aina kun mahdollista , SELinux/AppArmorin ja cgroupsien käyttö myös ilman roottia sekä vahva painotus rakenteellisten oikeuksien minimoimiseen.
Docker tarjoaa nyt myös aidon pääkäyttäjättömän tilan , jossa dockerd ja säilöt sijaitsevat käyttäjän nimiavaruudessa, toisin kuin vanhemmassa userns-remap-tilassa, jossa daemon pysyi pääkäyttäjänä. Tietoturvan näkökulmasta tämä estää dockerdia vastaan tehtyä hyökkäystä myöntämästä automaattisesti pääkäyttäjän oikeuksia isännälle.
Konttiverkot Podmanin avulla: silta-, isäntä-, macvlan- ja juurittomat rajapinnat
Toinen tärkeä elementti turvallisuuden ja käytännön toiminnan kannalta on konttiverkkokerros . Podman tarjoaa erilaisia mekanismeja yhteyksien tarjoamiseksi, erityisesti juurettomissa skenaarioissa.
Podman 4 esitteli netavarkin, CNI-mallia noudattavan verkkoajurin, joka tarjoaa konteille IP-osoitteita siltaverkoissa, MacVlaneissa jne. Netavarkin avulla rootful-kontit muodostavat tyypillisesti oletusarvoisesti yhteyden "podman"-nimiseen verkkoon, joka on liitetty isännän Linux-siltaan (podman0) ja jonka osoite on 10.88.0.0/16.
Tämä oletusarvoinen siltaverkko tarjoaa perusinternetyhteyden SNAT-sääntöjen kautta ja sallii konttiporttien paljastamisen isännälle käyttämällä `-po --publish`-valitsinta, joka luo DNAT-säännöt iptables/nftables-tiedostoihin. Docker-yhteensopivuuden vuoksi tässä verkossa ei ole sisäistä DNS-palvelinta.
Voimme myös luoda käyttäjän määrittämiä siltaverkkoja , jotka eristävät konttiryhmät toisistaan ja tarjoavat sisäisen nimipalvelun. Tämä mahdollistaa konttien nimenmäärityksen yksityisessä verkossaan, helpottaa sellaisten palveluiden erottamista, joiden ei pitäisi voida nähdä toisiaan, ja antaa paremman hallinnan MTU:hun, palomuureihin ja muihin ominaisuuksiin.
Kehittyneemmissä ympäristöissä on mahdollista käyttää MacVlan- tai IPVLAN-verkkoja konttien yhdistämiseen suoraan isännän fyysiseen verkkoon. MacVlan mahdollistaa konttien välisen kommunikoinnin, kun taas IPVLAN pyrkii eristämään ne enemmän; nämä ovat hyödyllisiä vaihtoehtoja käyttöönotoissa, joissa jokaisen kontin on oltava muun verkon nähtävissä todellisena isäntänä.
Juurettomat verkot: slirp4netns ja pasta
Kun käyttäjä ei ole pääkäyttäjä, asiat mutkistuvat: käyttäjä ilman käyttöoikeuksia ei voi vapaasti muokata globaalia verkon nimiavaruutta tai luoda mielivaltaisia rajapintoja, joten Podmanin on turvauduttava käyttäjäavaruusratkaisuihin yhteyden tarjoamiseksi.
Tässä kohtaa astuu kuvaan slirp4netns , Podmanin rootless-projektin käyttämä klassinen mekanismi . Tämä projekti luo eristetyn verkkoympäristön säilön sisään ja käyttää kernelin slirp-moduulia osoitteenkäännökseen (NAT) ja sallii säilön käyttää internetiä isännän verkon kautta.
Käytännössä slirp4netns luo TAP-rajapinnan säilön verkon nimiavaruuteen (esimerkiksi tap0, jonka IP-osoite on 10.0.2.100 ja yhdyskäytävä 10.0.2.2) ja reitittää liikenteen käyttäjätilaan toteutetun TCP/IP-pinon kautta. Se on toiminnallinen, mutta lisää jonkin verran lisäkustannuksia ja tiettyjä rajoituksia.
Yksi näistä rajoituksista on, että etuoikeudettomat käyttäjät eivät voi käyttää portteja, joiden koko on alle 1024. sysctl-parametri net.ipv4.ip_unprivileged_port_start merkitsee, mistä portista heitä pidetään "etuoikeutettuina" (oletusarvoisesti 1024), vaikka tätä voidaan säätää huolellisesti, jos suojausmalli sen sallii.
Podman 5:ssä slirp4netns on korvattu pastalla oletusarvoisena juurittomana mekanismina . Pasta toimii myös kokonaan käyttäjätilassa, mutta tap-rajapinnan ja kopiointivapaiden tekniikoiden ansiosta se saavuttaa lähes natiivin verkon suorituskyvyn, mikä vähentää vaikutusta latenssiin ja läpäisykykyyn verrattuna slirp4netnsiin.
Silta- ja isäntäverkot juurettomissa säilöissä
Vaikka työskentelisimme ei-root-tilassa, voimme yhdistää rootless-säilöt oletusarvoiseen "podman"-siltaverkkoon käyttämällä `--network=podman`-asetusta. Tämä hyödyntää netavarkin ominaisuuksia ja yhdistää portit isäntäkoneeseen `-p`-asetuksella, aivan kuten rootful-tilassa.
Käyttäjän määrittämiä siltausverkkoja voidaan luoda myös rootless-ympäristöissä . Tässä tapauksessa siltoja ja niihin liittyviä laitteita ei luoda isännän globaaliin verkon nimiavaruuteen, vaan käyttäjän nimiavaruuteen, joten nämä rajapinnat eivät ole näkyvissä isännästä yksinkertaisella `sudo ip a` -komennolla.
Näiden juurettomien siltojen tarkastamiseksi Podman tarjoaa komennon `podman unshare --rootless-netns` , joka avaa komentotulkin käyttäjän verkon nimiavaruudessa. Sieltä voidaan tarkastella sisäisiä siltoja ja varmistaa suora yhteys säilöihin.
Tällä eristyksellä on outo vaikutus: Isännästä ei välttämättä ole suoraa yhteyttä näiden pääkäyttäjien ulkopuolisten säilöjen IP-osoitteisiin.mutta se toimii isännän omaan IP-osoitteeseen yhdistettyjen porttien kanssa, jotka toimivat palvelun aloituspisteenä.
Käyttäjän määrittämään siltaverkkoon integroitu DNS-palvelin mahdollistaa konttien välisen kommunikoinnin, jolloin ne voivat puhua nimeltä, mikä yksinkertaistaa huomattavasti hajautettujen sovellusten konfigurointia.
Toisessa päässä on isäntäverkko (--network=host) , jossa säilö jakaa verkkopinon isännän kanssa ilman omaa IP-osoitetta. Tässä tilassa, jos pääkäyttäjätön säilö käynnistää palvelimen portissa 8080/tcp, palvelu on suoraan käytettävissä isännän portissa 8080, mikä säästää porttimääritystä, mutta vähentää eristäytymistä.
Podman Desktop, kuvantamistyökalut ja paikallinen orkestrointi
Niille, jotka pitävät visuaalisemmasta ratkaisusta, Podman Desktop tarjoaa graafisen ympäristön konttien, podien, kuvien ja verkkokonfiguraatioiden hallintaan kehityskoneilla. Se toimii suorana vaihtoehtona Docker Desktopille, mutta perustuu daemonless-moottoriin.
Levykuvat hankitaan `podman pull` -komennolla, joka lataa tiedostossa `/etc/containers/registries.conf` määritellyistä rekistereistä . Jos levykuvalle ei ole määritetty rekisterinimeä, Podman yrittää paikantaa sen määritetystä rekisterijärjestyksestä käyttäen oletusarvoisesti `latest`-tagia.
Podman-komentoliittymän lisäksi voimme käyttää skopeoa erillisenä työkaluna kuvien hallintaan, tarkasteluun ja kopiointiin rekistereiden ja paikallisten repositorioiden välillä. Komentojen, kuten kopioi, poista ja synkronoi, avulla voimme automatisoida synkronoinnin repositorioiden välillä, merkitä kuvat roskienkeruuta varten ja siirtää artefakteja ympäristöjen välillä.
Kun levykuva on ladattu, `podman run` -komennolla voit käynnistää säilöt määrittämällä siirron ja polun (oletuksena Docker-siirto ja haku määritetystä rekisteristä). Tavalliset asetukset (-d, -p, --name, --pod jne.) kattavat sekä laboratorioskenaariot että vakavammat käyttöönotot.
Päivittäinen hallinta suoritetaan komennolla `podman ps` konttien listaamiseen, `podman stop/start` olemassa olevien instanssien pysäyttämiseen tai käynnistämiseen ja `podman rm` pysäytettyjen konttien poistamiseen . Jos konttia on muokattu ja haluamme muuntaa sen uudeksi levykuvaksi, `podman commit` tallentaa muutokset uudella nimellä.
Podit ja edistyneet suoritusmallit Podmanin avulla
Kubernetesin inspiroimana Podman mahdollistaa konttien ryhmittelyn podeiksi, jotka jakavat saman verkkopinon ja tietyt resurssit . Se on täydellinen malli esimerkiksi tietokannalle ja sen asiakasohjelmalle tai useille mikropalveluille, joiden on kommunikoitava pienellä viiveellä.
Komento `podman pod create` luo uuden podin ja palauttaa sen ID:n, mutta oletusarvoisesti pod pysyy pysäytettynä, kunnes siihen liittyvä säilö käynnistetään tai se käynnistetään eksplisiittisesti komennolla `podman pod start`.
Järjestelmässä olevien podien näkee komennolla `podman pod ls` , joka listaa myös kuhunkin podiin liittyvän INFRA-kontin. Tämä erityinen kontti pitää podin verkon ja muut jaetut resurssit käynnissä, joten konttien määrä ei ole koskaan nolla.
Podman tarjoaa erityisiä komentoja kokonaisten podien käynnistämiseen, pysäyttämiseen tai uudelleenkäynnistämiseen (podman pod start/stop/restart) , mutta voimme myös toimia vain tiettyyn podin säilöön muokkaamatta muita, säilyttäen prosessien eristämisen sovellustasolla.
Lisätäksesi lisää säilöjä olemassa olevaan podiin, käytä `podman run --pod POD_NAME` -komentoa noudattaen samaa syntaksia kuin yksittäisille säilöille. Et voi poistaa säilöä podista tuhoamatta sitä, koska podin jäsenyys on sidottu sen elinkaareen.
Valvonta suoritetaan komennolla podman ps –pod tai erityisillä komennoilla, joilla valvotaan kaikkien podien kaikkien säilöjen prosesseja , jolloin tunnistetaan nopeasti, mikä kuuluu mihinkin ryhmään ja miten palvelut on jaettu.
Kontit, LXC ja sovellusvirtualisointi
Vaikka Docker ja Podman hallitsevat keskustelua, ne eivät ole ainoita konttiratkaisuvaihtoehtoja GNU/Linuxissa . Ratkaisut, kuten LXC/LXD, systemd-nspawn ja Kata Containers, käsittelevät ongelmaa hieman eri näkökulmista.
LXC tarjoaa erittäin kevyitä järjestelmäkontteja, joilla on oma isäntänimi, IP-osoite, tiedostojärjestelmä ja täydellinen alustusjärjestelmä . Yhdessä LXD:n kanssa, joka toimii hypervisorina konteille ja virtuaalikoneille, se tarjoaa kokemuksen, joka on hyvin lähellä useiden kevyiden koneiden käyttöä lähes pelkällä perussuorituskyvyllä.
Vaikka Docker/Podman keskittyy OCI-yhteensopiviin sovelluskontteihin , LXC loistaa, kun tarvitaan pysyviä ympäristöjä, joissa on useita palveluita ja prosesseja. Se toimii virtuaalikoneen tavoin, mutta pienemmällä yleiskululla ja erittäin luonnollisella integraatiolla Linux-ytimeen.
Suorituskyvyn kannalta LXC voi suorittaa dataintensiivisiä yrityssovelluksia käytännössä ilman seuraamuksia , mikä tekee siitä tehokkaan valinnan viiveherkille työkuormille, jotka eivät vaadi perinteisen virtuaalikoneen vahvaa eristystä.
Tämän rinnalla mikro-virtuaalikoneisiin ja parannettuun eristämiseen suunnatut teknologiat ovat myös saaneet jalansijaa, kuten Kata Containers , joka käynnistää jokaisen podin pienessä virtuaalikoneessa, jossa on oma kernel, tai gVisor, joka lisää Go-kielellä kirjoitetun "ytimen hiekkalaatikon" sovelluksen ja Linuxin väliin. Molemmat vähentävät riippuvuutta jaetusta ytimestä ja siirtyvät lähemmäksi virtuaalikoneiden tietoturvamallia säilyttäen samalla konttien käyttäjäystävällisyyden.
Dockerin ja Podmanin koventamisen parhaat käytännöt
Kaiken edellä mainitun perusteella järkevä lähestymistapa vankkaan konttialustaan on työskennellä kerroksittain: segmentointi nimiavaruuksien/cgroupsien avulla, suodatuskäytännöt seccompin ja MAC-osoitteiden avulla sekä rakenteellinen etuoikeuksien rajoittaminen pääkäyttäjän tilassa.
Käytännössä on suositeltavaa omaksua vakiokäytäntö, jossa kontteja käytetään ei-root-tilassa aina kun mahdollista , erityisesti usean käyttäjän ympäristöissä tai jaetuissa pilvissä. Podman mahdollistaa tämän oletusarvoisesti, ja Dockerin rootless-tila kattaa saman filosofian, kun yhteensopivuutta tarvitaan.
Palvelimen ydin on pidettävä ajan tasalla tietoturvakorjauksilla . Haavoittuvuudet, kuten Dirty COW, Dirty Pipe ja muut, korjataan päivityksillä, jotka on asennettava suhteellisen nopeasti, jos emme halua jättää ovea auki säilökarkaamisille.
Toinen erittäin tehokas keino on käyttää muuttumattomia, konttipohjaisia jakeluita, kuten openSUSE MicroOS tai Flatcar Linux . Niiden vain luku -tilassa oleva juurikäyttöoikeus ja atominen päivitysjärjestelmä pienentävät huomattavasti hyökkäyspintaa ja helpottavat palautuksia, jos jokin menee pieleen korjauksen jälkeen.
Kokoonpanon osalta: tuotannossa ei saa käyttää etuoikeutettuja säilöjä, paitsi erittäin kontrolloiduissa tapauksissa , sovelluksia ei saa ajaa root-käyttäjänä säilön sisällä, käytetään vain luku -tiedostojärjestelmiä aina kun mahdollista ja rajoitetaan ominaisuudet minimiin. Sovelluksen varsinaisiin kutsuihin räätälöidyt SELinux/AppArmor- ja seccomp-profiilit ovat käytännössä pakollisia.
Lopuksi, emme saa unohtaa ajonaikaista valvontaa . Työkalut, kuten Falco, Sysdig Secure tai Aqua, auttavat havaitsemaan poikkeavuuksia, pakoyrityksiä (kuten epätavallista pääsyä /proc- tai /sys-kansioon), epätyypillistä verkkoliikennettä tai epäilyttäviä komentoja, antaen aikaa reagoida ennen hyökkäyksen alkamista.
Yhdistämällä klassisen virtualisoinnin KVM:ään, Podmanin hallinnoimiin kontteihin (mieluiten rootless-tilassa), hyvin segmentoituihin verkkoihin ja hyviin suojauskäytäntöihin voidaan rakentaa erittäin joustava ja melko turvallinen virtualisointialusta. Ymmärrys siitä, että jaettu ydin on kriittisin kohta, virtuaalikoneiden tai mikrovirtuaalikoneiden käyttö riskien tai määräystenmukaisuuden sitä vaatiessa sekä levykuvan toimitusketjun huolellinen hallinta tekevät eron laboratorioympäristön ja tuotantovalmiin infrastruktuurin välillä.
