Podman, KVM og containere: en praktisk guide til sikker virtualisering

Informatec Digital » Ressurser » Podman, KVM og containere: en praktisk guide til sikker virtualisering

Når du begynner å sette opp et seriøst containermiljø på Linux, oppstår det samme spørsmålet umiddelbart: i hvilken grad er det trygt å stole utelukkende på containere, og når er det lurt å oppgradere til KVM eller mikro-VM-er? I bedriftsmiljøer, der Docker, Podman, LXC, virtuelle KVM-maskiner og diverse hypervisorer blandes sammen, er en solid forståelse av isolasjonsmodellen nøkkelen til å unngå feil.

Videre er noe komplekse scenarier ikke uvanlige, for eksempel å prøve å bruke Docker Desktop eller Podman i en virtuell maskin i VirtualBox eller KVM , der flere nivåer av virtualisering (nestet eller ikke) spiller inn, og det er lett å støte på feil som "KVM er ikke aktivert på verten." La oss organisere alle disse delene – containere, virtuelle maskiner, Podman, KVM, nettverk og sikkerhet – og se hvordan vi kan kombinere dem for å oppnå virkelig sikker og praktisk virtualisering.

Klassisk virtualisering med KVM og virtuelle maskiner

Grunnlaget for hele dette oppsettet er fortsatt fullstendig virtualisering av operativsystemer ved hjelp av hypervisorer som KVM, Xen eller ESXi . Her kjører den fysiske maskinvaren en hypervisor som er ansvarlig for å "dele" maskinen inn i flere uavhengige virtuelle maskiner.

I denne modellen starter hver virtuelle maskin sin egen kjerne og gjesteoperativsystem , helt separat fra verten. Hypervisoren (for eksempel KVM, integrert i Linux-kjernen) fungerer som en portvokter mellom maskinvaren og de virtuelle maskinene, og er ansvarlig for den sterke isolasjonen mellom dem.

Vi snakker vanligvis om to typer hypervisorer: Type 1- eller bare-metal-hypervisorer, som kjører direkte på maskinvaren, og Type 2-hypervisorer, som ligger oppå et eksisterende operativsystem. VirtualBox eller VMware Workstation ville være Type 2 , mens en KVM administrert av libvirt på en Linux-server er nærmere et Type 1-scenario, selv om den deler plass med verten selv.

Den største fordelen med denne tilnærmingen er at hver virtuelle maskin har sin egen komplette stabel: kjerne, brukerområde, tjenester, nettverk og lagring . Dette gir mye fleksibilitet og muligheten til å kjøre forskjellige operativsystemer og kjerneversjoner på samme fysiske maskin.

For å administrere disse virtualiserte plattformene i GNU/Linux brukes libvirt nesten alltid som et orkestrerings-API , i tillegg til at grafiske og kommandolinjeverktøy støttes, eller større prosjekter som OpenStack, som bygger komplette skyer ved å kombinere virtuelle maskiner, bare metal og containere.

Maskinvarekrav og vanlige problemer med KVM

Før du kjører KVM eller bruker løsninger som er avhengige av det (som noen Docker Desktop- eller micro-VM-konfigurasjoner), må du sørge for at prosessoren støtter maskinvarevirtualisering (VT-x på Intel eller SVM/AMD-V på AMD) og at det er aktivert i BIOS/UEFI.

I Linux har vi en rask sjekk: hvis kommandoen `grep -E 'svm|vmx' /proc/cpuinfo` ikke returnerer noe, eller alternativet fortsatt er deaktivert i firmwaren, vil ikke KVM fungere. Videre, i scenarier der vi kjører virtuelle maskiner inne i en annen virtuell maskin (nestet virtualisering), må hypervisoren på toppnivå eksplisitt eksponere disse utvidelsene for gjesten.

Når noe går galt, vises typiske meldinger, for eksempel den beryktede Docker Desktop-popupen i RHEL 9 i VirtualBox: «KVM er ikke aktivert på verten .» Problemet her ligger ikke direkte i Docker eller RHEL, men snarere i at VirtualBox VM ikke mottar de nødvendige virtualiseringsutvidelsene for å kjøre KVM i den.

