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

Informatic Digital » Recursos » Podman, KVM og containere: en praktisk guide til sikker virtualisering

Når du begynder at opsætte et seriøst containermiljø på Linux, opstår det samme spørgsmål straks: I hvilken grad er det sikkert udelukkende at bruge containere, og hvornår er det tilrådeligt at opgradere med KVM eller mikro-VM'er? I virksomhedsmiljøer, hvor Docker-, Podman-, LXC-, KVM-virtuelle maskiner og forskellige hypervisorer blandes, er det vigtigt at forstå isolationsmodellen godt for at undgå fejl.

Desuden er noget indviklede scenarier ikke ualmindelige, som f.eks. Prøv at bruge Docker Desktop eller Podman i en virtuel maskine i VirtualBox eller KVMDette involverer flere niveauer af virtualisering (indlejret eller ej), og det er nemt at støde på fejl som "KVM er ikke aktiveret på værten." Lad os organisere alle disse dele: containere, VM'er, Podman, KVM, netværk og sikkerhed, og se, hvordan man kombinerer dem for at opnå virkelig sikker og praktisk virtualisering.

Klassisk virtualisering med KVM og virtuelle maskiner

Fundamentet for hele denne opsætning er fortsat virtualisering af operativsystemer fuldfør ved hjælp af hypervisorer som KVM, Xen eller ESXiHer kører den fysiske hardware en hypervisor, der er ansvarlig for at "opdele" maskinen i flere uafhængige virtuelle maskiner.

I denne model starter hver virtuel maskine sin egen kerne og sit eget gæsteoperativsystemfuldstændig adskilt fra værten. Hypervisoren (for eksempel KVM, integreret i Linux-kernen) fungerer som en beskytter mellem hardwaren og de virtuelle maskiner og er ansvarlig for den stærke isolation mellem dem.

Vi taler generelt om to typer hypervisorer: type 1 eller bare metal, som monteres direkte på hardwaren, og type 2, som hostes på et eksisterende operativsystem. VirtualBox eller VMware Workstation ville være type 2Hvorimod en KVM administreret af libvirt på en Linux-server er tættere på et type 1-scenarie, selvom den deler plads med selve værten.

Den største fordel ved denne tilgang er, at Hver VM har sin egen komplette stak: kerne, brugerplads, tjenester, netværk, lagerpladsDette giver en stor fleksibilitet og muligheden for at køre forskellige operativsystemer og kerneversioner på den samme fysiske maskine.

For at administrere disse virtualiserede platforme i GNU/Linux bruger man næsten altid libvirt som en orkestrerings-API, hvortil grafiske og kommandolinjeværktøjer understøttes, eller større projekter som OpenStack, der bygger hele clouds ved at kombinere VM'er, bare metal og containere.

Hardwarekrav og almindelige problemer med KVM

Før du kører KVM eller bruger løsninger, der er afhængige af den (f.eks. visse Docker Desktop- eller micro-VM-konfigurationer), skal du sørge for, at Processoren understøtter hardwarevirtualisering (VT-x på Intel eller SVM/AMD-V på AMD) og hvad der er aktiveret i BIOS/UEFI.

I Linux har vi en hurtig kontrol: hvis kommandoen grep -E 'svm|vmx' /proc/cpuinfo Hvis den ikke returnerer noget, eller hvis indstillingen forbliver deaktiveret i firmwaren, vil KVM ikke fungere. Desuden skal topniveau-hypervisoren i scenarier, hvor vi kører VM'er inde i en anden VM (indlejret virtualisering), eksplicit eksponere disse udvidelser for gæsten.

Når noget går galt, vises typiske meddelelser, såsom den berømte Docker Desktop-popup i RHEL 9 i VirtualBox: "KVM er ikke aktiveret på værten"Problemet her ligger ikke direkte i Docker eller RHEL, men i at VirtualBox VM ikke modtager de nødvendige virtualiseringsudvidelser til at køre KVM i den.

