Segur que t'ha passat: intentes muntar un contenidor per a ús personal, busques que sigui més segur usant contenidors sense privilegis i, de cop i volta, et trobes atrapat en un laberint d'errors de permisos. És frustrant passar hores configurant carpetes a l'home de l'usuari només per descobrir que el contenidor no hi pot escriure o que, en fer-ho, els arxius resultants al host són impossibles de gestionar perquè pertanyen a un usuari fantasma.
La realitat és que, encara que la contenerització ha agilitzat el lliurament de programari, ha obert la porta a riscs considerables. Segons dades recents, la gran majoria de les imatges en producció arrosseguen vulnerabilitats crítiques, el que converteix la seguretat en un pilar innegociable. No es tracta només d'evitar que algú ens hacker, sinó d'entendre com funciona el aïllament de processos perquè la nostra infraestructura no es converteixi en un colador.
Entenent l'ecosistema de seguretat a contenidors
Per deixar de donar pals de cec amb els permisos, primer cal saber què estem protegint. L´arquitectura d´un contenidor es divideix en diverses capes crítiques. Primer tenim la imatge del contenidor, que és el pla original; si aquesta és vulnerable, totes les instàncies que despleguis seran insegures. Per això és vital fer servir imatges base de confiança i mantenir-les al dia.
Després entra en joc el temps d'execució (runtime), que actua com l‟àrbitre entre el sistema operatiu del host i l‟aplicació. Si el runtime està desactualitzat, el risc d'un escapament de contenidor augmenta dràsticament. A això hem de sumar l'orquestració, com Kubernetes, on el control d'accés basat en rols (RBAC) és l'única barrera real contra un accés no autoritzat a l'API de gestió.
No podem oblidar-nos del sistema operatiu del host. Si un atacant aconsegueix comprometre el nucli de l'amfitrió, té les claus de tot el regne. La recomanació aquí és clara: fer servir un sistema operatiu mínim per reduir la superfície datac. Finalment, la xarxa és el camí més comú dentrada; gairebé el 30% de les bretxes ocorren per fallades de connectivitat, per la qual cosa la segmentació de xarxa i el xifratge TLS/SSL els seus obligatoris.
El maldecap dels permisos i l'usuari Root
El problema típic dels aficionats és el flux de treball amb volums. Crees una carpeta, la muntes i, pum!, error de permís denegat. Això passa perquè, per defecte, molts contenidors arrenquen com a root. Quan intentes forçar el UID i GID a 0 perquè coincideixin amb el teu usuari del host, estàs creant un pont perillós. Si el contenidor no permet configurar aquests IDs, acabes perdent la tarda intentant esbrinar quin usuari intern està usant l'aplicació per fer un chown manual.
La solució eficient és aplicar el principi de mínim privilegi. No hauríeu d'executar res com a root si no és estrictament necessari. Per solucionar el caos dels fitxers creats pel contenidor que després no pots esborrar al host, és fonamental configurar el Dockerfile amb la instrucció USUARI, definint un usuari sense privilegis abans que l'aplicació arrenqui.
Si uses Podman, el concepte de rootless containers és nadiu i ajuda molt, però requereix que entenguis com es mapegen els usuaris del host als del contenidor. Per evitar que els permisos es descontrolin, l'ideal és que l'aplicació estigui dissenyada per escriure en rutes específiques i que mapeig de volums es faci considerant lUID real de lusuari que llança el procés.
Estratègies per construir imatges blindades
Si vols deixar de patir, has de canviar la manera com construeixes les teves imatges. Una tècnica brutalment efectiva és la compilació de diverses etapes (multi-stage builds). Bàsicament, utilitzes una imatge pesada amb totes les eines de compilació per generar el binari i després copies només aquest fitxer a una imatge final extremadament lleugera.
Fins i tot pots anar més enllà fent servir la imatge ratllar. Això crea un contenidor que no té absolutament res: ni intèrpret d'ordres, ni gestor de paquets, només la teva aplicació. Això fa que sigui pràcticament impossible per a un atacant executar ordres malicioses si aconsegueix entrar, ja que no hi ha intèrpret d'ordres disponible.
Una altra mesura de seguretat és netejar la imatge de qualsevol binari amb permisos setuid o setgid. Aquests permisos permeten que un fitxer s'executi amb els privilegis de l'amo del fitxer i no de l'usuari que el llança, cosa que és una autopista per a la escalada de privilegis. Un simple comandament de cerca i eliminació daquests bits durant la construcció de la imatge pot estalviar-te molts ensurts.
El perill de la manera privilegiada i les capacitats de Linux
De vegades, per desesperació en no solucionar un problema de permisos, caiem en la temptació d'usar el flag –privileged. Oblida't de fer això. El mode privilegiat trenca l'aïllament del contenidor i us dóna accés total als dispositius del host. És com donar les claus de casa teva a un desconegut sol perquè no sabia obrir la porta del jardí.
En lloc d'això, has de jugar amb les capacitats de Linux (capabilities). Docker assigna un conjunt de permisos per defecte (com CAP_CHOWN o CAP_NET_RAW). Si la teva aplicació no necessita manipular la xarxa a baix nivell, el més intel·ligent és eliminar les capacitats innecessàries i afegir només les estrictament requerides mitjançant --cap-add.
Per als que gestionen entorns més seriosos, existeixen plugins d'autorització com opa-docker-authz. Aquests permeten interceptar les trucades a l'API del dimoni de Docker i bloquejar qualsevol intent de llançar un contenidor en mode privilegiat, assegurant que ningú, ni tan sols per error, deixi la porta oberta al host.
Optimització i manteniment de lentorn
No t'obsessions que la imatge pesi 5MB usant Alpine Linux si això et porta problemes de compatibilitat amb les llibreries. De vegades és preferible una imatge de Debian una mica més pesada però estabilitzada i coneguda per l'equip. El que sí que és crític és implementar un escaneig de vulnerabilitats automàtic al teu pipeline de CI/CD per detectar CVEs abans que la imatge arribi a producció.
Quant a l'emmagatzematge, evita que l'aplicació escrigui al sistema de fitxers arrel. Configura el sistema de fitxers de només lectura (read-only rootfs) i defineix volums específics només per a les dades que han de persistir. Això no només és més segur, sinó que obliga a una arquitectura més neta i estateless, facilitant l'escalat horitzontal.
Per als processos programats, no fiquis un cron dins del contenidor de la web. La regla d'or és un procés per contenidor. El més net és fer servir la imatge de la teva app per llançar un contenidor efímer que executi la tasca i després es destrueixi, o bé gestionar el cron des del host trucant al motor del contenidor mitjançant ordres.
La seguretat dels contenidors és un camí continu que passa per eliminar lús de root, restringir les capacitats del nucli i netejar les imatges de qualsevol eina innecessària. Combinant l'ús d'usuaris sense privilegis amb l'enduriment del runtime i el monitoratge constant, s'aconsegueix un entorn on la funcionalitat no compromet la integritat del sistema amfitrió.
Redactor apassionat del món dels bytes i la tecnologia en general. M'encanta compartir els meus coneixements a través de l'escriptura, i això és el que faré en aquest bloc, mostrar tot el més interessant sobre gadgets, programari, maquinari, tendències tecnològiques, i més. El meu objectiu és ajudar-te a navegar pel món digital de forma senzilla i entretinguda.