Podman, KVM i contenidors: guia pràctica de virtualització segura

Informatec Digital » Recursos » Podman, KVM i contenidors: guia pràctica de virtualització segura

Quan comences a muntar un entorn seriós de contenidors a Linux, de seguida apareix el mateix dubte: fins a quin punt és segur recolzar-se només en contenidors i quan convé pujar el nivell amb KVM o micro-VMs? En entorns corporatius, on es barregen Docker, Podman, LXC, màquines virtuals KVM i diferents hipervisors, entendre bé el model d'aïllament és clau per no ficar la pota.

A més, no són rars els escenaris una mica enrevessats, com intentar utilitzar Docker Desktop o Podman dins d'una màquina virtual a VirtualBox o KVM , on entren en joc diversos nivells de virtualització (anidada o no) i és fàcil trobar-se amb errors tipus “KVM no està habilitat al host”. Ordenarem totes aquestes peces: contenidors, VMs, Podman, KVM, xarxes i seguretat, i veure com combinar-les per aconseguir una virtualització realment segura i pràctica.

Virtualització clàssica amb KVM i màquines virtuals

La base de tot aquest tinglado segueix sent la virtualització de sistemes operatius completa mitjançant hipervisors com KVM, Xen o ESXi . Aquí el maquinari físic executa un hipervisor que s'encarrega de “partir” la màquina a diverses màquines virtuals independents.

En aquest model, cada màquina virtual arrenca el seu propi nucli i el seu propi sistema operatiu convidat totalment separat del host. L'hipervisor (per exemple KVM, integrat al nucli de Linux) actua com a guardià entre el maquinari i les VMs, i és el responsable de l'aïllament fort entre elles.

Parlem generalment de dos tipus d'hipervisor: els de tipus 1 o bar metall, que van directament sobre el maquinari, i els de tipus 2, allotjats sobre un sistema operatiu existent. VirtualBox o VMware Workstation serien de tipus 2 , mentre que un KVM gestionat per libvirt en un servidor Linux s'acosta més a un escenari de tipus 1, encara que comparteixi espai amb el propi host.

El benefici més gran d'aquest enfocament és que cada VM té la seva pila completa: nucli, espai d'usuari, serveis, xarxa, emmagatzematge . Això aporta molta flexibilitat i la possibilitat d'executar diferents sistemes operatius i versions de kernel a la mateixa màquina física.

Per gestionar aquestes plataformes virtualitzades a GNU/Linux es recorre gairebé sempre a libvirt com a API d'orquestració , sobre la qual es recolzen eines gràfiques i de línia d'ordres, o projectes més grans com OpenStack, que munta núvols complets combinant VMs, bar metall i contenidors.

Requisits de maquinari i problemes habituals amb KVM

Abans de ficar-se a executar KVM oa utilitzar solucions que en depenen (com algunes configuracions de Docker Desktop o de micro-VMs), cal assegurar-se que el processador suporta virtualització per maquinari (VT-x a Intel o SVM/AMD-V a AMD) i que està activada a la BIOS/UEFI.

A Linux tenim una comprovació ràpida: si l'ordre grep -E 'svm|vmx' /proc/cpuinfo no torna res, o l'opció continua desactivada al microprogramari, KVM no funcionarà. A més, en escenaris on correrem VMs dins d'una altra VM (virtualització imbricada), l'hipervisor de primer nivell ha d'exposar explícitament aquestes extensions a l'hoste.

Quan alguna cosa falla, apareixen missatges típics com el famós popup de Docker Desktop a RHEL 9 dins de VirtualBox: “KVM no està habilitat al host” . Aquí el problema no és a Docker ni a RHEL directament, sinó que la VM de VirtualBox no rep les extensions de virtualització necessàries per muntar KVM al seu interior.

