A la lliçó anterior vam endurir cada component de Rutas Norte: botiga-web corre sense root amb el sistema de fitxers en només lectura, api-reserves no té ni una capacitat de Linux, postgres-reserves escriu al seu volum gràcies a fsGroup i tots porten seccompProfile: RuntimeDefault. La feina està feta i verificada.

I tot i així, hi ha un forat enorme: tot això depèn que algú se'n recordi. Demà un company afegeix un sidecar i oblida el drop: ["ALL"]. Un desenvolupador copia un manifest d'un blog que porta privileged: true perquè "així funcionava". Un operador de tercers s'instal·la amb un DaemonSet que munta / del node. Cap d'aquestes coses no trenca res visible, ningú no rep una alerta, i l'enduriment que vam construir amb tanta cura deixa d'aplicar-se al punt exacte on importa.

Aquesta lliçó fa el salt que ho canvia tot: passar de "cada equip posa bé el seu securityContext" a "el clúster rebutja un pod que no el tingui". És la tercera porta que vam veure a 08-01, el control d'admissió, i és la diferència entre una norma escrita i una norma aplicada.

Advertiment important. Les polítiques d'admissió són el mecanisme que fa complir el disseny de seguretat, i precisament per això un error en elles pot bloquejar desplegaments legítims o, pitjor, donar una falsa sensació de protecció. El conjunt de polítiques d'un clúster de producció l'ha de dissenyar i revisar un professional de seguretat. Quan les càrregues afectades tracten dades personals —postgres-reserves, api-reserves i informes-ocupacio a Rutas Norte— el responsable de compliment normatiu ha de conèixer i aprovar què s'exigeix i quines excepcions existeixen.

1. De la norma escrita a la norma aplicada
2. Context històric: les PodSecurityPolicy i per què van desaparèixer
3. Els Pod Security Standards: privileged, baseline i restricted
4. Pod Security Admission: activar-lo amb etiquetes al namespace
5. Aplicació progressiva a Rutas Norte
6. Càrregues que legítimament necessiten privilegis
7. Les limitacions del Pod Security Admission
8. Motors de política general: Kyverno i OPA Gatekeeper
9. Polítiques de Kyverno per a Rutas Norte
10. ValidatingAdmissionPolicy: CEL natiu sense instal·lar res
11. Errors comuns i consells
12. Exercicis
13. Conclusió

Recordem el recorregut d'una petició a l'API de 08-01:

La diferència amb RBAC és fonamental i convé tenir-la claríssima:

Algú de plataforma té permís RBAC per crear pods a rutas-norte-pro. Això no canvia. El que hi afegim és que, encara que tingui permís, el pod concret que envia ha de complir unes regles.

I hi ha una propietat molt valuosa: l'objecte rebutjat mai no arriba a etcd. No es crea i cal esborrar-lo després; senzillament no existeix. La resposta arriba a l'instant a qui va fer el kubectl apply, amb el motiu escrit.

Els mutants s'executen abans que els validants, cosa que té sentit: primer es completa l'objecte, després es comprova el resultat final.

Si busques informació sobre aquest tema trobaràs moltíssim material sobre PodSecurityPolicy (PSP). És important que sàpigues què eren, perquè apareixen constantment en documentació antiga, en respostes de fòrums i en manifests heretats. Però també que tinguis molt clar això:

Les PodSecurityPolicy van quedar obsoletes a Kubernetes 1.21 i es van eliminar del tot a la 1.25. En un clúster 1.30 no existeixen. Si un tutorial et diu que creïs una PodSecurityPolicy, aquell tutorial té com a mínim cinc anys.

Un recurs a nivell de clúster que descrivia què es permetia en un pod: si podia ser privilegiat, quins usuaris podia fer servir, quins volums, quines capacitats. La seva forma s'assemblava a això:

Conceptualment la idea era bona. La implementació tenia tres problemes greus que van resultar insalvables.

Una PSP no s'aplicava a ningú per si sola. S'"activava" concedint el verb use sobre ella mitjançant RBAC, i —això és el rar— al subjecte que creava el pod, que moltes vegades no era la persona sinó un controlador. Quan un Deployment creava pods, el subjecte rellevant era la ServiceAccount del controlador de ReplicaSets, no l'usuari que va fer el kubectl apply.