Kommandoer som modprobe kvm o modprobe kvm_amd / kvm_intel Kernelmodulerne burde indlæses uden fejlmeddelelser. Hvis der ikke vises noget relevant i dmesg, eller lsmod | grep kvm Den viser kun "bare" KVM og IRQ BYPASS, og de specifikke CPU-moduler mangler; det er meget sandsynligt, at Hardwarevirtualisering bliver ikke eksponeret til gæstesystemet eller er deaktiveret i firmwaren.

I disse scenarier, selvom alt muligt er aktiveret i værten, Hvis VirtualBox ikke tilbyder indlejret virtualisering, eller hvis den er forkert konfigureret, vil KVM simpelthen ikke være brugbar.Løsningen involverer at kontrollere konfigurationen af ​​værtshypervisoren (VirtualBox, VMware osv.) og aktivere indlejret virtualisering, hvis det er muligt.

Containere: Let virtualisering på operativsystemniveau

Sammenlignet med traditionelle VM'er tilbyder containere en alternativ tilgang: Ikke al hardware emuleres; i stedet genbruges værtskernen. og processer og ressourcer isoleres ved hjælp af Linux-kernefunktioner.

En container er stadig et sæt af indkapslede processer ved hjælp af navnerum og cgroupsInden for dette "miljø" tror applikationen, at den kører på sin egen maskine med sit filsystem, netværksgrænseflader og PID'er, men i virkeligheden deler den kernen med værten.

Containere tilbyder næsten native ydeevne, fordi Der er ingen anden kerne involveret, og heller ikke fuld hardwareemulering.Overheadomkostningerne er små: lige nok til at opsætte navnerummene, begrænse ressourcer med cgroups og anvende sikkerhedspolitikker (seccomp, AppArmor, SELinux osv.).

Dette design har dog en vigtig konsekvens: Alle nyttelast deler den samme fysiske kerneEn alvorlig sårbarhed i den kerne kan pludselig blive en potentiel undslipsvektor for alle containere, der kører på den node.

Derfor taler folk ofte om containerisolering. Den er ikke "absolut" som en virtuel maskineHvis nogen formår at udnytte en kritisk kernefejl, ophører navnerum med at være en effektiv barriere, og grænserne mellem containere og værter kan brydes.

Navnerum og c-grupper: fundamentet for containerisolering

I Linux er containerisolering bygget på to hovedsøjler: navnerum til at adskille systemvisninger y cgroups til at begrænse og redegøre for ressourcer.

Navnerum isolerer ting som PID'er, netværk, monteringspunkter, IPC, værtsnavn (UTS) og brugerePå denne måde "ser" en proces kun processerne, netværksgrænsefladerne, filsystemet og værtsnavnet i sit eget navnerum, hvilket giver den følelsen af ​​at være på et andet system.

For deres vedkommende tillader cgroups Angiv hvor meget CPU, hukommelse, disk-I/O, antal processer osv. en container kan forbrugeDette forhindrer en ukontrolleret belastning i at mætte hele værten, hvilket er afgørende, når noder deles mellem teams eller projekter.

Det er dog vigtigt at være helt klar over, at Navnerum og cgroups alene er ikke et komplet sikkerhedssystemDe blokerer ikke udnyttelsen af ​​kernesårbarheder, de filtrerer ikke systemkald, og de administrerer ikke detaljerede adgangspolitikker. De er fundamentet, men det skal styrkes.

Den fornuftige måde at styrke miljøet på er at kombinere syscall-filtre med seccomp, MAC-politikker (AppArmor eller SELinux) og en drastisk reduktion i funktioner af processerne, ideelt set sammen med brugernavnerum og rodløs tilstand for at minimere skade, hvis nogen formår at forlade containeren.

Sikkerhedstrusler på containerplatforme

I en rigtig containerplatform er angrebsfladen spredt over flere lag: kernen og runtime (runc, containerd, CRI-O), image-forsyningskæden, container-/orkestrator-konfigurationen og den underliggende infrastruktur (cloud, lagring, IAM, netværk).

Typiske angrebsvektorer inkluderer software sårbarheder i kernen eller container-runtime, brug af usikre eller ikke-vedligeholdte billeder, konfigurationsfejl i Kubernetes eller Docker (privilegerede containere, farlige værtmonteringer, overdrevent åbne netværkstilstande) og sikkerhedsfejl i CI/CD-registre eller pipelines.