Comandes com modprobe kvm o modprobe kvm_amd / kvm_intel haurien de carregar els mòduls del nucli sense missatges d'error. Si no apareix res rellevant a dmesg, o lsmod | grep kvm només mostra kvm “pelat” i irqbypass i falten els mòduls específics de la CPU, és molt probable que la virtualització per maquinari no s'estigui exposant al sistema convidat o estigui desactivada al microprogramari.

En aquests escenaris, encara que s'activi tot el possible dins de l'hoste, si VirtualBox no ofereix virtualització niada o està mal configurada, KVM simplement no es podrà utilitzar . La solució passa per revisar la configuració de l'hipervisor amfitrió (VirtualBox, VMware, etc.) i habilitar nested virtualization si està disponible.

Contenidors: virtualització lleugera a nivell de sistema operatiu

Davant les VMs tradicionals, els contenidors proposen una altra via: no s'emula tot el maquinari, sinó que es reutilitza el nucli del host i s'aïllen processos i recursos mitjançant funcions del nucli de Linux.

Un contenidor no deixa de ser un conjunt de processos encapsulats usant namespaces i cgroups . Dins d'aquest “entorn”, l'aplicació creu que corre a la pròpia màquina, amb el sistema de fitxers, les interfícies de xarxa i els PIDs, però en realitat comparteix nucli amb el host.

Els contenidors ofereixen un rendiment gairebé nadiu, perquè no hi ha un segon nucli per mitjà ni emulació de maquinari completa . El overhead és petit: just per muntar els espais de noms, restringir recursos amb cgroups i aplicar polítiques de seguretat (seccomp, AppArmor, SELinux, etc.).

Ara bé, aquest disseny porta una conseqüència important: totes les càrregues comparteixen el mateix nucli físic . Una vulnerabilitat greu en aquest nucli es pot convertir de cop en un possible vector d'escapament per a tots els contenidors que s'executen en aquest node.

Per això se sol parlar que l'aïllament de contenidors no és absolut com el d'una màquina virtual . Si algú aconsegueix explotar un bug crític del nucli, els namespaces deixen de ser un mur efectiu i es poden trencar els límits entre contenidors i host.

Namespaces i cgroups: la base de l´aïllament en contenidors

A Linux, l'aïllament de contenidors es construeix sobre dos pilars principals: namespaces per separar vistes del sistema i cgroups per limitar i comptabilitzar recursos.

Els namespaces aïllen coses com PIDs, xarxa, punts de muntatge, IPC, hostname (UTS) i usuaris . D'aquesta manera, un procés només “veu” els processos, les interfícies de xarxa, el sistema de fitxers i el nom de host del seu propi namespace, cosa que li fa la sensació d'estar en un sistema diferent.

Per la seva banda, els cgroups permeten marcar quanta CPU, memòria, I/O de disc, nombre de processos, etc. pot consumir un contenidor . Així s'evita que una càrrega descontrolada saturi tot el host, cosa essencial quan es comparteixen nodes entre equips o projectes.

No obstant això, convé tenir molt clar que namespaces i cgroups per si sols no són un sistema de seguretat complet . No bloquegen l'explotació de fallades del nucli, no filtren trucades al sistema ni gestionen polítiques d'accés fines. Són la base, però cal reforçar-la.

La manera assenyada d'endurir l'entorn passa per combinar filtres de syscalls amb seccomp, polítiques MAC (AppArmor o SELinux) i una reducció dràstica de capacitats dels processos, idealment juntament amb namespaces d'usuari i mode sense root (rootless) per minimitzar el mal si algú aconsegueix sortir del contenidor.

Amenaces de seguretat en plataformes de contenidors

En una plataforma real de contenidors, la superfície d'atac es reparteix en diverses capes: el kernel i el runtime (runc, containerd, CRI-O), la cadena de subministrament d'imatges, la configuració de contenidors/orquestradors i la infraestructura subjacent (núvol, emmagatzematge, IAM, xarxa).

Els vectors d'atac habituals inclouen vulnerabilitats de programari al nucli o al runtime del contenidor, utilitzar imatges insegures o sense manteniment, cometre errors de configuració a Kubernetes o Docker (contenidors privilegiats, muntatges perillosos de l'amfitrió, modes de xarxa excessivament oberts), i errors de seguretat en registres o pipelins de CI/CD.