Kommandoer som `modprobe kvm` eller `modprobe kvm_amd / kvm_intel` skal laste inn kjernemodulene uten feilmeldinger. Hvis `dmesg` ikke viser noe relevant, eller `lsmod | grep kvm` bare viser en ren `kvm` og `irqbypass`, og de CPU-spesifikke modulene mangler, er det svært sannsynlig at maskinvarevirtualisering ikke eksponeres for gjestesystemet eller er deaktivert i fastvaren.

I disse scenariene, selv om alle mulige funksjoner er aktivert i gjesten, vil KVM rett og slett ikke fungere hvis VirtualBox ikke tilbyr nestet virtualisering eller er feilkonfigurert . Løsningen innebærer å gjennomgå vertshypervisorens konfigurasjon (VirtualBox, VMware osv.) og aktivere nestet virtualisering hvis tilgjengelig.

Containere: lett virtualisering på operativsystemnivå

I motsetning til tradisjonelle virtuelle maskiner tilbyr containere en annen tilnærming: de emulerer ikke all maskinvaren, men gjenbruker heller vertskjernen og isolerer prosesser og ressurser ved hjelp av Linux-kjernefunksjoner.

En container er i hovedsak et sett med prosesser innkapslet ved hjelp av navnerom og cgroups . Innenfor dette «miljøet» tror applikasjonen at den kjører på sin egen maskin, med sitt eget filsystem, nettverksgrensesnitt og PID-er, men i virkeligheten deler den kjernen med verten.

Containere tilbyr nesten native ytelse fordi det ikke er noen andre kjerne involvert og ingen full maskinvareemulering . Overheaden er minimal: akkurat nok til å montere navnerom, begrense ressurser med cgroups og håndheve sikkerhetspolicyer (seccomp, AppArmor, SELinux, osv.).

Denne utformingen har imidlertid en betydelig konsekvens: alle arbeidsbelastninger deler den samme fysiske kjernen . En alvorlig sårbarhet i den kjernen kan plutselig bli en potensiell rømningsvektor for alle containere som kjører på den noden.

Derfor sies det ofte at containerisolering ikke er «absolutt» slik som en virtuell maskin . Hvis noen klarer å utnytte en kritisk kjernefeil, slutter navnerom å være en effektiv barriere, og grensene mellom containere og verter kan brytes.

Navnerom og c-grupper: grunnlaget for containerisolering

I Linux er containerisolering bygget på to hovedpilarer: navnerom for å skille systemvisninger og cgroups for å begrense og ta hensyn til ressurser.

Navnerom isolerer ting som PID-er, nettverk, monteringspunkter, IPC, vertsnavn (UTS) og brukere . På denne måten "ser" en prosess bare prosessene, nettverksgrensesnittene, filsystemet og vertsnavnet til sitt eget navnerom, noe som gir den følelsen av å være på et annet system.

På sin side lar cgroups deg spesifisere hvor mye CPU, minne, disk-I/O, antall prosesser osv. en container kan forbruke . Dette forhindrer at ukontrollert belastning overbelaster hele verten, noe som er viktig når man deler noder mellom team eller prosjekter.

Det er imidlertid viktig å forstå at navnerom og cgroups alene ikke er et komplett sikkerhetssystem . De forhindrer ikke utnyttelse av kjernesårbarheter, filtrerer systemkall eller administrerer detaljerte tilgangspolicyer. De er grunnlaget, men de må forsterkes.

Den fornuftige måten å herde miljøet på er å kombinere syscall-filtre med seccomp, MAC-policyer (AppArmor eller SELinux) og en drastisk reduksjon av prosessfunksjoner, ideelt sett sammen med brukernavnerom og rotløs modus for å minimere skade hvis noen klarer å unnslippe containeren.

Sikkerhetstrusler på containerplattformer

I en ekte containerplattform er angrepsflaten spredt over flere lag: kjernen og runtime (runc, containerd, CRI-O), image-forsyningskjeden, container-/orkestratorkonfigurasjonen og den underliggende infrastrukturen (sky, lagring, IAM, nettverk).