El resultat: ningú no sabia amb certesa quina política se li estava aplicant a un pod concret, i respondre a "per què s'ha rebutjat això?" era un exercici d'arqueologia.

Si a un subjecte se li aplicaven diverses PSP —cosa habitual— Kubernetes en triava una segons un algorisme complicat: primer les que no mutaven el pod, i si totes mutaven, la primera per ordre alfabètic. L'ordre alfabètic. Reanomenar una política canviava quina política s'aplicava.

Les PSP no només validaven: també modificaven el pod (omplien runAsUser, afegien fsGroup, treien capacitats). Això significava que el pod que s'executava no era el que hi havia al teu manifest, i que aplicar el mateix YAML a dos clústers podia donar resultats diferents sense cap avís.

A la pràctica, activar PSP en un clúster existent trencava gairebé tot, i com que no hi havia un mode "avisa'm però no bloquegis", el camí habitual era crear una PSP permissiva "temporal" que es quedava per sempre. La conclusió de la comunitat va ser clara: un mecanisme de seguretat que ningú no aconsegueix activar no protegeix ningú.

El substitut, el Pod Security Admission, es va dissenyar explícitament per corregir cadascun d'aquells defectes:

La contrapartida és que el PSA és molt menys flexible: només tres perfils, sense possibilitat de personalitzar-los. Aquell buit el cobreixen els motors de política de l'apartat 8.

Els Pod Security Standards (PSS) són tres perfils definits pel projecte Kubernetes. No són un recurs ni un objecte: són una especificació, un acord sobre què significa "segur" en tres nivells.

baseline permet afegir només aquestes, que són les del conjunt per defecte i totes relativament innòcues:

El que baseline prohibeix afegir és el veritablement perillós: NET_ADMIN, SYS_ADMIN, SYS_MODULE, SYS_PTRACE, BPF, NET_RAW...

restricted va molt més enllà: exigeix drop: ["ALL"] i només permet tornar a afegir NET_BIND_SERVICE. És exactament l'excepció de què vam parlar a 08-02 i per això dèiem que el port alt és preferible: amb port 8080 no necessites ni tan sols aquesta.

Fixa't que hi són tots els que fa servir Rutas Norte —emptyDir per als directoris d'escriptura, persistentVolumeClaim per a les dades de PostgreSQL, configMap i secret per a la configuració— i no hi ha hostPath. És la formalització de l'advertiment de 05-01.

Compara'l amb el bloc de "consell d'or" de 08-02: és pràcticament el mateix. Els Pod Security Standards no són altra cosa que la codificació oficial del que ja vam fer a mà. Tot el de la lliçó anterior encaixa ara en una etiqueta.

Nota important: restricted no exigeix readOnlyRootFilesystem. És una omissió coneguda (era massa disruptiva per a moltes càrregues) i una de les raons per les quals un motor de política complementa el PSA.

El Pod Security Admission (PSA) és el controlador que aplica els Pod Security Standards. Va integrat a l'apiserver des de 1.25: no cal instal·lar res, no hi ha cap pod que mantenir, no hi ha webhook que pugui caure.

S'activa posant etiquetes al Namespace:

La sintaxi de l'etiqueta és:

Els tres són independents i es poden combinar. Aquí hi ha la clau de l'adopció gradual: pots posar enforce: baseline (bloqueja el pitjor) juntament amb warn: restricted i audit: restricted (t'avisa del que encara no compleix, sense bloquejar).

Un detall essencial sobre enforce:

enforce només actua sobre pods que es creen o s'actualitzen. No afecta els que ja estan corrent. Si actives enforce: restricted en un namespace amb pods que no compleixen, aquests pods continuen funcionant tan tranquils... fins que el Deployment en creï un de nou, que fallarà. És una fallada diferida i desconcertant si no te l'esperes.

Per això warn i audit no bloquegen però sí que avaluen objectes que creen pods (Deployments, StatefulSets, CronJobs), avisant-te en el moment de l'apply. enforce, en canvi, només avalua el pod, no el Deployment. Hi tornarem a l'apartat 7.

Els Pod Security Standards evolucionen: en cada versió de Kubernetes s'hi poden afegir controls nous. Si no fixes la versió, el valor per defecte és latest, cosa que significa que una actualització del clúster pot començar a rebutjar pods que abans s'acceptaven, sense que ningú hagi tocat res.