En moltíssims incidents reals no hi ha un “bug màgic” aïllat, sinó una combinació de vulnerabilitat coneguda més configuració laxa : contenidors corrent com a root, ús del flag –privileged, muntatges del sistema de fitxers del host dins del contenidor i absència de seccomp o MAC.

A tot això se suma la qüestió de la cadena de subministrament: les imatges base públiques solen arrossegar CVEs, paquets obsolets i dependències poc controlades . És relativament fàcil que es coli malware o que una llibreria compromesa quedi latent fins que es donin les condicions per executar-se.

Per això, en producció no és opcional: cal escanejar imatges buscant vulnerabilitats amb eines com Trivy, Clair o Grype , controlar quins registres es fan servir (Harbor, Quay, GHCR amb polítiques) i signar/verificar les imatges abans de desplegar-les en clúster.

Docker vs Podman: impacte en el model d'amenaces

Dins del món de contenidors d'aplicacions, Docker i Podman cobreixen funcions semblants, però la seva arquitectura difereix força i això canvia el model de seguretat amb què treballem en un host.

Docker, en la seva manera clàssica rootful, es recolza en un dimoni central (dockerd) que corre com a root . La CLI es comunica amb aquest dimoni mitjançant /var/run/docker.sock o mitjançant TCP, i és aquest procés privilegiat el que crea i destrueix contenidors, gestiona imatges, xarxes i volums, i parla amb els registres.

Això implica que qui tingui accés al socket de Docker pràcticament té root sobre l'amfitrió , perquè pot llançar contenidors privilegiats, muntar sistemes de fitxers arbitraris i tocar configuració crítica. El dimoni es converteix, de facto, en un punt únic de fallada.

Podman, per contra, va néixer amb la idea de ser un motor de contenidors sense dimoni i el més “natiu” possible a Linux . No hi ha un procés central permanent; els contenidors pengen de lusuari o de systemd, i la integració amb aquest últim permet controlar contenidors mitjançant unitats de servei.

Aquest enfocament encaixa millor amb el model Unix de cada procés pertany a l'usuari que el llança i evita dependre d'un dimoni d'alts privilegis . A més, Podman ofereix compatibilitat amb ordres de Docker, simplificant la migració (fins i tot es pot fer àlies docker=podman en entorns on no volem instal·lar Docker CE).

Mode rootless i espais de noms d'usuari

Un dels grans avenços pràctics per reduir l'impacte d'una possible fuita de contenidor és el mode sense arrel (rootless) combinat amb namespaces d'usuari . Aquí la pregunta que s'intenta respondre és: “Què passa si finalment s'escapa el contenidor?”.

Els espais de noms d'usuari permeten remapejar l'UID 0 del contenidor a un UID sense privilegis al host . És a dir, dins del contenidor l'aplicació cregui que és root, però vist des del host aquest procés és, en realitat, un usuari corrent d'un rang subuid/subgid assignat.

D'aquesta manera, encara que un atacant aconsegueixi privilegis de root dins del contenidor i aconsegueixi encadenar un exploit de kernel o runtime, en tornar al host ho fa com a usuari sense privilegis . No podeu sobreescriure binaris de root, muntar sistemes de fitxers sensibles ni manipular dispositius on no té capacitats.

Podman es va dissenyar des del principi amb aquest model al cap: contenerització rootless per defecte sempre que sigui possible , ús de SELinux/AppArmor i cgroups fins i tot sense root, i un èmfasi fort a minimitzar els privilegis estructurals.

Docker també disposa avui d'una manera rootless “de veritat” , on dockerd i els contenidors viuen dins d'un user namespace, diferent de l'antic userns-remap on el dimoni seguia sent root. Des d'un punt de vista de seguretat, això evita que un exploit contra dockerd sigui un accés automàtic al root del host.