Vanlige angrepsvektorer inkluderer programvaresårbarheter i kjernen eller containerkjøretiden, bruk av usikre eller ikke-vedlikeholdte avbildninger, konfigurasjonsfeil i Kubernetes eller Docker (privilegerte containere, farlige vertsmonteringer, overdrevent åpne nettverksmoduser) og sikkerhetsfeil i registre eller CI/CD-pipelines.

I mange hendelser i den virkelige verden finnes det ingen enkeltstående «magisk feil», men snarere en kombinasjon av kjent sårbarhet pluss slapp konfigurasjon : containere som kjører som root, bruk av flagget --privileged, montering av vertsfilsystemet i containeren og fravær av seccomp eller MAC.

I tillegg til alt dette kommer problemet med forsyningskjeden: offentlige basebilder inneholder ofte CVE-er, utdaterte pakker og dårlig kontrollerte avhengigheter . Det er relativt enkelt for skadelig programvare å gli gjennom eller for et kompromittert bibliotek å forbli inaktivt inntil forholdene ligger til rette for at det kan kjøres.

Derfor er det ikke valgfritt i produksjon: du må skanne images for sårbarheter med verktøy som Trivy, Clair eller Grype , kontrollere hvilke registre som brukes (Harbor, Quay, GHCR med policyer) og signere/verifisere imagene før du distribuerer dem i en klynge.

Docker vs. Podman: Innvirkning på trusselmodellen

Innenfor applikasjonscontainernes verden dekker Docker og Podman lignende funksjoner, men arkitekturen deres er betydelig forskjellig, og det endrer sikkerhetsmodellen vi jobber med på en vert.

Docker, i sin klassiske rootful-modus, er avhengig av en sentral daemon (dockerd) som kjører som root . CLI kommuniserer med denne daemonen gjennom /var/run/docker.sock eller via TCP, og det er denne privilegerte prosessen som oppretter og ødelegger containere, administrerer bilder, nettverk og volumer, og samhandler med registre.

Dette betyr at alle med tilgang til Docker-socketen praktisk talt har root-tilgang til verten , fordi de kan starte privilegerte containere, montere vilkårlige filsystemer og endre kritisk konfigurasjon. Daemonen blir effektivt et enkelt feilpunkt.

Podman, derimot, ble født med ideen om å være en daemonfri containermotor som er så "native" til Linux som mulig . Det finnes ingen permanent sentral prosess; containere kontrolleres av brukeren eller av systemd, og integrasjon med sistnevnte gjør at containere kan kontrolleres gjennom serviceenheter.

Denne tilnærmingen stemmer bedre overens med Unix-modellen der «hver prosess tilhører brukeren som starter den» og unngår å være avhengig av en daemon med høye rettigheter . Videre tilbyr Podman kompatibilitet med Docker-kommandoer, noe som forenkler migrering (du kan til og med bruke alias `docker=podman` i miljøer der du ikke vil installere Docker CE).

Rotløs modus og brukernavneområder

En av de største praktiske fremskrittene for å redusere virkningen av en potensiell containerrømming er rotløs modus kombinert med brukernavnerom . Spørsmålet dette tar sikte på å svare på er: «Hva skjer hvis containeren faktisk slipper unna?»

Brukernavnområder lar deg omordne containerens UID 0 til en ikke-privilegert UID på verten . Med andre ord, inne i containeren tror applikasjonen at den er root, men fra vertens perspektiv er den prosessen faktisk en vanlig bruker med et tilordnet subuid/subgid-område.

På denne måten, selv om en angriper får rotrettigheter inne i containeren og klarer å kjede en kjerne- eller runtime-utnyttelse, gjør de det som en uprivilegert bruker når de returnerer til verten . De kan ikke overskrive rotbinærfiler, montere sensitive filsystemer eller manipulere enheter der de mangler de nødvendige rettighetene.

Podman ble designet fra starten av med denne modellen i tankene: rotløs containerisering som standard når det er mulig , bruk av SELinux/AppArmor og cgroups selv uten root, og en sterk vekt på å minimere strukturelle rettigheter.

Docker tilbyr nå også en ekte rotløs modus , der dockerd og containere befinner seg innenfor et brukernavneområde, i motsetning til den eldre userns-remap der daemonen forble root. Fra et sikkerhetssynspunkt forhindrer dette at en utnyttelse mot dockerd gir automatisk root-tilgang til verten.