I mange hændelser i det virkelige liv er der ikke en isoleret "magisk bug", men en kombination af kendt sårbarhed plus slap konfigurationcontainere, der kører som root, brug af flaget –privilegeret, montering af værtsfilsystemet inde i containeren og fravær af seccomp eller MAC.

Derudover kommer problemet med forsyningskæden: Offentlige basebilleder indeholder ofte CVE'er, forældede pakker og dårligt kontrollerede afhængigheder.Det er relativt nemt for malware at snige sig ind, eller for et kompromitteret bibliotek at forblive inaktivt, indtil betingelserne for udførelse opstår.

Derfor er det ikke valgfrit i produktionen: Billeder skal scannes for sårbarheder ved hjælp af værktøjer som Trivy, Clair eller Grype.Kontroller, hvilke registre der bruges (Harbor, Quay, GHCR med politikker), og signer/verificer billederne, før de implementeres i klyngen.

Docker vs. Podman: Indvirkning på trusselsmodellen

Inden for applikationscontainernes verden dækker Docker og Podman lignende funktioner, men Dens arkitektur er betydeligt anderledes, og det ændrer sikkerhedsmodellen. som vi arbejder med på en vært.

Docker er i sin klassiske rootful-tilstand afhængig af en central daemon (dockerd), der kører som rootCLI'en kommunikerer med denne daemon via /var/run/docker.sock eller via TCP, og det er denne privilegerede proces, der opretter og ødelægger containere, administrerer billeder, netværk og volumener, og kommunikerer med registrene.

Dette indebærer det Enhver med adgang til Docker-socket'en har i bund og grund root-adgang til værten.Fordi den kan starte privilegerede containere, montere vilkårlige filsystemer og ændre kritisk konfiguration, bliver dæmonen effektivt et enkelt fejlpunkt.

Podman blev derimod født med ideen om at være en containermotor uden en daemon og så "native" som muligt på LinuxDer er ingen permanent central proces; containere afhænger af brugeren eller systemd, og integration med sidstnævnte gør det muligt at styre containere via serviceenheder.

Denne tilgang passer bedre til Unix-modellen om, at "hver proces tilhører den bruger, der starter den", og undgå at være afhængig af en højt privilegeret dæmonDerudover tilbyder Podman kompatibilitet med Docker-kommandoer, hvilket forenkler migrering (du kan endda bruge alias docker=podman i miljøer, hvor du ikke ønsker at installere Docker CE).

Rodløs tilstand og brugernavnerum

Et af de største praktiske fremskridt i forhold til at reducere virkningen af ​​en potentiel beholderlækage er rodløs tilstand kombineret med brugernavnerumSpørgsmålet, der behandles her, er: "Hvad sker der, hvis beholderen til sidst slipper ud?"

Brugernavneområder tillader Omformuler container-UID 0 til et ikke-privilegeret UID på værtenMed andre ord, i containeren tror applikationen, at den er root, men fra værtens perspektiv er den proces faktisk en almindelig bruger med et tildelt subuid/subgid-område.

På denne måde, selvom en angriber får root-rettigheder inde i containeren og formår at kæde en kerne- eller runtime-exploit sammen, Når den vender tilbage til værten, gør den det som en bruger uden rettigheder.Du kan ikke overskrive rodbinære filer, montere følsomme filsystemer eller manipulere enheder, hvor du ikke har de nødvendige funktioner.

Podman blev designet fra starten med denne model i tankerne: Rodløs containerisering som standard, når det er muligt, brug af SELinux/AppArmor og cgroups selv uden root, og en stærk vægt på at minimere strukturelle privilegier.

Docker har også en "Ægte" rodløs tilstandI dette miljø befinder Dockerd og dets containere sig i et brugernavneområde, i modsætning til det ældre `userns-remap`-system, hvor dæmonen forblev root. Fra et sikkerhedsmæssigt synspunkt forhindrer dette en udnyttelse mod Dockerd i at give automatisk root-adgang til værten.

