A la lliçó anterior vam tancar la porta de qui pot fer què: RBAC decideix si tens dret a crear un pod a rutas-norte-pro. Però vam acabar amb una incomoditat molt concreta. Algú de plataforma, amb permisos perfectament legítims, pot desplegar avui mateix un contenidor amb privileged: true, que munti el disc del node amb hostPath i corri com a root. RBAC dirà que sí, perquè té permís per crear pods. I a partir d'aquí, el node sencer —amb tots els pods que hi corrin, inclòs postgres-reserves i les seves dades personals— queda al descobert.

Aquesta lliçó tracta de la segona barrera: què pot fer el procés un cop està corrent dins del contenidor. És la diferència entre "algú ha aconseguit executar codi a botiga-web" —un incident seriós però contingut— i "algú ha aconseguit executar codi a botiga-web i des d'allà ha llegit la base de dades de clients" —un incident d'una altra magnitud—.

L'eina es diu securityContext i és, juntament amb RBAC, el que més rendiment de seguretat dona per línia de YAML escrita.

Advertiment important. Aquesta lliçó explica els mecanismes d'enduriment i proposa una configuració d'exemple. L'enduriment real d'una plataforma en producció l'ha de revisar un professional de seguretat, que coneix el model d'amenaces concret de l'organització. Quan el sistema tracta dades personals —com postgres-reserves— el disseny l'ha de conèixer també el responsable de compliment normatiu. L'enfocament aquí és exclusivament defensiu: entendre els mecanismes per tancar-los, mai per explotar-los.

1. Què aïlla realment un contenidor
2. El securityContext: nivell de pod i nivell de contenidor
3. Executar sense root: runAsNonRoot, runAsUser i runAsGroup
4. Volums i permisos de fitxer: fsGroup i fsGroupChangePolicy
5. allowPrivilegeEscalation i el bit no_new_privs
6. privileged: true i per què equival a lliurar el node
7. Capacitats de Linux: treure-ho tot i afegir el just
8. readOnlyRootFilesystem i com fer-lo viable
9. Seccomp, AppArmor i SELinux
10. Els ajustos del pod que cal evitar
11. RuntimeClass i els entorns d'execució aïllats
12. L'enduriment complet de Rutas Norte
13. Com comprovar el resultat des de dins del contenidor
14. Errors comuns i consells
15. Exercicis
16. Conclusió

Abans de configurar res cal entendre què estem configurant. I l'afirmació de partida és incòmoda:

Un contenidor no és una màquina virtual. Tots els contenidors d'un node comparteixen el mateix kernel de Linux. Un contenidor és un procés normal del sistema operatiu del node, al qual se li han restringit tres coses: el que veu, el que consumeix i el que pot demanar al kernel.

Compara'l amb una màquina virtual:

Els tres mecanismes que fan l'aïllament:

No confondre amb els Namespace de Kubernetes: són un concepte de Linux completament diferent. Un namespace del kernel dona al procés una vista pròpia d'un recurs del sistema.

Quan dins d'un contenidor fas ps aux i veus només el teu procés com a PID 1, és el namespace PID actuant. Quan hostPID: true està actiu, veus tots els processos del node, inclosos els dels altres pods, amb les seves línies d'ordres i les seves variables d'entorn.

Els control groups limiten CPU, memòria, E/S i nombre de processos. És el que hi ha darrere de resources.limits del mòdul 3. La seva funció és sobretot d'estabilitat —evitar que un pod tombi el node— però també de seguretat, perquè una denegació de servei local és un atac.

Aquí és on el securityContext marca la diferència i on es juga el partit. Hi tornarem als apartats 7 i 9.

Que tots els contenidors comparteixin kernel té una conseqüència directa:

• Una fallada del kernel de Linux pot permetre sortir del contenidor. Aquestes fallades apareixen periòdicament i es corregeixen; per això mantenir els nodes apedaçats és una tasca de seguretat de primer ordre, no de manteniment rutinari.
• Com menys pugui demanar un contenidor al kernel, menys superfície té per aprofitar una d'aquestes fallades. Aquesta és la lògica de tot el que segueix.
• Si necessites aïllament fort per a alguna cosa que no controles, els contenidors normals no són la resposta: cal fer servir un entorn d'execució aïllat (apartat 11) o directament una màquina virtual.