Containernettverk med Podman: bro-, verts-, macvlan- og rotløse grensesnitt

Et annet viktig element for sikkerhet og praktisk drift er containernettverket . Podman tilbyr ulike mekanismer for å tilby tilkobling, med særlig vekt på rotløse scenarier.

Podman 4 introduserte netavark, en nettverksdriver som følger CNI-modellen for å gi containere IP-adresser på bronettverk, macvlans osv. Med netavark kobler rootful-containere vanligvis som standard til et nettverk kalt «podman» tilknyttet en Linux-bro (podman0) på verten, med adressering 10.88.0.0/16.

Dette standardbronettverket gir grunnleggende internettforbindelse via SNAT-regler og lar deg eksponere containerporter til verten ved hjelp av `-po --publish`, som genererer DNAT-regler i iptables/nftables. For Docker-kompatibilitet kjører ikke dette nettverket en intern DNS-server.

Vi kan også opprette brukerdefinerte bronettverk , som isolerer grupper av containere fra hverandre og tilbyr intern DNS. Dette lar containere løses etter navn innenfor sitt private nettverk, gjør det enklere å skille tjenester som ikke skal kunne se hverandre, og gir mer kontroll over MTU, brannmurer og andre funksjoner.

I mer avanserte miljøer er det mulig å bruke macvlan- eller ipvlan-nettverk for å koble containere direkte til vertens fysiske nettverk. Macvlan lar containere kommunisere med hverandre, mens ipvlan har en tendens til å isolere dem mer; dette er nyttige alternativer i distribusjoner der hver container må sees på som en ekte vert av resten av nettverket.

Rotløse nettverk: slirp4netns og pasta

Når brukeren ikke er root, blir ting komplisert: en bruker uten rettigheter kan ikke fritt endre det globale nettverksnavnerommet eller opprette vilkårlige grensesnitt, så Podman må ty til brukerområdeløsninger for å tilby tilkobling.

Det er her slirp4netns kommer inn i bildet , den klassiske mekanismen som brukes av Podman rootless . Dette prosjektet oppretter et isolert nettverksmiljø i containeren og bruker kjernens slirp-modul til å utføre adresseoversettelse (NAT) og la containeren få tilgang til internett gjennom vertens nettverk.

I praksis oppretter slirp4netns et TAP-grensesnitt innenfor containerens nettverksnavneområde (for eksempel tap0 med IP 10.0.2.100 og gateway 10.0.2.2) og ruter trafikk via en TCP/IP-stabel implementert i brukerområdet. Det er funksjonelt, men legger til noe overhead og visse begrensninger.

En av disse begrensningene er at ikke-privilegerte brukere ikke kan bruke porter under 1024. Sysctl-parameteren net.ipv4.ip_unprivileged_port_start markerer hvilken port de anses som "ikke-privilegerte" fra (som standard 1024), selv om dette kan justeres nøye hvis sikkerhetsmodellen tillater det.

I Podman 5 er slirp4netns erstattet av pasta som standard rotløs mekanisme . Pasta opererer også utelukkende i brukerområdet, men takket være tap-grensesnittet og nullkopieringsteknikker oppnår den nesten opprinnelig nettverksytelse, noe som reduserer påvirkningen på latens og gjennomstrømning sammenlignet med slirp4netns.

Bro og vertskap for nettverk i rotløse containere

Selv når vi jobber i ikke-root-modus, kan vi koble rotløse containere til standard "podman"-bronettverket ved å bruke `--network=podman`. Dette utnytter netavarks muligheter og tilordner porter til verten med `-p`, akkurat som i rootful-modus.

Det er også mulig å opprette brukerdefinerte bronettverk i rotløse miljøer . I dette tilfellet opprettes ikke broene og tilhørende enheter i vertens globale nettverksnavneområde, men i brukerens navneområde, slik at disse grensesnittene ikke vil være synlige fra verten med en enkel `sudo ip a`-kommando.

For å inspisere disse rotløse broene tilbyr Podman kommandoen `podman unshare --rootless-netns` , som åpner et skall i brukerens nettverksnavneområde. Derfra kan de interne broene observeres, og direkte tilkobling til containerne kan verifiseres.