Xarxes de contenidors amb Podman: bridge, host, macvlan i interfícies rootless

Una altra peça rellevant de la seguretat i del funcionament pràctic és la capa de xarxa dels contenidors . Podman ofereix diferents mecanismes per donar connectivitat, amb una cura especial als escenaris rootless.

A Podman 4 es va introduir netavark, un driver de xarxa que segueix el model CNI per proporcionar als contenidors adreces IP a xarxes bridge, macvlan, etc. Amb netavark, els contenidors rootful solen connectar-se per defecte a una xarxa anomenada “podman” associada a un Linux bridge (podman0) al host, amb adreçament 10.88.0.0/16.

Aquesta xarxa bridge per defecte proporciona connectivitat bàsica a internet mitjançant regles SNAT i permet exposar ports del contenidor al host usant -po –publish, cosa que genera regles DNAT en iptables/nftables. Per compatibilitat amb Docker, aquesta xarxa no activa un servidor DNS intern.

A més, podem crear xarxes bridge definides per l'usuari , que aïllen grups de contenidors entre si i sí que ofereixen DNS intern. Això permet que els contenidors es resolguin per nom dins de la seva xarxa privada, facilita separar serveis que no s'haurien de veure entre si i dóna més control sobre MTU, tallafocs, etc.

En entorns més avançats podeu utilitzar xarxes macvlan o ipvlan per connectar els contenidors directament a la xarxa física del host. Macvlan permet que els contenidors es comuniquin entre si, mentre que ipvlan tendeix a aïllar-los més; són opcions útils en desplegaments on cada contenidor ha de veure com un host real per a la resta de la xarxa.

Xarxes rootless: slirp4netns i pasta

Quan l'usuari no és root, la cosa es complica: un usuari sense privilegis no pot modificar lliurement el namespace de xarxa global ni crear interfícies arbitràries, així que Podman ha d'estirar solucions en espai d'usuari per donar connectivitat.

Aquí entra en joc slirp4netns, el mecanisme clàssic usat per Podman rootless . Aquest projecte genera un entorn de xarxa aïllat dins del contenidor i utilitza el mòdul slirp del nucli per traduir adreces (NAT) i permetre que el contenidor surti a internet a través de la xarxa del host.

A la pràctica, slirp4netns crea una interfície TAP dins del namespace de xarxa del contenidor (per exemple tap0 amb IP 10.0.2.100 i gateway 10.0.2.2) i encamina el trànsit via una pila TCP/IP implementada en espai d'usuari. És funcional, però afegeix una mica de overhead i certes limitacions.

Una d'aquestes limitacions és que els usuaris sense privilegis no poden fer servir ports per sota del 1024 . El paràmetre sysctl net.ipv4.ip_unprivileged_port_start marca des de quin port es consideren “no privilegiats” (per defecte, 1024), encara que es pot ajustar amb compte si el model de seguretat ho permet.

A Podman 5, slirp4netns se substitueix per pasta com a mecanisme rootless per defecte . Pasta també funciona íntegrament en espai d'usuari, però gràcies a la interfície tap ia tècniques de zero-copy aconsegueix un rendiment de xarxa gairebé nadiu, reduint l'impacte en latència i throughput davant de slirp4netns.

Xarxes bridge i host en contenidors rootless

Fins i tot treballant en mode sense root podem enganxar contenidors rootless a la xarxa bridge per defecte “podman” usant –network=podman. D'aquesta manera s'aprofiten les capacitats de netavark i es mapegen ports al host amb -p, igual que en mode rootful.

També és possible crear xarxes bridge definides per l'usuari en entorns rootless . En aquest cas, els bridges i dispositius associats no es creen al namespace de xarxa global del host, sinó a l'espai de noms de l'usuari, de manera que des del host no veurem aquestes interfícies amb un simple sudo ip a.