Containernetværk med Podman: bridge-, host-, macvlan- og rootless-grænseflader

Et andet vigtigt element for sikkerhed og praktisk drift er containernetværkslagPodman tilbyder forskellige mekanismer til at skabe forbindelse, med særlig vægt på rodløse scenarier.

Podman 4 introduceret Netavark, en netværksdriver, der følger CNI-modellen at forsyne containere med IP-adresser på bro-netværk, macvlan osv. Med NetAvark opretter rootful-containere normalt forbindelse som standard til et netværk kaldet "podman", der er tilknyttet en Linux-bro (podman0) på værten med adresseringen 10.88.0.0/16.

Dette standardbronetværk leverer Grundlæggende internetforbindelse via SNAT-regler Det giver dig mulighed for at eksponere containerporte til værten ved hjælp af `-po --publish`, som genererer DNAT-regler i iptables/nftables. For Docker-kompatibilitet aktiverer dette netværk ikke en intern DNS-server.

Vi kan også skabe brugerdefinerede bronetværkDisse løsninger isolerer grupper af containere fra hinanden og tilbyder intern DNS. Dette gør det muligt for containere at identificere hinanden ved navn inden for deres private netværk, gør det nemmere at adskille tjenester, der ikke burde kunne se hinanden, og giver mere kontrol over MTU, firewalls og andre indstillinger.

I mere avancerede miljøer er det muligt at bruge macvlan- eller ipvlan-netværk til at forbinde containere direkte til det fysiske netværk Macvlan tillader containere at kommunikere med hinanden, mens ipvlan har en tendens til at isolere dem mere; disse er nyttige muligheder i implementeringer, hvor hver container skal ses som en reel vært af resten af ​​netværket.

Rodløse netværk: slirp4netns og pasta

Når brugeren ikke er root, bliver tingene komplicerede: En bruger uden privilegier kan ikke frit ændre det globale netværksnavneområde ej heller oprette vilkårlige grænseflader, så Podman er nødt til at ty til brugerrumsløsninger for at levere konnektivitet.

Det er her, det kommer i spil slirp4netns, den klassiske mekanisme brugt af Podman rootlessDette projekt opretter et isoleret netværksmiljø i containeren og bruger kernens slirp-modul til at oversætte adresser (NAT) og give containeren adgang til internettet via værtens netværk.

I praksis, slirp4netns opretter en TAP-grænseflade i containerens netværksnavneområde (for eksempel tap0 med IP 10.0.2.100 og gateway 10.0.2.2) og ruter trafik via en TCP/IP-stak implementeret i brugerområdet. Det er funktionelt, men tilføjer noget overhead og visse begrænsninger.

En af disse begrænsninger er, at Ikke-privilegerede brugere kan ikke bruge porte under 1024Parameteren sysctl net.ipv4.ip_unprivileged_port_start markerer, hvilken port der betragtes som "ikke-privilegeret" (som standard 1024), selvom den kan justeres omhyggeligt, hvis sikkerhedsmodellen tillader det.

I Podman 5 er slirp4netns erstattet af indsæt som en rodløs mekanisme som standardPasta fungerer også udelukkende i brugerområdet, men takket være tap-grænsefladen og zero-copy-teknikkerne opnår den næsten native netværksydelse, hvilket reducerer påvirkningen på latenstid og gennemløb sammenlignet med slirp4netns.

Bro og vært netværk i rootless containere

Selv når vi arbejder i ikke-root-tilstand, kan vi Forbind rodløse containere til standard "podman"-bronetværket ved hjælp af –network=podman. Dette udnytter netavarks muligheder og knytter porte til værten med -p, ligesom i rootful-tilstand.

Det er også muligt at skabe brugerdefinerede bronetværk i rodløse miljøerI dette tilfælde oprettes broerne og tilhørende enheder ikke i værtens globale netværksnavnerum, men i brugerens navnerum, så fra værten vil vi ikke se disse grænseflader med en simpel sudo ip a.

For at inspicere disse rodløse broer tilbyder Podman kommandoen podman unshare –rootless-netnsDette åbner en shell i brugerens netværksnavneområde. Derfra kan de interne broer observeres, og direkte forbindelse til containerne kan verificeres.