Denne isolasjonen har en merkelig effekt: Det er kanskje ikke direkte tilkobling fra verten til IP-adressene til disse rotløse containerne.men det fungerer med porter som er tilordnet vertens egen IP-adresse, som fungerer som inngangspunkt til tjenesten.
For kommunikasjon mellom containere lar DNS-serveren som er integrert i det brukerdefinerte bronettverket dem snakke ved navn, noe som forenkler konfigurasjonen av distribuerte applikasjoner betraktelig.

I den andre enden er vertsnettverket (--network=host) , der containeren deler nettverksstakken med verten uten sin egen IP-adresse. I denne modusen, hvis en rotløs container starter en server på port 8080/tcp, vil tjenesten være direkte tilgjengelig på port 8080 til verten, noe som sparer porttilordning men reduserer isolasjon.

Podman Desktop, bildebehandlingsverktøy og lokal orkestrering

For de som foretrekker noe mer visuelt, tilbyr Podman Desktop et grafisk miljø for å administrere containere, pods, bilder og nettverkskonfigurasjoner på utviklingsmaskiner, og fungerer som et direkte alternativ til Docker Desktop, men er avhengig av den daemonløse motoren.

Bilder hentes ved hjelp av `podman pull`, som laster ned fra registrene definert i `/etc/containers/registries.conf` . Hvis bildet er spesifisert uten et registernavn, prøver Podman å finne det i den konfigurerte registerrekkefølgen, ved å bruke `latest`-taggen som standard.

I tillegg til Podman CLI kan vi bruke skopeo som et dedikert verktøy for å administrere, inspisere og kopiere bilder mellom registre og lokale arkiver. Kommandoer som kopier, slett og synkroniser lar oss automatisere synkronisering mellom arkiver, merke bilder for søppelinnsamling og flytte artefakter mellom miljøer.

Når avbildningen er nedlastet, lar `podman run` deg starte containere ved å spesifisere transport og bane (som standard Docker-transport og søk i det konfigurerte registeret). De vanlige alternativene (-d, -p, --name, --pod, osv.) dekker både labscenarier og mer seriøse distribusjoner.

Daglig administrasjon fullføres med `podman ps` for å liste opp containere, `podman stop/start` for å stoppe eller starte eksisterende instanser, og `podman rm` for å fjerne stoppede containere . Hvis en container har blitt endret og vi ønsker å konvertere den til et nytt image, lagrer `podman commit` disse endringene under et nytt navn.

Poder og avanserte utførelsesmodeller med Podman

Inspirert av Kubernetes, lar Podman deg gruppere containere i pods som deler samme nettverksstabel og bestemte ressurser . Det er et perfekt mønster for ting som en database og dens klient, eller flere mikrotjenester som trenger å kommunisere med lav latens.

Kommandoen `podman pod create` oppretter en ny pod og returnerer ID-en, men som standard forblir poden stoppet inntil en tilknyttet container startes eller den eksplisitt startes med `podman pod start`.

For å se hvilke pods som er på systemet, bruk `podman pod ls` , som også vil liste opp INFRA-containeren som er tilknyttet hver enkelt. Denne spesielle containeren holder nettverket og andre delte ressurser i poden i gang, slik at antallet containere aldri er null.

Podman tilbyr spesifikke kommandoer for å starte, stoppe eller starte hele pods på nytt (podman pod start/stop/restart) , men vi kan også bare handle på en bestemt beholder i pod-en uten å endre resten, og dermed opprettholde prosessisolasjon på applikasjonsnivå.

For å legge til flere containere i en eksisterende pod, bruk `podman run --pod POD_NAME` , og følg samme syntaks som for individuelle containere. Du kan ikke fjerne en container fra en pod uten å ødelegge den, ettersom pod-medlemskap er knyttet til livssyklusen.

Overvåking fullføres med podman ps –pod eller spesifikke kommandoer for å overvåke prosessene til alle containere i alle pods , og raskt identifisere hva som tilhører hvilken gruppe og hvordan tjenestene er distribuert.

Containere, LXC og applikasjonsvirtualisering