Fixa sempre la versió. I quan actualitzis el clúster, apuja l'etiqueta com un canvi explícit i revisat, amb warn primer. És la diferència entre una actualització planificada i un incident el dilluns al matí.

Es pot indicar a l'apiserver un perfil per defecte per als namespaces que no portin etiquetes, mitjançant AdmissionConfiguration:

Això és molt potent perquè cobreix els namespaces futurs: si demà algú crea rutas-norte-experiments sense etiquetes, arrenca ja en baseline. Sense aquesta configuració, un namespace sense etiquetar equival a privileged, és a dir, sense cap restricció.

Requereix accés al pla de control, així que a Kubernetes gestionat (10-06) pot no estar disponible; en aquest cas, l'alternativa és una política de Kyverno que exigeixi les etiquetes a tot namespace nou (ho veurem a l'apartat 9).

Llegeix bé aquella sortida: el Deployment s'ha aplicat (configured), però l'avís enumera exactament els quatre camps que falten, contenidor per contenidor. És la millor documentació possible de què cal arreglar. Anota com de ben redactat està el missatge: cada línia et diu el camp, el contenidor i el valor esperat.

No activis mai enforce: restricted de cop en un namespace de producció. El camí correcte té quatre fases i pot durar setmanes. El recorrerem.

Aquí no es bloqueja res: el clúster continua funcionant igual. Ara cal provocar l'avaluació de totes les càrregues existents. Un truc molt útil és reaplicar els manifests sense canvis:

--dry-run=server envia l'objecte a l'apiserver, que el passa per tota la cadena d'admissió i retorna el resultat sense desar-lo. És la forma segura d'avaluar la situació completa.

I per veure el que avalua el mode audit, la font és el registre d'auditoria de l'apiserver, amb l'anotació pod-security.kubernetes.io/audit-violations. Ho veurem en detall a 08-06.

Una eina que estalvia molt de temps en aquesta fase:

També es pot consultar directament quins namespaces estan sense protecció:

Els <none> a enforce són namespaces on ara mateix s'hi pot desplegar qualsevol cosa, inclòs default. Aquella taula és una diapositiva excel·lent per a una reunió de seguretat.

baseline bloqueja el veritablement perillós —privilegiats, namespaces d'host, hostPath— i gairebé cap aplicació normal no l'incompleix. És un pas amb molt poc risc i molt valor.

Ara, si algú intenta desplegar un pod privilegiat:

Aquest és el moment en què la feina de 08-02 deixa de dependre de la memòria de ningú.

Abans de fer aquest pas, tots els components han de complir. Provem primer amb un manifest sense endurir per veure el missatge complet:

El missatge és una llista de tasques. Corregim:

A 08-02 vam deixar readOnlyRootFilesystem: false a PostgreSQL com a excepció documentada. Bona notícia: restricted no exigeix aquell camp, així que aquell punt no bloqueja. El que sí que exigeix és runAsNonRoot: true i drop: ["ALL"], que ja teníem. postgres-reserves passa restricted sense canvis.

Comprovem-ho abans de tocar el namespace:

Sense avisos. Perfecte.

I aquí no hi ha res per arreglar: el recol·lector necessita legítimament llegir /var/log del node i necessita ser root per fer-ho. És el tema de l'apartat següent.

Que rutas-norte-pre sigui igual d'estricte que producció és innegociable: si a preproducció es permet el que a producció no, la promoció falla just en el pitjor moment. Aquest és tot el sentit de tenir un entorn intermedi.

rutas-norte-dev en baseline és una concessió deliberada: bloqueja el perillós però permet, per exemple, córrer com a root per provar alguna cosa. Amb warn: restricted, el desenvolupador veu a cada apply exactament què li faltarà per promocionar. És una decisió d'equilibri que cal documentar.

Hi ha programari que no pot complir restricted, i no per deixadesa. El plugin CNI configura les interfícies de xarxa del node. El driver CSI munta volums al sistema de fitxers de l'amfitrió. El recol·lector de logs llegeix /var/log. L'agent de detecció en temps d'execució (Falco, que veurem a 08-06) observa crides al sistema.