Llegeix el diagrama al revés: si un procés de botiga-web aconsegueix abusar del kernel compartit, està al mateix pla que postgres-reserves. L'única barrera és quant li hem permès demanar al kernel.

securityContext apareix a dos llocs del manifest, i quins camps admet cadascun és diferent. Confondre'ls és l'error número u.

Regla mnemotècnica: el que té a veure amb identitat i amb volums va al pod; el que té a veure amb el que pot fer el procés va al contenidor.

Quan un camp existeix als dos nivells i es defineix a tots dos, guanya el del contenidor. Això permet una estratègia molt neta: posar la línia base restrictiva al pod i fer excepcions puntuals i visibles al contenidor que ho necessiti.

Un matís que confon: capabilities i allowPrivilegeEscalation no s'hereten del pod perquè no existeixen a nivell de pod. Cal repetir-los a cada contenidor, inclosos els initContainers i els sidecars. És tediós i és la causa més freqüent que un pod "endurit" tingui un contenidor sense endurir. Kustomize o Helm ajuden; una política d'admissió (08-03) ho garanteix.

Un initContainer privilegiat és un pod privilegiat: s'executa amb accés complet abans que arrenqui el contenidor principal. Repassa 06-04 i comprova que tots els teus initContainers i sidecars estan endurits igual que els contenidors principals.

Per defecte, un contenidor corre amb l'usuari que declari la imatge; i moltíssimes imatges públiques, inclosa nginx, declaren root (UID 0). Córrer com a root dins del contenidor no és el mateix que ser root del node, però està molt més a prop del que a ningú li agradaria:

• Root dins del contenidor té, per defecte, un conjunt de capacitats que un usuari normal no té.
• Si el contenidor comparteix alguna cosa amb el node (un hostPath, un socket), root escriu on un usuari normal no podria.
• Si apareix una fallada d'escapada del kernel, la majoria requereixen ser root dins del contenidor per funcionar. No ser-ho elimina bona part d'aquesta classe de problemes.

runAsNonRoot sense runAsUser funciona només si la imatge declara un usuari numèric. Si el Dockerfile posa USER appuser (nom, no número), el kubelet no pot resoldre el nom —no té accés al /etc/passwd de la imatge abans d'arrencar-la— i el pod falla:

D'aquí una regla que reprendrem a 08-05: declara sempre l'usuari numèric al Dockerfile (USER 10001), i a més especifica runAsUser al manifest. Cinturó i tirants.

Si intentes córrer com a root amb la verificació activa:

botiga-web fa servir la imatge oficial nginx, que arrenca com a root per poder escoltar al port 80 i després baixa de privilegis en els seus processos treballadors. Si li posem runAsNonRoot: true sense més, falla en intentar escriure a /var/cache/nginx i en obrir el port 80.

Hi ha dos camins, i només un és bo:

La segona és clarament superior i és la que adoptem:

I el Service continua publicant el 80 cap enfora:

Ningú fora del clúster nota la diferència, i hem eliminat una capacitat i l'arrencada com a root.

Aquí arriba el problema pràctic que fa que molta gent es rendeixi i torni a root. És exactament el cas de postgres-reserves.

Un volum aprovisionat dinàmicament (mòdul 5) es munta amb els permisos que li posi el sistema de fitxers, normalment propietat de root:root amb mode 0755. Si el contenidor corre com a UID 10001, no pot escriure al seu propi volum de dades.

Quan fsGroup hi és present, el kubelet, abans d'arrencar els contenidors:

1. Canvia el grup propietari dels fitxers i directoris del volum a aquell GID.
2. Afegeix el bit d'escriptura per al grup.
3. Posa el bit setgid als directoris, perquè el que sigui nou hereti el grup.
4. Afegeix aquell GID als grups suplementaris del procés.

Resultat: el procés pot escriure al volum sense ser root i sense tocar la imatge.

fsGroup no s'aplica a tots els tipus de volum. Funciona amb els que tenen sistema de fitxers propi (la majoria de volums en bloc via CSI, emptyDir, configMap, secret) i no amb NFS ni altres sistemes de fitxers de xarxa, on els permisos els governa el servidor. Amb NFS cal coordinar els UID/GID amb qui administra l'emmagatzematge.