Denne isolation har en mærkelig effekt: Der er muligvis ikke direkte forbindelse fra værten til IP'erne for disse rodløse containere.men det virker med porte, der er knyttet til værtens egen IP-adresse, som fungerer som indgangspunkt til tjenesten.
Til kommunikation mellem containere tillader den DNS-server, der er integreret i det brugerdefinerede bronetværk, at de taler ved navn, hvilket i høj grad forenkler konfigurationen af ​​distribuerede applikationer.

I den anden ende er værtsnetværket (–network=host)I denne tilstand deler containeren netværksstakken med værten uden sin egen IP-adresse. Hvis en rootless container starter en server på port 8080/tcp, vil tjenesten være direkte tilgængelig på værtens port 8080, hvilket sparer portmapping, men reducerer isolation.

Podman Desktop, billeddannelsesværktøjer og lokal orkestrering

For dem, der foretrækker noget mere visuelt, Podman Desktop leverer et grafisk miljø til at administrere containere, pods, billeder og netværkskonfigurationer på udviklingsmaskiner, der fungerer som et direkte alternativ til Docker Desktop, men er afhængig af den daemonless-motor.

Billedoptagelse udføres med Kommandoen `podman pull` downloader fra de registre, der er defineret i `/etc/containers/registries.conf`.Hvis vi angiver billedet uden et postnavn, forsøger Podman at finde det i den konfigurerede postrækkefølge og bruger som standard det nyeste tag.

Udover Podmans CLI kan vi også bruge skopeo som et specifikt værktøj til at administrere, inspicere og kopiere billeder mellem lokale registre og lagre. Kommandoer som kopiér, slet eller synkroniser giver dig mulighed for at automatisere synkronisering mellem lagre, markere billeder til garbage collection eller flytte artefakter mellem miljøer.

Når billedet er downloadet, Podman Run tillader start af containere ved at angive transport og rute (Som standard transporterer og søger Docker i de konfigurerede registre). De sædvanlige indstillinger (-d, -p, --name, --pod osv.) dækker både laboratoriescenarier og mere seriøse implementeringer.

Daglig ledelse er afsluttet med `podman ps` til at liste containere, `podman stop / start` til at stoppe eller starte eksisterende instanser, og `podman rm` til at fjerne stoppede containere.Hvis en container er blevet ændret, og vi ønsker at konvertere den til et nyt billede, gemmer podman commit disse ændringer under et nyt navn.

Pods og avancerede udførelsesmodeller med Podman

Inspireret af Kubernetes, tillader Podman grupper containere i pods, der deler den samme netværksstak og bestemte ressourcerDet er et perfekt mønster til ting som en database og dens klient, eller flere mikrotjenester, der skal kommunikere med lav latenstid.

Kommandoen `podman pod create` opretter en ny pod og returnerer sit ID, men som standard forbliver pod'en stoppet, indtil en tilknyttet container startes, eller den eksplicit startes med podman pod start.

For at se hvilke pods der er i systemet, bruger du Podman pod lsDette vil også vise den INFRA-container, der er knyttet til hver enkelt. Denne særlige container holder netværket og andre delte ressourcer i pod'en i live, så antallet af containere aldrig er nul.

Podman tilbyder specifikke kommandoer til start, stop eller genstart hele pods (podman pod start/stop/genstart)Men vi kan også kun handle på en specifik container i poden uden at ændre resten, og dermed opretholde procesisolation på applikationsniveau.

For at tilføje flere containere til en eksisterende pod, bruger du podman løb –pod POD_NAMEFølger samme syntaks som for individuelle containere. En container kan ikke "fjernes" fra en pod uden at ødelægge den, da pod-medlemskab er knyttet til dens livscyklus.

Supervisionen er afsluttet med `podman ps --pod` eller specifikke kommandoer til at overvåge processerne i alle containere i alle pods, hurtigt at identificere, hvad der tilhører hvilken gruppe, og hvordan tjenesterne er fordelt.

Containere, LXC og applikationsvirtualisering