La resposta correcta no és relaxar el perfil de rutas-norte-pro. És aïllar aquelles càrregues.

Tres decisions importants en aquell manifest:

1. audit i warn continuen en restricted. Encara que enforce sigui privileged, cada pod que se salti el perfil deixa rastre al registre d'auditoria. Així el namespace privilegiat no és un forat negre: sabem exactament què s'hi executa i amb quins privilegis.
2. L'anotació de justificació. Un namespace amb perfil privileged és una excepció de seguretat i ha d'estar documentada al mateix objecte, amb qui la revisa i quan.
3. RBAC estricte al damunt. Recordant 08-01: qui pot crear pods aquí pot crear pods privilegiats. Només plataforma ha de tenir permís, i a 08-01 vam veure que crear pods en un namespace equival a poder fer servir qualsevol ServiceAccount d'aquell namespace: una altra raó perquè les aplicacions no hi visquin.

I el complement imprescindible a RBAC:

El PSA admet exempcions globals per tres criteris:

Un avís sobre usernames: eximeix el subjecte a tots els namespaces, no només on t'interessa. És un permís molt ampli. L'exempció per namespace és més fàcil de raonar i d'auditar.

I l'advertiment general: cada exempció és una excepció de seguretat. Ha de tenir justificació escrita, responsable, i una revisió periòdica que confirmi que continua sent necessària. A Rutas Norte, la llista d'exempcions es revisa cada trimestre juntament amb el RBAC.

El PSA és excel·lent en el seu terreny, i el seu terreny és bastant estret. Conèixer-ne els límits evita confiar-hi per a coses que no fa.

El PSA avalua objectes Pod. Punt. No mira Services, ni Ingressos, ni PVCs, ni ConfigMaps, ni NetworkPolicies.

Això té un efecte pràctic incòmode amb enforce:

El Deployment es crea correctament, el ReplicaSet es crea, i és el ReplicaSet el que no aconsegueix crear pods. Qui va fer l'apply veu un èxit i ha d'anar a mirar els esdeveniments per descobrir el problema.

Per això warn és tan valuós: sí que avalua els objectes que creen pods i avisa en el moment de l'apply. Mantén sempre warn actiu encara que tinguis enforce, precisament per aquest motiu.

Coses que el PSA no pot exigir:

Aquella llista és exactament el buit que cobreixen Kyverno i Gatekeeper.

No pots crear un perfil "restricted però permetent hostPath en només lectura" ni "restricted més readOnlyRootFilesystem". Els perfils els defineix el projecte Kubernetes i són immutables.

És una virtut de disseny (evita el problema 3 de les PSP), però significa que el PSA mai no t'ajudarà omplint camps. Si vols que a tot pod se li afegeixi automàticament seccompProfile: RuntimeDefault, necessites un motor de política mutant.

La recomanació pràctica: PSA sempre, com a línia base que no pot fallar (és a l'apiserver, no depèn de cap pod), i al damunt un motor de política per a tota la resta.

Un motor de política és un webhook d'admissió: l'apiserver li envia cada objecte i ell respon si l'accepta, el rebutja o el modifica.

Això comporta una consideració operativa molt seriosa: el motor de política es converteix en una dependència de l'apiserver. Si el webhook està configurat amb failurePolicy: Fail i els pods del motor han caigut, ningú no pot crear res al clúster. S'han tombat clústers sencers així.

Les mitigacions habituals: diverses rèpliques del motor amb antiafinitat (06-05), un PodDisruptionBudget (09-05), i excloure kube-system dels webhooks per poder recuperar el clúster.

Recomanació per a Rutas Norte: Kyverno. Les raons són concretes:

• L'equip ja escriu YAML tot el dia. Aprendre Rego seria una barrera real perquè les polítiques les escriguin també els desenvolupadors.
• La verificació de signatures amb Cosign està integrada, i és just el que necessitarem a 08-05.
• La capacitat de generar objectes permet, per exemple, crear automàticament la NetworkPolicy deny-all de 04-06 en cada namespace nou.
• La mutació resol el "afegeix seccompProfile a tot" sense tocar cent manifests.

Gatekeeper és la millor opció si l'organització ja fa servir OPA per a altres coses (control d'accés a APIs, polítiques a Terraform) i vol un únic llenguatge de polítiques per a tot.