Canviar el propietari de cada fitxer és una operació recursiva. Al volum de postgres-reserves, amb milions de fitxers, això pot trigar minuts en cada arrencada del pod. I passa en cada reinici, en cada actualització, en cada moviment de node.

OnRootMismatch funciona perquè, si el directori arrel ja té el grup i els permisos esperats, és que el canvi es va fer en una arrencada anterior. La primera vegada sí que fa el recorregut complet; les següents són instantànies.

La imatge postgres:16.4 defineix l'usuari postgres amb UID i GID 999. Configuració final:

Quatre decisions per justificar:

1. runAsUser: 999: l'UID que la imatge ja espera. Posar-ne un altre obligaria a modificar la imatge.
2. fsGroupChangePolicy: OnRootMismatch: sense ell, amb 50 GiB de dades personals, cada reinici del pod trigaria minuts i apareixeria com una caiguda del servei.
3. readOnlyRootFilesystem: false a PostgreSQL: és una excepció conscient i documentada. PostgreSQL escriu fitxers de socket i temporals fora del volum de dades. Es podria arreglar amb emptyDir a /var/run/postgresql i /tmp, i és el recomanable a mitjà termini; aquí ho deixem explícit perquè es vegi que una excepció documentada és millor que una excepció silenciosa.
4. El sidecar exportador sí que porta readOnlyRootFilesystem: true: no escriu res, així que no hi ha raó per deixar-lo obert. Cada contenidor s'endureix segons el que necessita, no segons el que necessita el seu veí.

Aquesta línia, que costa zero, es tradueix al kernel al bit no_new_privs del procés (documentat a prctl(2)). El seu significat exacte:

Amb no_new_privs actiu, cap procés fill pot obtenir més privilegis que el seu pare, ni tan sols executant un binari amb el bit setuid posat o amb capacitats de fitxer.

A Linux, un executable pot portar el bit setuid, que fa que en executar-se corri amb l'UID del seu propietari en lloc del de qui el llança. L'exemple clàssic és /usr/bin/passwd: el llança un usuari normal, però corre com a root perquè necessita escriure a /etc/shadow.

Dins d'un contenidor, un binari setuid propietat de root és un pont entre "soc l'usuari 10001" i "soc root en aquest contenidor". Moltes imatges base en porten uns quants sense que ningú se n'adoni:

Amb allowPrivilegeEscalation: false, executar qualsevol d'ells no eleva privilegis: el bit setuid queda neutralitzat.

Pràcticament mai en una aplicació. Hi ha tres situacions legítimes:

Nota de coherència: allowPrivilegeEscalation: false és incompatible amb privileged: true. Si poses tots dos, el pod és rebutjat. És una comprovació deliberada de Kubernetes.

no_new_privs és a més la condició perquè seccomp funcioni sense capacitats especials. Posar-lo a false prepara el terreny per a l'apartat 9.

Regla pràctica: allowPrivilegeEscalation: false a tots els contenidors, sense excepcions que no estiguin documentades i aprovades.

Quan un contenidor és privilegiat:

La conseqüència pràctica és senzilla d'enunciar:

Un contenidor privilegiat és, a efectes pràctics, root al node. Pot llegir i escriure els discos, carregar mòduls del kernel, accedir al sistema de fitxers de l'amfitrió i, amb això, als secrets muntats de tots els altres pods d'aquell node.

Aplicat a Rutas Norte: si botiga-web corregués privilegiat i estigués al mateix node que postgres-reserves, qui controlés botiga-web tindria accés al volum de dades personals. I ni RBAC ni les NetworkPolicies del mòdul 4 ho impedirien, perquè no és una petició a l'API ni trànsit de xarxa: és accés directe al disc.

privileged: true té usos reals, tots al pla d'infraestructura, no en aplicacions:

Aquest últim és important i l'aprofitem: el recol·lector de logs del mòdul 7 no necessita ser privilegiat. Amb muntar /var/log en només lectura n'hi ha prou.

Continua sent un pod amb més privilegis que una aplicació normal —ho vam advertir a 06-02— però hem baixat de "control total del node" a "lectura d'un directori". Aquesta reducció és exactament la feina d'aquesta lliçó.

Regla: si un manifest d'un tercer demana privileged: true, exigeix una justificació concreta abans d'aplicar-lo. Molt sovint és un valor per defecte còmode, no una necessitat.