Per inspeccionar aquests bridges rootless, Podman ofereix l'ordre podman unshare –rootless-netns , que obre una intèrpret d'ordres al namespace de xarxa de l'usuari. Des d'aquí sí que s'observen els bridges interns i es pot comprovar la connectivitat directa amb els contenidors.

Aquest aïllament té un efecte curiós: des del host pot no haver-hi connectivitat directa amb les IP d'aquests contenidors rootless, però sí amb els ports mapejats a la IP del propi host, que actuen dentrada al servei.
Per a la comunicació entre contenidors, el servidor DNS integrat a la xarxa bridge definida per l'usuari permet que parlin per nom, cosa que facilita molt la configuració d'aplicacions distribuïdes.

A l'altre extrem hi ha la xarxa host (–network=host) , on el contenidor comparteix la pila de xarxa amb l'amfitrió sense IP pròpia. En aquest mode, si un contenidor rootless aixeca un servidor al port 8080/tcp, el servei estarà directament disponible al port 8080 de l'amfitrió, cosa que estalvia mapatges de ports però redueix aïllament.

Podman Desktop, eines d'imatges i orquestració local

Per a qui prefereix una mica més visual, Podman Desktop proporciona un entorn gràfic per gestionar contenidors, pods, imatges i configuracions de xarxa en màquines de desenvolupament, actuant com a alternativa directa a Docker Desktop però recolzant-se al motor sense daemon.

L'obtenció d'imatges es fa amb podman pull, que es descarrega des dels registres definits a /etc/containers/registries.conf . Si indiquem la imatge sense nom de registre, Podman intenta localitzar-la a l'ordre de registres configurats, usant l'etiqueta latest per defecte.

A més de la CLI de Podman, podem recórrer a skopeig com a eina específica per gestionar, inspeccionar i copiar imatges entre registres i magatzems locals. Comandes com copy, delete o sync permeten automatitzar la sincronització entre repositoris, marcar imatges per garbage collection o moure artefactes entre entorns.

Un cop descarregada la imatge, podman run permet arrencar contenidors indicant transport i ruta (per defecte, transport docker i cerca als registres configurats). Les opcions habituals (-d, -p, –name, –pod, etc.) cobreixen tant escenaris de laboratori com desplegaments més seriosos.

La gestió diària es completa amb podman ps per llistar contenidors, podman stop / start per aturar o arrencar instàncies existents, i podman rm per eliminar contenidors aturats . Si un contenidor s'ha modificat i volem convertir-lo en imatge nova, podman commit desa aquests canvis sota un nom nou.

Pods i models avançats d'execució amb Podman

Inspirant-se en Kubernetes, Podman permet agrupar contenidors en pods que comparteixen la mateixa pila de xarxa i certs recursos . És un patró perfecte per a coses com una base de dades i el seu client, o diversos microserveis que cal comunicar amb baixa latència.

L'ordre podman pod create genera un nou pod i torna el vostre ID, però per defecte el pod queda aturat fins que s'arrenca algun contenidor associat o es llança explícitament amb podman pod start.

Per veure quins pods hi ha al sistema es fa servir podman pod ls , que llistarà també el contenidor INFRA associat a cadascun. Aquest contenidor especial manté viva la xarxa i altres recursos compartits del pod, per la qual cosa el nombre de contenidors mai no és zero.

Podman ofereix ordres específiques per iniciar, aturar o reiniciar pods complets (podman pod start/stop/restart) , però també podem actuar només sobre un contenidor concret dins del pod sense modificar la resta, mantenint l'aïllament de processos a nivell d'aplicació.

Per afegir més contenidors a un pod existent s'utilitza podman run –pod NOM_POD , seguint la mateixa sintaxi que per a contenidors solts. No es pot “treure” un contenidor d'un pod sense destruir-lo, ja que la pertinença al pod va lligada al cicle de vida.

La supervisió es completa amb podman ps –pod o ordres específiques per monitoritzar els processos de tots els contenidors en tots els pods , identificant ràpidament què forma part de quin grup i com estan distribuïts els serveis.