Tres rèpliques i un PDB: el motor de política és infraestructura crítica i cal tractar-la com a tal.

Una política de Kyverno és un ClusterPolicy (tot el clúster) o Policy (un namespace) amb una llista de regles.

Aquesta és probablement la política de més valor per línia escrita. Impedeix que es desplegui res que no hagi passat pel registre de l'empresa, on a 08-05 i 08-06 posarem l'escaneig i la signatura.

Desgranem el manifest:

• validationFailureAction: Enforce rebutja. L'alternativa és Audit, que només genera un informe. Igual que amb el PSA, es comença en Audit i es passa a Enforce quan ja no hi ha incompliments.
• background: true fa que Kyverno avaluï també els objectes que ja existeixen, produint PolicyReport. Sense això només veuries els objectes nous.
• match.any.resources defineix l'àmbit. Aquí, pods dels tres namespaces de Rutas Norte. kyverno, kube-system i rutas-norte-sistema queden fora perquè fan servir imatges d'infraestructura externes.
• =(initContainers) i =(ephemeralContainers): el prefix =() significa "si aquest camp existeix, ha de complir el patró". Sense ell, un pod sense initContainers fallaria la validació. No oblidis els contenidors efímers: són la via de kubectl debug (07-06) i sense aquesta línia algú podria injectar una imatge arbitrària en un pod de producció.
• El missatge apareix literalment al terminal de qui desplega. Escriure'l bé —què falla, per què, i què fer— estalvia moltíssimes preguntes.

Provant:

A 02-07 vam definir l'esquema d'etiquetes de Rutas Norte, i al mòdul 7 els quadres de comandament i les alertes en depenen. Una càrrega sense app.kubernetes.io/part-of: rutas-norte és invisible per al monitoratge.

Sintaxi de patrons de Kyverno que apareix aquí:

La segona regla és un detall que sembla menor i no ho és: una etiqueta entorn: dev en un manifest copiat a producció fa que Alertmanager encamini les alertes al canal de desenvolupament i ningú no s'assabenti d'una caiguda real. La política ho impedeix.

Fixa't que exigim limits.memory però no limits.cpu. És deliberat i és una decisió discutida: limitar la CPU provoca estrangulament (throttling) que pot degradar la latència d'api-reserves sense que es vegi clar per què, mentre que no limitar la memòria pot tombar el node. És un bon exemple de política que codifica una decisió tècnica de l'equip; ho tractarem a fons a 09-06.

Aquí brilla Kyverno davant del PSA:

Amb +(), si el manifest ja defineix securityContext, Kyverno no el toca; si no el defineix, l'afegeix. És una xarxa de seguretat, no una substitució de la feina de 08-02: el correcte continua sent declarar-ho explícitament al manifest, perquè qui el llegeixi sàpiga què s'està executant.

Un advertiment sobre mutar: és exactament el problema 3 de les PodSecurityPolicy. Fes-ho servir amb moderació i només per a valors per defecte segurs, mai per "arreglar" manifests incorrectes, perquè aleshores el YAML del repositori deixa de descriure el que corre.

Això garanteix que cap namespace de Rutas Norte no pugui existir sense la denegació per defecte que vam construir a 04-06. I synchronize: true fa que, si algú l'esborra, torni sola. És una capacitat que Gatekeeper no té i que resol un problema real.

Aquells informes són la llista de deures pendents i, amb background: true, es mantenen al dia sols. A 08-06 els convertirem en evidència per a auditories de compliment.

Des de Kubernetes 1.30, la ValidatingAdmissionPolicy permet escriure regles d'admissió dins de l'apiserver, sense webhook, fent servir expressions CEL (Common Expression Language).

Avantatges davant d'un motor extern:

Es compon de dos objectes: la política (què es comprova) i el binding (on s'aplica).

Punts a observar:

• validationActions compleix el mateix paper que els modes del PSA: [Warn, Audit] per provar, [Deny] quan n'estàs segur. Es poden combinar: [Deny, Audit].
• namespaceSelector aplica la política només als namespaces etiquetats com a part de Rutas Norte. Els de sistema queden fora.
• CEL té funcions molt llegibles: all(), exists(), has(), endsWith(), contains(), matches() per a expressions regulars.
• Separar política i binding permet escriure la regla una vegada i aplicar-la amb distinta severitat en distints entorns: [Warn] a dev i [Deny] a pro, amb dos bindings.

Prova:

Les VAP poden llegir configuració d'un recurs extern, cosa que les fa reutilitzables:

messageExpression construeix el missatge amb els valors reals, cosa que s'agraeix molt en depurar.

Fes servir VAP per a regles senzilles sobre camps: prohibir latest, exigir una etiqueta, limitar un valor numèric, comprovar un prefix. Són gratis en disponibilitat i no afegeixen cap peça per mantenir.

Fes servir Kyverno per a el que VAP no pot: verificar signatures d'imatges (08-05), generar objectes, mutar, o polítiques que necessiten consultar altres recursos del clúster.

I fes servir el PSA sempre com a línia base de securityContext, perquè està integrat i no pot fallar.

A Rutas Norte fem servir els tres, en capes:

Buscar tutorials de PodSecurityPolicy. Es van eliminar a la 1.25. Si un recurs et parla de kind: PodSecurityPolicy, està desactualitzat i probablement tota la resta també.

Activar enforce: restricted directament a producció. Els pods existents continuen corrent, però el primer reinici o la primera actualització falla. Recorre sempre les fases: warn/audit, després baseline, després restricted.

No fixar -version a les etiquetes. Sense ella es fa servir latest i una actualització del clúster pot rebutjar pods que abans passaven. Fixa la versió i puja-la com a canvi explícit.

Creure que enforce avisa en aplicar un Deployment. No: el PSA només avalua pods. El Deployment es crea i és el ReplicaSet el que falla, en un esdeveniment que cal anar a buscar. Mantén sempre warn actiu, que sí que avalua els objectes que creen pods.

Deixar namespaces sense etiquetar. Un namespace sense etiquetes de PSA equival a privileged. Comprova default i qualsevol namespace creat a mà; configura el valor per defecte a l'apiserver o exigeix les etiquetes amb Kyverno.

Relaxar el perfil de tot un namespace per una càrrega. Si el recol·lector de logs necessita hostPath, va a rutas-norte-sistema amb perfil privileged, no es baixa rutas-norte-pro a baseline.

Oblidar el RBAC del namespace privilegiat. Un namespace amb perfil privileged on desenvolupament pugui crear pods és pitjor que no tenir PSA: dona una falsa sensació de seguretat. I recorda de 08-01 que crear pods allà permet fer servir qualsevol ServiceAccount d'aquell namespace.

Fer servir failurePolicy: Fail sense alta disponibilitat del motor. Si Kyverno cau, ningú no pot crear res. Tres rèpliques, PDB i antiafinitat com a mínim, i exclou kube-system.

Oblidar initContainers i ephemeralContainers a les polítiques. Un initContainer amb una imatge sense verificar se salta tota la política de registre. Els contenidors efímers són la via de kubectl debug.

Posar validationFailureAction: Enforce des del primer dia. Igual que amb el PSA: primer Audit, mira els PolicyReport, arregla, i després Enforce.

Abusar de la mutació. Si Kyverno "arregla" els manifests, el YAML del repositori deixa de descriure el que corre. Fes-la servir només per a valors per defecte segurs.

Missatges d'error inútils. El missatge el llegeix una persona que està intentant desplegar. Digues-li què falla, per què existeix la regla i què ha de fer. Un bon missatge estalvia una interrupció a l'equip de plataforma.

Consell d'or: les polítiques són codi. Van a k8s/politiques/ del repositori, es revisen en petició de canvi, i es proven a rutas-norte-dev abans d'arribar a producció. Una política aplicada a mà a producció és exactament el mateix problema que un RoleBinding aplicat a mà.

L'equip crea rutas-norte-analitica per desplegar un servei d'agregació d'estadístiques d'ocupació. Escriu:

1. El manifest del Namespace a la fase 1 (avisar sense bloquejar) amb la versió fixada.
2. L'ordre que avaluaria un manifest existent contra el perfil sense desplegar-lo.
3. El manifest del Namespace en el seu estat final, atès que el servei ja està endurit.

En desplegar un component nou a rutas-norte-pro, que té enforce: restricted, obtens:

El manifest original:

1. Enumera les quatre violacions i explica què significa cadascuna.
2. Reescriu el manifest perquè compleixi restricted, sabent que NET_RAW es va afegir "per si de cas" i que el fitxer de /etc/rutasnorte/horaris és en realitat un fitxer de configuració estàtic.
3. Què hauries fet si NET_RAW fos realment imprescindible?

A 03-06 vam establir que les càrregues que no parlen amb l'API han de portar automountServiceAccountToken: false. Escriu un ClusterPolicy de Kyverno que:

• S'apliqui a Pods de rutas-norte-pre i rutas-norte-pro.
• Rebutgi els pods que no declarin automountServiceAccountToken explícitament (ni a true ni a false), obligant que sigui una decisió conscient.
• Exceptuï els pods la ServiceAccount dels quals sigui api-reserves o agent-inventari, que sí que necessiten el token.
• Inclogui un missatge que expliqui què fer.

Indica també com el desplegaries de forma segura.

Solució 1

1. Fase 1: avisar sense bloquejar

L'anotació amb data objectiu evita que "temporal" es converteixi en "permanent", que és com acaben gairebé totes les fases 1.

2. Avaluar sense desplegar

--dry-run=server passa l'objecte per tota la cadena d'admissió —PSA, VAP i Kyverno inclosos— i retorna el veredicte sense desar res. És diferent de --dry-run=client, que només valida el YAML localment i no detectaria res d'això.

3. Estat final

Es mantenen audit i warn encara que enforce ja bloquegi: warn continua avaluant els Deployments (que enforce no veu) i audit deixa constància al registre d'auditoria.

Solució 2

1. Les quatre violacions:

2. Manifest corregit:

Els quatre canvis i la seva justificació:

1. NET_RAW eliminat. Era "per si de cas": permet crear sockets en brut, cosa que serveix per fer ping i per inspeccionar trànsit. Un exportador d'horaris no ho necessita. Si el procés falla en arrencar, el log ho dirà i aleshores investigarem per què; no es concedeixen capacitats preventivament.
2. hostPath substituït per un ConfigMap. El fitxer era configuració estàtica, exactament per al que serveix un ConfigMap (03-01). A més de complir la política, això hi guanya: el fitxer deixa de dependre que algú l'hagi copiat a cada node, queda versionat a Git i és idèntic als tres entorns. La correcció de la política ha millorat el disseny, que és el que sol passar.
3. runAsNonRoot: true + runAsUser: 10005 declarats explícitament.
4. seccompProfile: RuntimeDefault al pod, heretat pel contenidor.

Extres que no exigia restricted però sí les polítiques de Kyverno de l'apartat 9: etiquetes de l'esquema, resources i automountServiceAccountToken: false. I readOnlyRootFilesystem: true, que cap política no exigeix però és la línia base de 08-02.

3. Si NET_RAW fos imprescindible:

El procés seria aquest, en ordre:

1. Qüestionar el requisit. Per què necessita sockets en brut un exportador d'horaris? En el 90 % dels casos hi ha una alternativa (una comprovació TCP en lloc d'ICMP, per exemple).
2. Si és real, fer servir una biblioteca que no ho necessiti o canviar el disseny.
3. Si no hi ha alternativa, no relaxar rutas-norte-pro. Es desplega en un namespace propi amb enforce: baseline (que sí que permet NET_RAW), amb RBAC restringit, amb justificació anotada, amb revisió trimestral i amb aprovació del professional de seguretat.
4. Documentar l'excepció al registre d'excepcions de seguretat, amb data de caducitat. Tornarem a aquest registre a 08-06.