Històricament Linux tenia dues classes de procés: root (ho podia tot) i la resta (no podia gairebé res). Les capacitats van partir els poders de root en una quarantena de peces independents que es concedeixen per separat.

Capacitats rellevants:

Un contenidor sense configuració especial no arrenca amb totes: l'entorn d'execució concedeix un conjunt per defecte d'unes catorze, entre elles CHOWN, DAC_OVERRIDE, NET_RAW, SETUID, SETGID i NET_BIND_SERVICE. Cap aplicació web normal no en fa servir cap.

drop: ["ALL"] seguit de res és la configuració objectiu de tots els components de Rutas Norte. Cap no necessita ni una sola capacitat.

Detall important: drop: ["ALL"] i add: ["NET_BIND_SERVICE"] junts funcionen i són la forma correcta d'expressar "només aquesta". El drop es processa abans que l'add.

Suposem que vols mantenir la imatge nginx oficial escoltant al 80, sense ser root:

Comparem-ho amb l'alternativa que ja hem adoptat:

El port baix és una restricció d'una era en què els servidors eren màquines físiques compartides. A Kubernetes, on el Service tradueix ports sense cost, mantenir-lo només afegeix una capacitat innecessària. La regla general: si pots evitar una capacitat canviant un número de port, canvia'l.

Tots a zero: exactament el que volem. Per traduir un valor no nul a noms:

Si veiessis alguna cosa com cap_chown,cap_dac_override,cap_net_raw,cap_setgid,cap_setuid, és que falta el drop: ["ALL"] en aquell contenidor.

El sistema de fitxers arrel del contenidor es munta en només lectura. Els volums muntats explícitament continuen sent escrivibles.

Converteix el contenidor en una cosa immutable en temps d'execució: el que es desplega és el que s'executa, de principi a fi. I dona una propietat molt útil per al mòdul 7: si alguna cosa intenta escriure a /, salta un error registrat. És un senyal de detecció gratis, i a 08-06 el convertirem en una regla de Falco.

Gairebé tot el programari escriu alguna cosa: fitxers temporals, sockets, cachés, PIDs. La solució és muntar emptyDir exactament en aquests llocs.

botiga-web amb nginx és l'exemple canònic, perquè nginx necessita quatre directoris de caché més /tmp i el seu fitxer de PID:

Punts a destacar:

• medium: Memory fa que l'emptyDir visqui a RAM (tmpfs). Per a cachés petites és més ràpid i evita escriure dades al disc del node, cosa que importa si per elles hi passa informació de sessió.
• sizeLimit és obligatori a la pràctica. Un emptyDir sense límit pot créixer fins a esgotar el disc (o la memòria) del node. Amb medium: Memory compta a més contra el límit de memòria del pod.
• Els emptyDir es buiden en reiniciar el contenidor, cosa que és just el que volem: res no persisteix.

No ho endevinis: mesura-ho. Desplega amb readOnlyRootFilesystem: true a rutas-norte-dev i mira què falla.

El log et diu exactament la ruta. Hi afegeixes l'emptyDir, repeteixes, i en dues o tres iteracions tens la llista completa. És un procediment de deu minuts per component que es fa una vegada.

Directoris habituals per tipus d'aplicació:

Secure Computing Mode limita quines crides al sistema pot fer el procés. És la defensa més directa contra les fallades del kernel: si una fallada és en una crida que el teu contenidor no pot fer, no t'afecta.

Atenció a un detall històric: el valor per defecte de Kubernetes ha estat Unconfined durant anys. Des de 1.27 la porta d'enllaç SeccompDefault del kubelet permet canviar-lo a RuntimeDefault, però cal activar-la explícitament a la configuració del kubelet. Mentre no ho facis, si no poses seccompProfile, el teu contenidor no té cap filtre seccomp. Aquesta és una d'aquelles coses que la gent dona per fetes i no ho és.

RuntimeDefault bloqueja crides com ara mount, reboot, init_module, kexec_load, ptrace en alguns contextos, bpf i pivot_root. És compatible amb pràcticament qualsevol aplicació normal, així que posar-lo és gairebé gratis i cal fer-ho sempre.