Selv om Docker og Podman dominerer samtalen, er de ikke de eneste containeriseringsalternativene i GNU/Linux . Løsninger som LXC/LXD, systemd-nspawn og Kata Containers adresserer problemet fra litt forskjellige vinkler.

LXC tilbyr svært lette systemcontainere, med eget vertsnavn, IP-adresse, filsystem og komplett init-system . Kombinert med LXD, som fungerer som en hypervisor for containere og virtuelle maskiner, leverer den en opplevelse som er svært lik flere lette maskiner med tilnærmet bare-metal-ytelse.

Mens Docker/Podman fokuserer på OCI-kompatible applikasjonscontainere , skinner LXC når det er behov for vedvarende miljøer med flere tjenester og prosesser, og oppfører seg som en VM, men med mindre overhead og en veldig naturlig integrasjon med Linux-kjernen.

Fra et ytelsessynspunkt kan LXC kjøre dataintensive bedriftsapplikasjoner praktisk talt uten straff , noe som gjør det til et kraftig valg for latensfølsomme arbeidsbelastninger som ikke krever den sterke isolasjonen til en tradisjonell virtuell maskin.

Ved siden av dette har teknologier rettet mot mikro-VM-er og forbedret isolasjon også fått fotfeste, som Kata Containers , som starter hver pod i en liten virtuell maskin med sin egen kjerne, eller gVisor, som setter inn en "kernel sandbox" skrevet i Go mellom applikasjonen og Linux. Begge reduserer avhengigheten av den delte kjernen og beveger seg nærmere sikkerhetsmodellen til virtuelle maskiner, samtidig som de opprettholder brukervennligheten til containere.

Beste praksis for herding av Docker og Podman

Med alt det ovennevnte er den rimelige tilnærmingen til en robust containerplattform å jobbe i lag: segmentering med navnerom/cgroups, filtreringspolicyer med seccomp og MAC, og strukturell rettighetsbegrensning gjennom rotløs modus.

I praksis er det lurt å bruke standardpraksisen med å kjøre containere i ikke-root-modus når det er mulig , spesielt i miljøer med flere leietakere eller i delte skyer. Podman tilrettelegger dette som standard, og Docker rootless dekker den samme filosofien når kompatibilitet er nødvendig.

Vertskjernen må holdes oppdatert med sikkerhetsoppdateringer . Sårbarheter som Dirty COW, Dirty Pipe og andre håndteres med oppdateringer som må implementeres relativt raskt hvis vi ikke vil la døren stå åpen for containerrømming.

Et annet svært effektivt tiltak er å bruke uforanderlige, containerorienterte distribusjoner, som openSUSE MicroOS eller Flatcar Linux . Deres skrivebeskyttede rot- og atomoppdateringssystem reduserer angrepsflaten betraktelig og forenkler tilbakerulling hvis noe går galt etter en oppdatering.

Angående konfigurasjon: ingen privilegerte containere i produksjon unntatt i ekstremt kontrollerte tilfeller , ikke kjør applikasjoner som root inne i containeren, bruk skrivebeskyttede filsystemer når det er mulig, og begrens funksjonaliteten til et absolutt minimum. SELinux/AppArmor- og seccomp-profiler skreddersydd til applikasjonens faktiske kall er praktisk talt obligatoriske.

Til slutt må vi ikke glemme aspektet ved kjøretidsovervåking . Verktøy som Falco, Sysdig Secure eller Aqua hjelper med å oppdage avvik, forsøk på å unngå feil (som uvanlig tilgang til /proc eller /sys), atypisk nettverkstrafikk eller mistenkelige kommandoer, noe som gir tid til å reagere før angrepet tar overhånd.

Ved å kombinere klassisk virtualisering med KVM, containere administrert av Podman (helst i rotløs modus), godt segmenterte nettverk og gode herdingspraksiser, kan en svært fleksibel og ganske sikker virtualiseringsplattform bygges. Å forstå at den delte kjernen er det viktigste punktet, å stole på virtuelle maskiner eller mikro-VM-er når risiko eller samsvar med regelverk krever det, og å nøye administrere imageforsyningskjeden utgjør forskjellen mellom et laboratoriemiljø og en produksjonsklar infrastruktur.