Contenidors, LXC i virtualització d'aplicacions

Encara que Docker i Podman dominin la conversa, no són les úniques opcions de contenidorització a GNU/Linux . Hi ha solucions com LXC/LXD, systemd‑nspawn o Kata Containers que aborden el problema des d'angles una mica diferents.

LXC proporciona contenidors de sistema molt lleugers, amb el seu propi hostname, IP, sistema de fitxers i un init complet . En combinació amb LXD, que actua com a hipervisor de contenidors i VMs, s'aconsegueix una experiència molt propera a tenir múltiples màquines lleugeres amb exercici gairebé bare metall.

Mentre que Docker/Podman se centren en contenidors d'aplicació compatibles amb OCI , LXC brilla quan es necessiten entorns persistents, amb diversos serveis i processos, que es comportin com una VM però amb menor overhead i una integració molt natural amb el kernel de Linux.

Des del punt de vista del rendiment, LXC pot executar aplicacions empresarials d'ús intensiu de dades gairebé sense penalització , cosa que el converteix en una opció potent per a càrregues sensibles a la latència però que no requereixen l'aïllament fort d'una VM tradicional.

Al costat d'això, també han guanyat força tecnologies orientades a micro-VMs i aïllament reforçat com Kata Containers , que llancen cada pod dins d'una petita màquina virtual amb el seu propi kernel, o gVisor, que intercala un “kernel sandbox” escrit a Go entre l'aplicació i Linux. Totes dues redueixen la dependència del nucli compartit i s'acosten al model de seguretat de les VM mantenint l'ergonomia dels contenidors.

Bones pràctiques d'enduriment per a Docker i Podman

Amb tot això, l'enfocament raonable per a una plataforma de contenidors robusta és treballar en capes: segmentació amb namespaces/cgroups, polítiques de filtratge amb seccomp i MAC, i restricció de privilegis estructurals mitjançant mode rootless.

A la pràctica, convé adoptar com a estàndard que els contenidors s'executin en mode sense root sempre que sigui possible , especialment en entorns multitenant o dins de núvols compartits. Podman ho facilita de sèrie, i Docker rootless cobreix la mateixa filosofia quan cal compatibilitat.

El nucli del host ha de mantenir-se al dia de pegats de seguretat . Vulnerabilitats com Dirty COW, Dirty Pipe i companyia es resolen amb actualitzacions que cal aplicar relativament ràpid si no volem deixar obert el camí a fuites de contenidors.

Una altra mesura molt eficaç és utilitzar distribucions immutables orientades a contenidors, com openSUSE MicroOS o Flatcar Linux . La seva arrel de només lectura i el sistema d'actualitzacions atòmiques redueixen molt la superfície d'atac i faciliten rollback si alguna cosa surt malament després d'un pegat.

Quant a configuració: res de contenidors privilegiats en producció excepte casos hipercontrolats , no executar aplicacions com a root dins del contenidor, usar sistemes de fitxers de només lectura quan sigui viable i limitar les capacitats al mínim necessari. SELinux/AppArmor i perfils seccomp ajustats a les trucades reals de laplicació són gairebé obligatoris.

Finalment, cal no oblidar la part de monitorització del temps d'execució . Eines com Falco, Sysdig Secure o Aqua ajuden a detectar anomalies, intents d'escapament (per exemple accessos rars a /proc o /sys), trànsit de xarxa atípic o ordres sospitoses, donant marge de reacció abans que l'atac es consolidi.

En combinar virtualització clàssica amb KVM, contenidors gestionats per Podman (preferiblement en mode rootless), xarxes ben segmentades i bones pràctiques d'enduriment, es pot muntar una plataforma de virtualització molt flexible i força segura. Entendre que el nucli compartit és el punt més delicat, recolzar-se en VM o micro-VM quan el risc o el compliment normatiu ho exigeixen, i tenir cura de la cadena de subministrament d'imatges marca la diferència entre un entorn de laboratori i una infraestructura llesta per a producció.