Quan RuntimeDefault no n'hi ha prou —per exemple, per a un component molt exposat com api-reserves— pots escriure un perfil propi. El fitxer es col·loca a /var/lib/kubelet/seccomp/perfils/ de cada node (normalment amb un DaemonSet o amb el Security Profiles Operator):

Advertiments seriosos sobre els perfils a mida:

• Són fràgils. Una actualització de la llibreria estàndard o de l'entorn d'execució pot introduir una crida nova i el procés mor amb SIGSYS o un EPERM incomprensible.
• Cal generar-los observant, no escrivint-los a mà. El Security Profiles Operator pot gravar el perfil d'una càrrega en execució.
• Comença sempre per RuntimeDefault. El salt a un perfil a mida només compensa en components molt crítics i amb capacitat de mantenir-lo.

Per depurar, es pot fer servir defaultAction: SCMP_ACT_LOG, que registra en lloc de bloquejar. No deixis mai això en producció: no protegeix de res.

Control d'accés obligatori basat en rutes, habitual a Debian i Ubuntu. Des de Kubernetes 1.30 té camp natiu al securityContext, sense necessitat d'anotacions:

Les anotacions container.apparmor.security.beta.kubernetes.io/<contenidor> continuen funcionant per compatibilitat, però estan obsoletes: fes servir el camp.

Control d'accés obligatori basat en etiquetes, habitual a Red Hat i derivats. Es configura amb seLinuxOptions:

A la pràctica, l'ús més freqüent a Kubernetes és deixar que l'entorn d'execució assigni etiquetes automàticament. Modificar-les a mà sol ser contraproduent llevat que l'organització tingui una política SELinux pròpia.

Recomanació per a Rutas Norte: seccompProfile: RuntimeDefault a absolutament tots els pods, i AppArmor/SELinux segons el que portin els nodes, sense dependre'n per a la seguretat essencial (perquè el clúster local és minikube i el de producció podria no coincidir).

Hi ha cinc ajustos que trenquen l'aïllament del pod respecte al node. Els hem anat esmentant a 05-01 i 06-02; aquí els reunim.

Aquest mereix un paràgraf a part perquè desmunta feina d'un mòdul anterior. A 04-06 vam construir una política deny-all a rutas-norte-pro i vam anar autoritzant cada conversa una a una. Un pod amb hostNetwork: true fa servir la pila de xarxa del node, no la del pod, així que les NetworkPolicies —que actuen sobre les IP de pod— no se li apliquen. Tota aquella feina queda anul·lada per a aquell pod.

És la raó per la qual un DaemonSet amb hostNetwork no ha de compartir namespace amb les aplicacions i per la qual els seus manifests mereixen una revisió especialment acurada.

Un hostPath a / dona accés a:

• /var/lib/kubelet/pods/*/volumes/kubernetes.io~projected/ — els tokens de ServiceAccount de tots els pods del node.
• /etc/kubernetes/ — en un node de pla de control, les claus del clúster.
• /var/lib/docker o /var/lib/containerd — totes les imatges i capes.
• /var/run/containerd/containerd.sock — el socket de l'entorn d'execució, que permet arrencar contenidors privilegiats.

Aquest últim punt és clau i sovint es passa per alt: muntar el socket de l'entorn d'execució equival a privileged: true, encara que el pod no ho declari. Qualsevol manifest que munti /var/run/docker.sock o containerd.sock s'ha de tractar com un pod privilegiat.

Els usos legítims de hostPath són d'infraestructura (llegir /var/log per al recol·lector, exposar dispositius a un driver CSI) i sempre han de ser:

1. La ruta més específica possible, mai / ni /var.
2. Amb readOnly: true sempre que sigui possible.
3. Amb type: explícit (Directory, File, Socket) perquè no es creï per accident.
4. En un namespace a part amb perfil de seguretat relaxat (08-03).

Obre el port a la IP del node. Problemes: només hi cap un pod per node amb aquell port, se salta el Service i l'Ingress (i per tant el TLS de 04-05 i el WAF de 08-04), i exposa el servei a qualsevol que arribi a la IP del node. Per publicar serveis es fa servir Ingress, com al mòdul 4.

Tot l'anterior endureix un contenidor, però no canvia el fet fonamental: el kernel és compartit. Si necessites aïllament fort, cal una altra cosa.

Un RuntimeClass selecciona quin entorn d'execució fa servir el pod:

Rutas Norte no té avui cap càrrega que ho justifiqui. Si demà permetés a les empreses d'autobusos pujar un fitxer d'horaris i el processés amb una llibreria d'anàlisi complexa, aquell component seria el candidat natural: s'executa codi sobre dades que vénen de fora.

L'important és conèixer l'eina i el seu criteri: l'aïllament reforçat és per a codi en què no confies, no per al teu.

Reunim tot en la configuració final de cada component, amb la justificació de cada excepció.

Fixa't en la imatge referenciada per digest en lloc de per etiqueta. És el tema de 08-05 i encaixa aquí de forma natural: de res no serveix endurir un contenidor si no saps amb certesa quina imatge s'està executant.

Dos detalls fins: l'adaptador fa servir el mateix UID que el worker per poder llegir els fitxers que aquest escriu (alternativa: fsGroup compartit), i munta el volum amb readOnly: true perquè només llegeix. Endurir un sidecar és tan important com endurir el contenidor principal: comparteixen el namespace de xarxa i sovint volums.

Aquest component és especialment sensible perquè llegeix dades personals per agregar-les. Recorda el que vam dir a 07-05: els informes només contenen agregats (ocupació per línia i per franja horària), mai registres individuals, i res d'això no va als logs.

Com que aquests blocs es repeteixen, el raonable és extreure'ls. Amb Kustomize (mòdul 10) s'aplica un pedaç estratègic a tots els Deployments:

I a 08-03 farem el pas definitiu: fer que el clúster rebutgi qualsevol pod que no compleixi aquestes regles, perquè cap desplegament futur no se les pugui saltar per oblit.

Un enduriment sense verificar és una suposició. Aquestes comprovacions triguen un minut i s'han de fer després de cada canvi.

Si veiessis uid=0(root), el runAsUser no s'està aplicant (comprova que no el sobreescrigui el securityContext del contenidor).

I que els emptyDir sí que són escrivibles:

CapEff: 0 confirma el drop: ["ALL"]. NoNewPrivs: 1 confirma allowPrivilegeEscalation: false. És la comprovació més directa de les dues línies més importants del manifest.

Si veus 0 quan esperaves RuntimeDefault, revisa que el camp estigui al nivell correcte i que el node ho admeti.

Només els processos del contenidor. Si veiessis processos del node (kubelet, containerd, processos d'altres pods), és que hostPID: true està actiu.

Nota pràctica: aquest guió necessita pods/exec, un permís que a 08-01 no vam donar a suport ni a desenvolupament. És una tasca de plataforma, i el lògic és integrar-la com a comprovació automàtica a rutas-norte-pre abans de promocionar a producció.

Posar capabilities o readOnlyRootFilesystem al securityContext del pod. No existeixen a aquest nivell. El manifest es rebutja o el camp s'ignora, segons l'eina. Van a cada contenidor.

Oblidar els initContainers i els sidecars. Un pod amb el contenidor principal perfectament endurit i un initContainer privilegiat és un pod privilegiat. Repassa 06-04.

Fer servir runAsNonRoot: true amb una imatge que declara USER per nom. El kubelet no ho pot verificar i el pod no arrenca. Fes servir sempre UID numèric al Dockerfile (08-05) i runAsUser al manifest.

Rendir-se davant de readOnlyRootFilesystem i treure'l. El log et diu la ruta exacta que falla. Dos o tres emptyDir resolen gairebé tots els casos.

emptyDir sense sizeLimit. Pot omplir el disc o la memòria del node i provocar el desallotjament d'altres pods. Amb medium: Memory, a més, compta contra el límit de memòria del pod.

Donar per fet que seccomp està actiu. El valor per defecte ha estat Unconfined durant anys. Si no poses seccompProfile: RuntimeDefault, probablement no hi ha filtre. Comprova-ho amb grep Seccomp /proc/1/status.

Escriure un perfil seccomp a mida a mà. És fràgil i es trenca amb cada actualització de la imatge. Comença per RuntimeDefault; si necessites més, genera el perfil observant la càrrega.

Muntar el socket de l'entorn d'execució. /var/run/docker.sock o containerd.sock equivalen a privileged: true encara que el manifest no ho digui.

Acceptar privileged: true en un manifest d'un tercer sense preguntar. Moltes vegades és comoditat, no necessitat. Demana la justificació.

Oblidar fsGroupChangePolicy: OnRootMismatch en volums grans. El pod triga minuts a arrencar en cada reinici i sembla una caiguda.

Creure que runAsNonRoot canvia l'usuari. No el canvia: el verifica. Sense runAsUser ni un USER numèric a la imatge, no arrenca.

Suposar que un contenidor aïlla com una VM. Comparteix kernel. És la premissa de tota la lliçó i la raó que els nodes hagin d'estar apedaçats.

Consell d'or: l'objectiu per a tota aplicació és aquest bloc exacte, i qualsevol desviació ha d'estar comentada al mateix YAML explicant per què:

redis-cache és un StatefulSet d'una rèplica amb la imatge redis:7.4-alpine, que corre com a root i munta un PVC a /data. Escriu el fragment de securityContext complet (nivell de pod i de contenidor) sabent que:

• La imatge oficial de Redis defineix l'usuari redis amb UID i GID 999.
• Redis escriu el seu fitxer de dades a /data (el PVC) i el seu fitxer de PID a /var/run/redis.
• No necessita cap capacitat de Linux.
• El volum és de 8 GiB.

Indica què es trencaria si ometessis fsGroup i com ho detectaries.

Després d'endurir worker-notificacions, el pod queda en CrashLoopBackOff:

El securityContext aplicat és:

1. Quina és la causa exacta?
2. Proposa dues solucions i raona quina és millor.
3. Escriu l'ordre que confirmaria el diagnòstic.

Escriu una ordre que llisti tots els pods de rutas-norte-pro que incompleixin alguna d'aquestes condicions, indicant quina:

• readOnlyRootFilesystem: true a tots els seus contenidors.
• allowPrivilegeEscalation: false a tots els seus contenidors.
• capabilities.drop inclou ALL a tots els seus contenidors.
• No fan servir hostNetwork, hostPID ni hostIPC.
• Cap contenidor no és privileged.

Ha de recórrer també els initContainers.

Solució 1

Sense fsGroup: el PVC es munta amb propietari root:root i mode 0755. Redis, corrent com a UID 999, no pot escriure a /data. El pod arrenca i mor tan bon punt intenta persistir:

Detecció:

Amb fsGroup: 999 aplicat:

El grup passa a 999, apareix el bit d'escriptura de grup i la s indica el setgid al directori.

Nota addicional: com que és una caché, la pèrdua del volum no és crítica. Però sí que ho és que no arrenqui, perquè api-reserves respondria més lentament i podria degradar-se la disponibilitat de places.

Solució 2

1. Causa. readOnlyRootFilesystem: true impedeix escriure a qualsevol lloc del sistema de fitxers arrel que no sigui un volum muntat. El worker intenta escriure a /app/cua/pendents.dat, que és dins de la imatge i per tant al rootfs de només lectura. El missatge EACCES en un openSync d'escriptura és la signatura típica d'aquest problema. No és un problema d'UID: encara que corregués com a root, / continuaria sent de només lectura.

2. Dues solucions:

Opció A — muntar un emptyDir a /app/cua:

Opció B — canviar la configuració del worker perquè faci servir /tmp, ja muntat:

Quina és millor: depèn de si aquestes dades han de sobreviure. I aquí hi ha una consideració de negoci que va més enllà del YAML: /app/cua/pendents.dat guarda notificacions pendents d'enviar. Amb qualsevol de les dues opcions, aquestes dades es perden en reiniciar el contenidor, perquè emptyDir és efímer. Si un client compra un bitllet i el worker es reinicia abans d'enviar el correu, aquell client no rep la seva confirmació.

La solució correcta, per tant, és la C: worker-notificacions no hauria de tenir cua local. La cua ha d'estar en un magatzem compartit i durador —Redis amb persistència, o la mateixa base de dades— de manera que qualsevol rèplica pugui reprendre la feina. Això a més arregla un problema que existia abans d'endurir res: amb diverses rèpliques, cadascuna tenia la seva pròpia cua local invisible per a les altres.

Com a solució immediata per desbloquejar, l'A amb emptyDir és preferible a la B, perquè deixa el problema visible al manifest (volumes: cua) en lloc d'amagar-lo en una variable d'entorn. I cal obrir la tasca per a la C.

Aquest exercici il·lustra una cosa important: endurir un contenidor sovint destapa fallades de disseny preexistents. El readOnlyRootFilesystem no ha creat el problema; l'ha fet visible.

3. Confirmació del diagnòstic:

Els permisos del directori són correctes (propietari 10002, el mateix UID del procés), i tot i així falla: això descarta un problema de permisos i confirma que la causa és el muntatge de només lectura.

Solució 3

Interpretació d'aquesta sortida concreta:

• postgres-reserves: és l'excepció documentada de l'apartat 12. Està justificada, encara que la tasca de resoldre-la amb emptyDir continua oberta.
• fluent-bit-collector: DaemonSet de logs amb hostPath en només lectura. Legítim i ja reduït al mínim (sense privileged), però a 08-03 el mourem a un namespace a part perquè no relaxi el perfil de tot rutas-norte-pro.

Que cap altre pod no aparegui és l'evidència que l'enduriment està aplicat. Aquest guió s'hauria d'executar a la canalització sobre rutas-norte-pre abans de cada promoció a producció, amb una llista d'excepcions conegudes perquè només alerti de les noves.

Nota sobre // true i // false al jq: els valors per defecte estan escrits en la direcció insegura a propòsit. allowPrivilegeEscalation absent equival a permès, així que el seu defecte és true; readOnlyRootFilesystem absent equival a escrivible, així que el seu defecte és false. Una auditoria ha d'assumir el pitjor quan el camp no hi és.

Hem afegit la segona capa de defensa. Repassant l'essencial:

• Un contenidor no és una màquina virtual. Comparteix kernel amb el node, i l'aïllament el donen els namespaces, els cgroups i els límits del que pot demanar al kernel. Per això apedaçar els nodes és una tasca de seguretat de primer nivell.
• El securityContext viu a dos nivells: identitat i volums al pod; capacitats, escalada i sistema de fitxers al contenidor. El del contenidor guanya, i capabilities, privileged, readOnlyRootFilesystem i allowPrivilegeEscalation cal repetir-los a cada contenidor, inclosos initContainers i sidecars.
• No córrer com a root (runAsNonRoot + runAsUser numèric), i resoldre els permisos de volum amb fsGroup i fsGroupChangePolicy: OnRootMismatch quan el volum és gran, com a postgres-reserves.
• allowPrivilegeEscalation: false activa no_new_privs i neutralitza els binaris setuid. Costa una línia.
• privileged: true equival a lliurar el node, i muntar el socket de l'entorn d'execució també, encara que no ho declari.
• capabilities: drop: ["ALL"] i afegir només l'imprescindible; i moltes vegades es pot evitar fins i tot NET_BIND_SERVICE canviant a un port alt.
• readOnlyRootFilesystem: true fa el contenidor immutable en execució, i esdevé viable amb uns quants emptyDir amb sizeLimit.
• seccompProfile: RuntimeDefault sempre; no donis per fet que ja està actiu.
• Evitar hostNetwork, hostPID, hostIPC, hostPath i hostPort; recorda que hostNetwork anul·la les NetworkPolicies del mòdul 4.
• Per a codi en què no confies, RuntimeClass amb gVisor o Kata; per al teu, no compensa.
• I comprovar-ho tot des de dins: id, l'escriptura fallida, CapEff, NoNewPrivs i Seccomp a /proc/1/status.

Ara tots els components de Rutas Norte estan endurits. Però fixa't en la naturalesa del que hem fet: hem escrit un YAML correcte. Res no impedeix que demà algú desplegui un pod nou sense securityContext, o que copiï un manifest d'internet amb privileged: true, o que un company afegeixi un sidecar i oblidi el drop: ["ALL"]. Tot l'enduriment d'aquesta lliçó depèn que cada persona se'n recordi, cada vegada. I això no és una garantia: és una esperança.

La lliçó següent, 08-03, Polítiques de Seguretat de Pods i Pod Security Standards, fa el pas definitiu: passar de "cada equip posa bé el seu securityContext" a "el clúster no accepta un pod que no el tingui". Veurem els Pod Security Standards, el Pod Security Admission integrat a l'apiserver, i els motors de política com Kyverno que permeten exigir qualsevol regla que se t'acudeixi, amb el missatge de rebuig exacte que retorna l'API quan un pod no compleix.