El que mai no es fa és baixar rutas-norte-pro a baseline: això converteix una excepció d'un component en una excepció de tota la plataforma.

Solució 3

Notes sobre la solució:

• El patró "false | true" obliga que el camp existeixi amb un d'aquells dos valors. Si el camp no hi és, la validació falla, que és just el que demanava l'enunciat: convertir una omissió en una decisió.
• exclude.any.resources.subjects permet exceptuar per ServiceAccount. Una alternativa més mantenible a llarg termini seria exceptuar per una etiqueta (seguretat.rutasnorte.example/usa-api: "true"), per no haver d'editar la política cada vegada que una càrrega nova necessiti l'API.
• És una política de govern, no de bloqueig d'un atac: el seu valor està a forçar que algú hi pensi en cada desplegament.

Desplegament segur, en quatre passos:

I la verificació final:

Una precaució addicional important: abans de passar a Enforce, comprova que la política no bloqueja els controladors del sistema que creen pods en aquells namespaces (el controlador de ReplicaSets, el de Jobs). Si un controlador crea pods sense el camp, els teus desplegaments deixaran de funcionar. Provar-ho primer a rutas-norte-dev amb Enforce durant uns dies és la manera barata de descobrir-ho.

Hem convertit l'enduriment de 08-02 en una cosa que el clúster fa complir per si sol:

• El control d'admissió és la tercera porta: RBAC decideix si tens dret a l'operació, l'admissió decideix si l'objecte és acceptable. L'objecte rebutjat mai no arriba a etcd.
• Les PodSecurityPolicy són història: obsoletes a la 1.21, eliminades a la 1.25. Els seus tres defectes —RBAC contraintuïtiu, ordre alfabètic impredictible i mutació— expliquen el disseny del seu substitut.
• Els Pod Security Standards defineixen tres perfils: privileged (sense restriccions), baseline (bloqueja les escalades conegudes) i restricted (l'objectiu per a tota aplicació), que és essencialment la codificació oficial del que vam fer a mà a 08-02.
• El Pod Security Admission va integrat a l'apiserver i s'activa amb etiquetes al namespace, amb tres modes —enforce, audit, warn— que permeten l'adopció gradual. Fixa sempre -version perquè una actualització del clúster no trenqui res.
• L'adopció correcta és per fases: warn+audit, després enforce: baseline, després enforce: restricted. Mai de cop a producció. I rutas-norte-pre ha de ser tan estricte com rutas-norte-pro.
• Les càrregues que legítimament necessiten privilegis —CNI, CSI, recol·lector de logs— van a un namespace a part amb perfil privileged, RBAC restringit i justificació anotada. Mai no es relaxa el perfil de producció per una càrrega.
• El PSA té límits clars: només mira el pod, no pot exigir etiquetes, límits de recursos ni registres d'imatges, i no muta.
• Aquell buit el cobreixen Kyverno (YAML, muta, genera, verifica signatures: l'elecció de Rutas Norte) i OPA Gatekeeper (Rego, genèric més enllà de Kubernetes), i les ValidatingAdmissionPolicy amb CEL cobreixen les regles senzilles sense instal·lar res.
• Rutas Norte fa servir els tres en capes: PSA com a base infal·lible, VAP per a regles simples, Kyverno per al registre obligatori, les etiquetes de l'esquema, els límits de recursos i la generació automàtica de la NetworkPolicy deny-all.

Ara el clúster rebutja per si mateix un pod privilegiat, un que munti hostPath, un que corri com a root o un la imatge del qual no vingui del registre de l'empresa. Ningú no s'ho pot saltar per oblit.

Però tornem a mirar el conjunt. Hem protegit qui pot fer què (08-01) i què pot fer un contenidor (08-02 i 08-03). Falta una dimensió sencera: què pot parlar amb què. A 04-06 vam posar una NetworkPolicy deny-all a rutas-norte-pro i vam autoritzar les converses una a una, i ja aleshores vam assenyalar dos límits incòmodes: les polítiques treballen a L3/L4 —no entenen de rutes HTTP ni de mètodes— i no registren res, així que un intent de connexió denegat és invisible. A més, dins del clúster tot el trànsit viatja sense xifrar un cop passat el TLS de l'Ingress: qui pugui observar la xarxa del node veu les consultes a postgres-reserves en clar, amb les dades personals incloses. I el trànsit sortint continua pràcticament sense restringir, que és la via natural per la qual s'exfiltra una base de dades de clients.

La lliçó següent, 08-04, Seguretat de Xarxa, construeix l'estratègia completa sobre el que ja saps: microsegmentació, control del trànsit de sortida i el problema de les IP davant dels noms de domini, xifratge en trànsit amb mTLS i malles de serveis —Istio, Linkerd i Cilium comparades, amb el criteri honest de quan en cal una i quan no—, protecció del perímetre i del pla de control, i la visibilitat del trànsit que és just el que li falta a NetworkPolicy.