Selvom Docker og Podman dominerer samtalen, Dette er ikke de eneste containeriseringsmuligheder i GNU/LinuxDer findes løsninger som LXC/LXD, systemd-nspawn eller Kata Containers, der griber problemet an fra lidt forskellige vinkler.

LXC leverer Meget lette systemcontainere med deres eget værtsnavn, IP, filsystem og en komplet init.I kombination med LXD, der fungerer som hypervisor for containere og VM'er, får du en oplevelse, der er meget tæt på at have flere letvægtsmaskiner med næsten bare metal-ydeevne.

Mens Docker/Podman fokuserer på OCI-kompatible applikationscontainereLXC er fremragende, når der er behov for persistente miljøer med flere tjenester og processer, der opfører sig som en VM, men med mindre overhead og en meget naturlig integration med Linux-kernen.

Fra et præstationssynspunkt, LXC kan køre dataintensive virksomhedsapplikationer stort set uden ulemper.Dette gør den til en effektiv løsning til latenstidsfølsomme arbejdsbelastninger, der ikke kræver den stærke isolation, som en traditionel VM tilbyder.

Samtidig med dette har de også fået styrke Teknologier rettet mod mikro-VM'er og forstærket isolation såsom Kata ContainersDisse muligheder starter hver pod i en lille virtuel maskine med sin egen kerne, mens gVisor indsætter en Go-skrevet "kernel sandbox" mellem applikationen og Linux. Begge reducerer afhængigheden af ​​den delte kerne og nærmer sig sikkerhedsmodellen for VM'er, samtidig med at containernes ergonomi bevares.

Bedste fremgangsmåder til hærdning af Docker og Podman

I betragtning af alt ovenstående er den rimelige tilgang til en robust containerplatform at arbejde i lag: Segmentering med navnerum/cgroups, filtreringspolitikker med seccomp og MAC og strukturel privilegiebegrænsning ved hjælp af rootless-tilstand.

I praksis er det tilrådeligt at anvende som standard, at Containere bør køre i ikke-root-tilstand, når det er muligt.især i miljøer med flere lejere eller i delte clouds. Podman muliggør dette direkte, og Docker rootless følger den samme filosofi, når kompatibilitet er påkrævet.

Værtskernen skal hold dig opdateret med sikkerhedsrettelserSårbarheder som Dirty COW, Dirty Pipe og andre løses med opdateringer, der skal implementeres relativt hurtigt, hvis vi ikke vil lade døren stå åben for containerudslip.

En anden meget effektiv foranstaltning er at bruge Uforanderlige containerorienterede distributioner, såsom openSUSE MicroOS eller Flatcar LinuxDets skrivebeskyttede root- og atomare opdateringssystem reducerer angrebsfladen betydeligt og letter rollback, hvis noget går galt efter en patch.

Angående konfiguration: Ingen privilegerede containere i produktion undtagen i hyperkontrollerede tilfældeKør ikke applikationer som root inde i containeren, brug skrivebeskyttede filsystemer når det er muligt, og begræns mulighederne til et absolut minimum. SELinux/AppArmor- og seccomp-profiler, der er skræddersyet til applikationens faktiske kald, er næsten obligatoriske.

Endelig må vi ikke glemme den del, der handler om overvågning af udførelsestidVærktøjer som Falco, Sysdig Secure eller Aqua hjælper med at opdage anomalier, forsøg på at undgå angreb (f.eks. usædvanlig adgang til /proc eller /sys), atypisk netværkstrafik eller mistænkelige kommandoer, hvilket giver tid til at reagere, før angrebet tager fat.

Ved at kombinere klassisk virtualisering med KVM, containere administreret af Podman (helst i rootless-tilstand), velsegmenterede netværk og gode hærdningspraksisser kan der opbygges en yderst fleksibel og ret sikker virtualiseringsplatform. Forståelse for, at den delte kerne er det mest kritiske punkt, afhængighed af VM'er eller mikro-VM'er, når risiko eller overholdelse af lovgivning kræver det, og omhyggelig styring af imageforsyningskæden gør forskellen mellem et laboratoriemiljø og en produktionsklar infrastruktur.