Hem tancat dues dimensions de la seguretat de Rutas Norte. Amb RBAC (08-01) controlem qui pot fer què contra l'API. Amb els contextos de seguretat (08-02) i les polítiques d'admissió (08-03) controlem què pot fer un contenidor un cop està corrent, i vam aconseguir que el clúster ho fes complir per si sol.

Queda una dimensió sencera: què pot parlar amb què. I aquí ja vam fer feina important a 04-06, quan vam posar una NetworkPolicy deny-all a rutas-norte-pro i vam autoritzar cada conversa una a una. Però aleshores vam assenyalar tres límits incòmodes que vam deixar aparcats:

1. Les NetworkPolicies treballen a L3/L4: entenen d'IP i de ports, no de rutes HTTP ni de mètodes. api-reserves pot arribar a postgres-reserves, sí, però la política no distingeix entre una consulta legítima i un abocament complet de la taula de clients.
2. No registren res. Un intent de connexió denegat és completament invisible. Si algú està sondejant la xarxa interna, no ens n'assabentem.
3. Dins del clúster, tot el trànsit viatja sense xifrar un cop passat el TLS de l'Ingress (04-05). Qui pugui observar la xarxa del node veu les consultes a postgres-reserves en clar, amb noms, DNI i telèfons inclosos.

I hi ha una quarta cosa de la qual amb prou feines hem parlat: el trànsit sortint. És la via natural per la qual surt una base de dades de clients.

Aquesta lliçó no repeteix la sintaxi de NetworkPolicy: la dones per sabuda i la fem servir. El que construïm aquí és l'estratègia de xarxa completa d'una plataforma en producció, per capes.

Advertiment important. El disseny de l'arquitectura de xarxa d'una plataforma de producció l'ha de revisar un professional de seguretat, que avaluarà el model d'amenaces concret. I com que el trànsit de Rutas Norte transporta dades personals de clients —nom, DNI, telèfon i correu—, les decisions sobre xifratge en trànsit, control de sortida i registre de fluxos les han de conèixer i aprovar també el responsable de compliment normatiu. L'enfocament d'aquesta lliçó és exclusivament defensiu: entendre els camins pels quals es pot fugar informació per tancar-los i detectar-los.

1. Les capes de defensa en xarxa
2. Microsegmentació com a principi
3. Control del trànsit sortint
4. El problema de les IP davant dels noms de domini
5. Xifratge en trànsit dins del clúster
6. Què és una malla de serveis i què costa
7. Istio, Linkerd i Cilium comparats
8. Polítiques d'autorització de nivell 7
9. Protecció del perímetre
10. Seguretat del pla de control
11. Registre i visibilitat del trànsit
12. Confiança zero aplicada a Rutas Norte
13. Errors comuns i consells
14. Exercicis
15. Conclusió

La seguretat de xarxa no és un mecanisme: és una sèrie de capes, cadascuna de les quals assumeix que l'anterior pot fallar. Aquest és el model complet que construirem.

L'ordre importa: cada capa es justifica pel que passaria si l'anterior fallés. Si el WAF no atura un atac, l'Ingress encara valida el certificat. Si algú aconsegueix executar codi a botiga-web, la microsegmentació impedeix que arribi a postgres-reserves. Si hi arribés, el mTLS impediria que es fes passar per api-reserves. I si tot l'anterior fallés, el control de sortida impediria que les dades sortissin del clúster.

La microsegmentació consisteix a tractar cada càrrega de treball com el seu propi segment de xarxa, amb regles explícites de què pot parlar amb què. És el contrari del model tradicional de "xarxa interna de confiança darrere d'un tallafocs".

En una xarxa clàssica, el tallafocs separava "dins" de "fora", i a dins tothom es parlava. En un clúster de Kubernetes, per defecte, tots els pods poden parlar amb tots els pods de tots els namespaces. Un curl des de botiga-web arriba a postgres-reserves sense cap obstacle.

Recorda el que vam dir a 02-06: un namespace no és una frontera de seguretat per si sol. Sense NetworkPolicies, rutas-norte-dev i rutas-norte-pro són a la mateixa xarxa plana.

La conseqüència pràctica: si algú aconsegueix executar codi a botiga-web —el component més exposat, perquè atén directament internet— té accés de xarxa a tota la plataforma. La microsegmentació converteix això en "té accés de xarxa a api-reserves, i només al port 8080".

Principi 1: denegar per defecte als tres entorns.

A 04-06 vam aplicar deny-all a rutas-norte-pro. Això no n'hi ha prou. rutas-norte-dev i rutas-norte-pre també ho necessiten, per dues raons:

• Si desenvolupament i preproducció estan oberts, una política que funciona allà pot fallar a producció, i la fallada es descobreix en el pitjor moment.
• Un pod compromès a rutas-norte-dev sense restriccions de xarxa pot arribar a rutas-norte-pro, perquè la xarxa del clúster és plana.

A 08-03 vam resoldre això elegantment amb una política de Kyverno que genera la deny-all a tot namespace nou de Rutas Norte, amb synchronize: true perquè torni si algú l'esborra. És la garantia que cap namespace futur neixi obert.

Principi 2: polítiques per component, no per namespace.

És temptador escriure "tot el de rutas-norte-pro pot parlar amb tot el de rutas-norte-pro". És un error: reprodueix dins del namespace el mateix model pla que volíem evitar.

La diferència és enorme i el cost és escriure sis polítiques en lloc d'una.

Principi 3: revisió periòdica de quines converses continuen sent necessàries.

Les polítiques de xarxa es degraden igual que el RBAC. S'afegeix un permís per depurar i s'hi queda. Es retira un component i la seva política sobreviu. Es canvia un port i es deixa el vell "per si de cas".

La matriu de comunicacions autoritzades de Rutas Norte, tal com va quedar a 04-06, ha de cabre en una taula i revisar-se cada trimestre:

Cada fila ha de tenir un perquè viu. Una pregunta útil a la revisió: si esborro aquesta regla ara mateix, què es trenca? Si ningú no ho sap, cal esbrinar-ho (a preproducció) o treure-la.

Un guió per detectar polítiques orfes:

Aquella política va sobreviure al component que protegia. No és perillosa per si mateixa, però és soroll que dificulta la revisió, i si demà algú desplega alguna cosa amb aquella etiqueta hereta permisos que ningú no va decidir.

Aquí hi ha, probablement, el buit més greu que queda a Rutas Norte.

Pensa en la seqüència d'un incident:

1. Algú troba una fallada a api-reserves i aconsegueix executar codi.
2. El procés té accés legítim a postgres-reserves: pot llegir la taula de clients amb noms, DNI, telèfons i correus.
3. Ara necessita treure aquelles dades del clúster.

El pas 3 és el que converteix un compromís en una fuga de dades. Sense control de sortida, el pas 3 és trivial: una petició HTTPS a qualsevol servidor d'internet.

Regla que cal interioritzar: la política d'entrada limita qui entra; la política de sortida limita què pot sortir. Gairebé tothom escriu la primera i oblida la segona. I la segona és la que decideix si un incident es queda en "algú va executar codi" o escala a "es van filtrar les dades personals de 200.000 clients".

La majoria de les guies de NetworkPolicy només parlen d'Ingress. Comprova les teves polítiques: si policyTypes no inclou Egress, el trànsit de sortida està completament obert.

Auditem quines sortides són legítimes:

Quatre dels sis components no necessiten sortir a internet en absolut. Això és el primer que cal aprofitar: tancar-los la sortida del tot és gratis i elimina la via d'exfiltració per a la major part de la plataforma.

Recordant que a 04-06 vam deixar deny-all amb policyTypes: [Ingress, Egress], cada component necessita explícitament la seva sortida. El mínim universal és DNS:

Sense això, cap pod no resol noms i tot falla d'una forma molt confusa: els serveis no es troben entre si encara que les polítiques d'entrada estiguin bé. És l'error més freqüent en activar Egress per primera vegada.

api-reserves necessita arribar a pagos.proveedorexterno.example. Aquí és on apareix el problema de l'apartat següent, però vegem primer la solució amb ipBlock:

L'important d'aquest manifest no és el que permet, sinó el que no permet: api-reserves no pot connectar amb cap altra adreça d'internet. Si algú aconsegueix executar codi allà i vol enviar la taula de clients a un servidor propi, la connexió no surt.

Nota sobre ipBlock i les IP privades: ipBlock es refereix a IP de xarxa, i els pods del clúster també tenen IP. Un ipBlock: 0.0.0.0/0 inclouria tot el trànsit intern del clúster. Quan es vol "tot internet menys la xarxa interna", cal fer servir except:

Això és "qualsevol destí públic al 443", que és molt més lax que la llista de rangs del proveïdor i no ho recomanem per a api-reserves. Ho incloem perquè és un patró que apareix sovint i convé entendre per què és pitjor: permet enviar dades a qualsevol servidor d'internet que parli HTTPS.

Recorda de 06-04 que la connexió amb la passarel·la de pagaments passa per un contenidor ambaixador dins del pod d'api-reserves. Això té una conseqüència de xarxa important: com que els contenidors d'un pod comparteixen el namespace de xarxa, la política s'aplica al pod sencer, no al contenidor. L'ambaixador i el contenidor principal tenen exactament els mateixos permisos de xarxa.

L'ambaixador aporta altres avantatges —centralitza els reintents, la lògica de temps d'espera i les credencials de la passarel·la— però no és un límit de seguretat de xarxa. Si volguéssim que només l'ambaixador pogués parlar amb la passarel·la, hauria de ser un pod a part amb la seva pròpia política.

És un bon exemple d'una confusió comuna: el patró ambaixador és un patró d'arquitectura, no d'aïllament.

Aquí arriba la limitació estructural de les NetworkPolicies.

Les NetworkPolicies estàndard de Kubernetes treballen amb adreces IP i rangs CIDR. No entenen de noms de domini. No existeix un camp to: dnsName: pagos.proveedorexterno.example.

I això no és un descuit: les polítiques es tradueixen a regles de tallafocs al kernel del node, que actua sobre paquets IP. Quan el paquet hi arriba, el nom ja s'ha resolt i no en queda cap rastre.

Problema 1: les IP canvien. Els serveis al núvol roten adreces. La documentació del proveïdor de pagaments pot publicar rangs avui i canviar-los en tres mesos. Si el teu ipBlock es queda desfasat, els pagaments deixen de funcionar i el diagnòstic és especialment ingrat perquè res als logs no diu "una NetworkPolicy ha bloquejat això".

Problema 2: un rang és més del que vols. 203.0.113.0/24 són 256 adreces. Si el proveïdor comparteix infraestructura, aquell rang pot incloure servidors d'altres clients seus. Has autoritzat la sortida a 256 destins per arribar a un.

Problema 3: l'escenari invers és pitjor. Si un servei legítim comparteix IP amb un servei d'emmagatzematge genèric (cosa habitual als núvols públics), autoritzar el primer autoritza el segon, i aleshores sí que hi ha una via d'exfiltració.

És l'opció més portable i la que dona millor visibilitat. Un Squid o un proxy dedicat en un pod, amb una llista de dominis:

Les aplicacions es configuren amb HTTPS_PROXY, i la NetworkPolicy només permet sortir cap al proxy:

Avantatge decisiu: el proxy registra cada destí sol·licitat, permès o denegat. Això resol parcialment el problema de la manca de registre de les NetworkPolicies, almenys per al trànsit sortint, que és el que més importa vigilar.

Inconvenient honest: una aplicació que ignori les variables HTTPS_PROXY se salta el proxy. Per això la NetworkPolicy continua sent necessària: impedeix la sortida directa, obligant a passar pel proxy encara que l'aplicació no col·labori. Les dues capes juntes funcionen; cap per separat.

Si el CNI és Cilium, la CiliumNetworkPolicy permet escriure el nom directament:

Com funciona: Cilium intercepta les respostes DNS del pod, veu quina IP va retornar pagos.proveedorexterno.example i programa dinàmicament la regla per a aquella IP, amb el temps de vida que indiqui el registre DNS. Si demà el proveïdor canvia d'IP, la política continua funcionant sense que ningú toqui res.

És, amb diferència, la solució més elegant. El seu cost és la dependència del CNI: adoptar Cilium és una decisió de plataforma que va molt més enllà d'aquesta política.

Un enfocament en dos temps:

1. Ara: ipBlock amb els rangs publicats pel proveïdor, més un treball programat mensual que verifiqui que continuen sent vàlids i avisi si canvien. És la solució que funciona amb qualsevol CNI i no requereix peces noves.
2. A mitjà termini: proxy de sortida amb llista de permesos, principalment pel registre de destins. Si en algun moment es migra a Cilium (cosa que també aportaria els avantatges de l'apartat 11), se substitueixen les polítiques per toFQDNs.

I la comprovació que cal automatitzar en qualsevol cas:

Aquesta prova s'ha d'executar a rutas-norte-pre en cada desplegament. És la verificació de la capa que impedeix una fuga de dades personals, i com a tal hauria d'estar a l'expedient que revisa el responsable de compliment.

A 04-05 vam posar TLS a l'Ingress amb cert-manager: el trànsit entre el navegador del client i la plataforma va xifrat fins a https://www.rutasnorte.example. Perfecte. Però què passa després de l'Ingress?

Tot el que hi ha a la dreta de l'Ingress viatja sense xifrar per la xarxa del clúster. I per aquell tram passen, en clar:

• Les consultes SQL amb noms, DNI, telèfons i correus de clients.
• Les respostes de l'API amb les dades de les reserves.
• Les credencials de la base de dades, a la salutació inicial de cada connexió.

Aquesta és la pregunta que decideix si val la pena l'esforç:

Fixa't en com es connecten les lliçons: a 08-02 vam prohibir hostNetwork i CAP_NET_RAW, i a 08-03 vam fer que el clúster ho rebutgi. Aquella feina és el que fa que el trànsit intern sense xifrar sigui un risc acceptable en molts escenaris. El xifratge intern és la defensa per a quan aquella capa falla, o quan la normativa ho exigeix explícitament.

És el que ja fem amb la passarel·la de pagaments (l'ambaixador parla HTTPS). Per al trànsit intern significaria configurar PostgreSQL amb ssl = on, generar certificats, distribuir-los i configurar cada client.

Avantatge: xifra el tram que més importa (les dades personals) amb poc desplegament. Inconvenient: cal fer-ho component a component, gestionar la rotació de certificats i confiar que cada client verifiqui realment el certificat (molts clients de base de dades, per defecte, no ho fan).

Per a Rutas Norte, xifrar específicament la connexió amb postgres-reserves és una mesura d'alt valor i cost moderat, i probablement el primer pas a fer.

Diversos CNI poden xifrar automàticament tot el trànsit entre nodes amb WireGuard o IPsec.

Aquell últim punt és la limitació essencial: el xifratge del CNI protegeix contra qui observi la xarxa entre nodes, però no aporta identitat per servei. botiga-web i api-reserves al mateix node es parlen igual d'en clar, i cap dels dos pot demostrar criptogràficament qui és.

Tot i així, la relació valor/esforç és excel·lent. Si el CNI ho admet, activa-ho.

És l'apartat següent, perquè dona molt més que xifratge.

Una malla de serveis (service mesh) és una capa d'infraestructura que s'ocupa de la comunicació entre serveis, traient-la del codi de les aplicacions.

Al model clàssic, s'injecta un proxy sidecar (habitualment Envoy) a cada pod. Tot el trànsit que entra i surt del pod passa per aquell proxy, que és qui aplica el xifratge, l'autorització i la recollida de mètriques. L'aplicació no se n'assabenta: continua fent http://api-reserves:8080.

La identitat per càrrega de treball és la joia de la corona i mereix que l'entenguem bé. Sense malla, quan postgres-reserves rep una connexió des d'una IP, l'única cosa que sap és que ve d'aquella IP. Amb la NetworkPolicy sabem que aquella IP correspon a un pod amb l'etiqueta app: api-reserves... però les etiquetes les posa qui crea el pod, i una IP es pot suplantar.

Amb mTLS, postgres-reserves rep un certificat que diu spiffe://cluster.local/ns/rutas-norte-pro/sa/api-reserves, signat per l'autoritat certificadora del clúster, que ningú més no pot falsificar. Això sí que és identitat. I encaixa perfectament amb les ServiceAccounts de 03-06.

Aquesta és la part que les presentacions comercials passen per sobre:

Aquell últim punt té un exemple directe a Rutas Norte: el CronJob informes-ocupacio acaba la seva feina, però el sidecar continua corrent i el Job mai no es marca com a completat. Hi ha solucions (contenidors sidecar natius des de 1.29, o cridar el punt de terminació del proxy), però és exactament el tipus de fricció imprevista que apareix.

Respondrem amb honestedat, perquè és una decisió cara.

Arguments a favor:

• Transporta dades personals entre serveis i el xifratge intern és exigible en una anàlisi de risc seriosa.
• L'autorització L7 permetria regles com "només botiga-web pot fer POST /reserves", que NetworkPolicy no pot expressar.
• La identitat criptogràfica elimina la suplantació de serveis.

Arguments en contra:

• Són sis components. Una malla brilla amb desenes o centenars de microserveis i comunicacions complexes.
• El graf de crides és gairebé lineal: botiga-web → api-reserves → postgres-reserves/redis-cache. No hi ha una topologia que justifiqui una capa d'encaminament.
• L'equip de plataforma és petit. Afegir una malla mal operada pot empitjorar la seguretat (certificats caducats, polítiques mal enteses, actualitzacions ajornades).
• Bona part del benefici s'aconsegueix més barat: xifratge del CNI per al trànsit, TLS a PostgreSQL per al crític, i NetworkPolicies estrictes per a la segmentació.

Decisió per a Rutas Norte: no, encara no. El pla alternatiu:

1. Activar el xifratge WireGuard del CNI (una opció de configuració).
2. Configurar TLS a postgres-reserves, que és on són les dades personals.
3. Mantenir les NetworkPolicies estrictes amb control de sortida.
4. Revisar la decisió quan es compleixi algun d'aquests criteris objectius: més de quinze serveis, comunicació entre diversos equips que no es coordinen, un requisit normatiu explícit de mTLS, o la necessitat real de desplegaments canari per percentatge de trànsit.

I una recomanació general que va més enllà d'aquest curs:

Una malla de serveis és una resposta excel·lent a un problema que cal tenir primer. Adoptar-la "perquè és el modern", sense la complexitat que la justifica, afegeix risc operatiu sense afegir seguretat neta. Si l'operes malament, és pitjor que no tenir-la.

Dit això, cal conèixer-la, perquè el dia que la plataforma creixi serà la resposta correcta. Anem amb les opcions.

Istio en mode sidecar si necessites el conjunt de funcions més complet: encaminament sofisticat, multiclúster complex, integració amb passarel·les d'API, extensions amb WebAssembly. És l'opció amb més capacitat i també la que més costa operar. Necessites gent dedicada.

Istio en mode ambient és l'evolució que ataca el principal retret al model sidecar: el cost per pod. En lloc d'un proxy a cada pod, hi ha un agent per node (ztunnel) que dona mTLS i L4, i només es desplega un proxy L7 (waypoint) on de debò cal autorització de nivell 7. Redueix moltíssim el consum i elimina el problema dels Jobs que no acaben. Si avui haguéssim de triar Istio, seria aquest mode.

Linkerd si vols mTLS i observabilitat amb la mínima complexitat. El seu proxy en Rust és notablement lleuger i la seva filosofia és fer poques coses i fer-les bé. Per a una plataforma com Rutas Norte, si algun dia calgués una malla, aquesta seria la primera candidata: cobreix el que necessitem (mTLS, identitat, autorització bàsica) sense la superfície d'Istio.

Cilium Service Mesh si ja fas servir Cilium com a CNI. En integrar la malla al CNI evites una capa completa: el mTLS i les polítiques L4 s'apliquen en eBPF, dins del kernel, sense proxy. Només es desplega Envoy per a les polítiques L7. És l'opció més eficient, i a més porta les polítiques per nom de domini de l'apartat 4 i la visibilitat de Hubble de l'apartat 11. La contrapartida és que lliga la decisió de la malla a la del CNI.

Aquest és el buit concret que NetworkPolicy no pot omplir, i convé veure'l amb un exemple real.

La nostra política actual diu: botiga-web pot connectar amb api-reserves al port 8080. Això és tot el que pot expressar. Tan bon punt la connexió està oberta, botiga-web pot fer:

Una política L7 sí que pot distingir. Vegem com s'expressaria amb Istio, prenent l'exemple de l'enunciat: només api-reserves pot fer POST /reserves.

Amb action: ALLOW, tot el que no encaixi amb cap regla es denega. És el mateix principi de denegació per defecte de les NetworkPolicies, ara aplicat a mètodes i rutes HTTP.

Observa la línia clau:

Això no és una etiqueta ni una IP: és la identitat SPIFFE que la malla verifica criptogràficament a la salutació mTLS. Un pod no pot reclamar aquella identitat sense tenir la clau privada corresponent. I fixa't que es basa en la ServiceAccount, tancant el cercle amb 03-06 i 08-01: la ServiceAccount passa de ser només la identitat davant de l'API a ser també la identitat davant dels altres serveis.

Les dues són complementàries, no alternatives. La NetworkPolicy és la primera línia i la més barata; la política L7 és l'afinació. Si t'haguessis de quedar amb una, queda't amb la NetworkPolicy: sense ella, la política L7 protegeix un servei al qual qualsevol pot continuar connectant-se per altres vies.

Sense malla, l'autorització L7 la fa la mateixa aplicació. api-reserves pot validar al seu codi qui la crida:

Funciona i per a sis serveis és perfectament raonable, però té inconvenients reals: cal implementar-ho a cada servei, rotar els tokens a mà, i si algú llegeix el Secret (RBAC, 08-01) pot suplantar el servei. El mTLS de la malla resol les tres coses automàticament. És exactament el tipus de cost que va creixent amb el nombre de serveis i que, arribat un punt, justifica la malla.

Tot l'anterior protegeix l'interior. Ara, la porta d'entrada.

A 04-02 vam veure els tipus de Service. Repassem-ne la implicació de seguretat:

Per què NodePort no val a producció:

• Obre el port a tots els nodes, inclosos els que no executen el pod.
• Se salta l'Ingress, i amb ell el TLS (04-05), el WAF i la limitació de peticions.
• El port és en un rang alt i poc convencional, difícil de protegir amb un tallafocs convencional.
• No té nom: qualsevol que arribi a la IP del node arriba al servei.

I recorda de 08-02 que hostPort és encara pitjor, perquè ni tan sols hi ha un Service al davant.

La regla de Rutas Norte: un únic punt d'entrada, el balancejador de l'Ingress. Tota la resta és ClusterIP.

Un únic LoadBalancer, el de l'Ingress. Qualsevol altra línia en aquella sortida és una pregunta que cal respondre.

Un tallafocs d'aplicació web (WAF) inspecciona les peticions HTTP i bloqueja patrons d'atac coneguts: injecció SQL, execució de scripts entre llocs, recorregut de directoris. Amb ingress-nginx es pot activar ModSecurity amb el conjunt de regles OWASP:

Advertiment seriós sobre els WAF: un WAF mal ajustat bloqueja peticions legítimes. Si botiga-web deixa de poder crear reserves perquè una regla del WAF considera sospitós un nom amb apòstrof, has creat una incidència. El procediment correcte és idèntic al del PSA a 08-03:

1. SecRuleEngine DetectionOnly: registra però no bloqueja.
2. Analitzar els falsos positius durant setmanes de trànsit real.
3. Ajustar les regles problemàtiques.
4. Només aleshores, SecRuleEngine On.

I la limitació de peticions, per anotació a l'Ingress:

Les capçaleres, una a una:

Un detall sobre HSTS: max-age=31536000 són 365 dies, i els navegadors ho recorden. Si algun dia el teu TLS deixa de funcionar, els clients que ja van visitar el lloc no podran entrar per HTTP com a alternativa. És el desitjable des del punt de vista de seguretat, però cal ser-ne conscient abans d'activar-ho.

Un punt important que s'oblida: l'autoescalat no és una defensa contra la denegació de servei, és una manera de pagar-la. Si api-reserves escala a 50 rèpliques davant d'un atac, has convertit una caiguda en una factura. El límit superior de l'HPA (09-01) és també un control de seguretat i de cost.

Tot l'anterior protegeix les càrregues. El pla de control és l'objectiu de més valor: qui el controla, controla tot el clúster.

Una IP privada és bon senyal. Si veiessis una IP pública sense restricció d'origen, és una troballa de seguretat de primer nivell.

A Kubernetes gestionat (10-06), els tres grans proveïdors permeten restringir l'accés al punt final. És de les primeres coses que cal configurar en un clúster nou.

etcd guarda tot l'estat del clúster, inclosos els Secrets. Com vam dir a 03-02, si etcd no està xifrat, els Secrets són en clar al disc.

Xifratge en repòs:

Detall important: l'ordre dels proveïdors importa. El primer es fa servir per escriure; tots es fan servir per llegir. Tenir identity: {} al final permet llegir els objectes que es van escriure abans d'activar el xifratge. I després d'activar-lo, cal reescriure'ls:

Sense aquell pas, els Secrets antics continuen en clar a etcd per sempre.

Altres controls d'etcd:

Aquell punt de les còpies és fàcil de passar per alt i molt greu. A 05-06 vam parlar de Velero i de les dades personals; una còpia d'etcd conté, a més, totes les credencials del clúster. S'ha de xifrar, emmagatzemar amb accés restringit i registrat, i provar-ne la restauració periòdicament.

Cada node executa un kubelet amb una API al port 10250. Sense protecció, permet llistar pods, llegir logs i executar ordres en qualsevol contenidor d'aquell node.

Comprovació:

I una NetworkPolicy o regla de tallafocs que impedeixi als pods arribar al port 10250 dels nodes és una defensa molt rendible, perquè tanca una via d'escalada coneguda.

Recorda de 08-01 que el permís get nodes/proxy és de nivell crític precisament per això: permet parlar amb el kubelet i, a través d'ell, executar en qualsevol pod del node.

Els nodes del pla de control no han d'executar càrregues d'aplicació. Kubernetes ho aconsegueix amb un taint (06-05):

Aquell taint impedeix que s'hi planifiquin pods normals. La raó és directa: un pod en un node del pla de control està a una fallada de distància dels certificats del clúster i de la base de dades d'etcd.

I cal verificar que ningú no l'ha tolerat per comoditat:

Només components del sistema que legítimament corren a tots els nodes. Si hi aparegués un pod de rutas-norte-pro, cal investigar per què es va posar aquella tolerància. Compte amb la tolerància universal (operator: Exists sense key): tolera tots els taints, inclòs el del pla de control, i sovint es posa sense adonar-se'n.

Tornem al segon límit que vam assenyalar a 04-06: les NetworkPolicies no registren res.

Quan una NetworkPolicy denega una connexió, el paquet es descarta al kernel. No hi ha esdeveniment de Kubernetes, no hi ha log, no hi ha mètrica. Des del pod origen, la connexió simplement esgota el seu temps d'espera.

Les conseqüències són dues, i totes dues són dolentes:

Per operar: depurar "per què el meu servei no connecta" és dolorós. Pot ser DNS, una política, un Service mal configurat o l'aplicació. Res no et diu quin.

Per a la seguretat: si algú compromet un pod i comença a sondejar la xarxa interna, generarà desenes de connexions denegades i no se n'assabentarà ningú. Just el senyal més clar d'un moviment lateral és invisible.

Hubble, el component d'observabilitat de Cilium, resol això aprofitant que Cilium ja inspecciona cada paquet en eBPF.

Veure fluxos en temps real:

I el que de debò importa, les denegacions:

Llegeix-ho amb atenció, perquè aquella sortida explica una història completa. botiga-web —el component més exposat— ha intentat, en cinc segons: connectar amb la base de dades de clients, connectar amb la caché, sortir a internet per HTTPS i sortir a internet per SSH. botiga-web no fa res d'això en el seu funcionament normal. És exactament el patró d'algú explorant què pot arribar a assolir des d'un pod compromès.

Les polítiques van fer la seva feina: tot DROPPED. Però sense Hubble, això hauria passat completament desapercebut.

Hubble exposa mètriques Prometheus, així que s'integra directament amb el mòdul 7:

Aquella segona alerta és de les més valuoses de tota la plataforma: avisa d'una possible exfiltració de dades personals en curs. La ruta a Alertmanager i el seu encaminament són les del mòdul 7; l'única cosa nova és la font de la mètrica.

Per a Rutas Norte, sense Cilium avui, la combinació pràctica és: registre del proxy de sortida per al trànsit extern (que és el crític) i Falco per a les connexions anòmales, que veurem a la lliçó següent.

La confiança zero (zero trust) és un model que es resumeix en una frase: mai no confiïs, verifica sempre. Res no es considera de confiança per la seva ubicació a la xarxa.

La idea d'assumir el compromís és la que més canvia el disseny. No es tracta de "com evito que entrin", sinó de "quan entrin, què poden fer i en quant de temps me n'assabento?".

Les tres prioritats que surten d'aquesta taula, per ordre: control de sortida, visibilitat del trànsit i revisió del pla de control. Totes ataquen el mateix escenari: algú ja és a dins.

Escriure només polítiques d'Ingress. Si policyTypes no inclou Egress, la sortida està oberta i amb ella la via d'exfiltració. És l'error més greu i més freqüent d'aquesta lliçó.

Activar Egress i oblidar el DNS. Tot deixa de funcionar d'una forma molt confusa: els noms no resolen i sembla un problema de Service. La regla cap a kube-dns al port 53, UDP i TCP, és la primera que cal escriure.

Fer servir ipBlock: 0.0.0.0/0 sense except. Inclou la xarxa interna del clúster, així que la política és molt més permissiva del que sembla.

Confiar que els ipBlock d'un proveïdor extern no canvien. Canvien. Programa una verificació mensual o fes servir un proxy amb llista de dominis.

Creure que el contenidor ambaixador aïlla la xarxa. Comparteix el namespace de xarxa amb la resta del pod. És un patró d'arquitectura, no un límit de seguretat.

Escriure polítiques per namespace en lloc de per component. Reprodueix la xarxa plana dins del namespace. El cost de fer-ho bé són cinc polítiques més.

Deixar rutas-norte-dev i rutas-norte-pre sense polítiques. La xarxa del clúster és plana entre namespaces, i una política que només es prova a producció es prova en el pitjor moment.

Adoptar una malla de serveis sense necessitar-la. És infraestructura crítica: mal operada, empitjora la seguretat. Defineix criteris objectius per revisar la decisió.

Activar un WAF directament en mode bloqueig. Bloquejarà peticions legítimes i tindràs una incidència. DetectionOnly primer, setmanes d'anàlisi, i després bloqueig.

Fer servir NodePort a producció "perquè és més ràpid de configurar". Se salta el TLS, el WAF i la limitació de peticions, i obre el port a tots els nodes.

Oblidar que l'autoescalat no defensa de la denegació de servei. Converteix una caiguda en una factura. Posa un límit superior a l'HPA.

Xifrar etcd i no reescriure els Secrets existents. Els antics continuen en clar. kubectl get secrets -A -o json | kubectl replace -f -.

No xifrar les còpies de seguretat d'etcd. Una còpia d'etcd conté tots els Secrets del clúster.

Toleràncies universals. Un operator: Exists sense key tolera tots els taints, inclòs el del pla de control, i se sol posar sense adonar-se'n.

Consell d'or: dibuixa el diagrama de què parla amb què i comprova que les polítiques ho reprodueixen exactament, ni una fletxa més. Després, fes la pregunta clau: si comprometen aquest pod, on pot arribar i per on poden treure les dades? Si la resposta a la segona part no és "enlloc", hi ha feina pendent a l'egrés.

Quatre dels sis components de Rutas Norte no necessiten sortir a internet: botiga-web, postgres-reserves, redis-cache i informes-ocupacio. Escriu una única NetworkPolicy que els permeti només l'imprescindible dins del clúster i els tanqui completament la sortida a internet.

Tingues en compte que:

• Tots necessiten DNS.
• postgres-reserves i informes-ocupacio han de poder parlar entre si (el CronJob consulta la base de dades).
• botiga-web ha de poder arribar a api-reserves.
• Tots han de poder ser consultats per Prometheus.

Inclou l'ordre que verificaria que la sortida està efectivament tancada.

La direcció de Rutas Norte planteja desplegar Istio "perquè és el que fan servir les empreses grans". Prepara una resposta tècnica d'una pàgina que inclogui:

1. Quins problemes concrets resoldria a la plataforma actual.
2. Què costaria, de forma quantificada.
3. Quines alternatives més barates cobreixen part del benefici.
4. Criteris objectius i mesurables per revisar la decisió.
5. Una recomanació clara.

A les 03:47 salta l'alerta ConnexionsDenegadesAnomales. Consultes Hubble i obtens:

1. Què està passant? Justifica la teva lectura línia per línia.
2. Quines capes de defensa han funcionat i quines no?
3. Enumera les accions immediates, per ordre de prioritat.
4. Què hauria passat sense control de sortida? I sense Hubble?

Solució 1

I la política d'entrada perquè Prometheus pugui raspar mètriques (és Ingress, complementària):

Una observació important sobre la primera política: en fer servir un podSelector amb matchExpressions que agrupa quatre components, tots comparteixen les mateixes regles de sortida. Això vol dir que redis-cache tècnicament podria connectar amb api-reserves:8080, encara que no ho faci.

És un compromís conscient entre concisió i precisió. La versió estrictament correcta seria una política per component, i és el que recomanaríem a producció seguint el principi 2 de l'apartat 2. Aquesta versió agrupada és acceptable perquè l'objectiu declarat de l'exercici —tancar la sortida a internet— es compleix igualment, i cap dels permisos interns concedits de més no dona accés a dades personals. Documentar aquell raonament és tan important com el YAML.

Verificació:

Comprovar el DNS és tan important com comprovar el bloqueig: una política de sortida que bloqueja internet i el DNS trenca la plataforma sense que sigui evident per què.

Solució 2

Informe tècnic: adopció d'una malla de serveis a la plataforma Rutas Norte

1. Quins problemes resoldria

De sis problemes, un és urgent (xifratge) i cinc són millores desitjables sense urgència.

2. Cost quantificat

Amb Istio en mode ambient o amb Linkerd, la memòria i la latència baixarien substancialment. La complexitat operativa i el risc dels primers mesos, no.

3. Alternatives més barates

Les dues primeres juntes cobreixen el 80 % del benefici de seguretat per menys del 5 % del cost.

4. Criteris objectius per revisar la decisió

Es reobrirà l'avaluació quan es compleixi qualsevol d'aquests:

• La plataforma superi els 15 serveis amb comunicació entre ells.
• Més de tres equips despleguin al clúster sense coordinació diària.
• Aparegui un requisit normatiu o contractual explícit de mTLS entre serveis (per exemple, una certificació d'un client corporatiu).
• Calguin desplegaments canari per percentatge de trànsit que no es puguin aproximar amb rèpliques.
• Calgui encaminament entre diversos clústers (11-05).
• L'equip de plataforma arribi a 5 persones o més, amb capacitat per dedicar-ne una a la malla.

5. Recomanació

No adoptar una malla de serveis ara. En el seu lloc, en aquest ordre:

1. Activar WireGuard al CNI (aquesta setmana).
2. Configurar TLS a postgres-reserves (aquest trimestre).
3. Implantar visibilitat de fluxos (aquest trimestre).
4. Revisar la decisió cada sis mesos contra els criteris anteriors.

Si en el futur s'adopta, la primera candidata seria Linkerd per la seva relació entre benefici i complexitat, o Istio en mode ambient si per aleshores cal encaminament avançat.

Nota final: aquesta recomanació és una valoració d'arquitectura basada en la mida i la topologia actuals. L'ha de validar el professional de seguretat de l'organització, especialment pel que fa al xifratge del trànsit amb dades personals, on el responsable de compliment normatiu té l'última paraula sobre quin nivell de protecció és exigible.

Solució 3

1. Què està passant, línia per línia

La seqüència completa —quatre segons, tres ports diferents cap a la mateixa IP externa, sondeig de serveis interns, i tornada a la base de dades— no correspon a cap comportament legítim de worker-notificacions. La signatura és la d'un procés compromès buscant per on treure informació, i l'última línia suggereix que continua accedint a dades.

Un detall temporal important: són les 03:47. El CronJob informes-ocupacio corre a les 03:00. Caldrà descartar que hi hagi relació.

2. Capes que van funcionar i que no

3. Accions immediates, per prioritat

Les ordres dels dos primers passos:

En treure l'etiqueta app, el ReplicaSet detecta que li falta una rèplica i crea un pod nou i net: el servei es recupera sol mentre el pod compromès queda aïllat per a l'anàlisi. És una tècnica que convé tenir assajada abans de necessitar-la.

4. Els escenaris contrafactuals

Sense control de sortida: les tres connexions a 192.0.2.55 haurien estat FORWARDED. El procés tenia accés legítim a postgres-reserves, és a dir, a la taula de clients amb noms, DNI, telèfons i correus. Això hauria estat una fuga de dades personals consumada, amb obligació de notificació a l'autoritat de control i als afectats. La política d'egrés —aquelles línies de YAML que gairebé ningú no escriu— és l'única cosa que va separar un incident contingut d'una bretxa de dades.

Sense Hubble: no hi hauria alerta. Les connexions denegades són silencioses: sense registre de fluxos, el pod compromès hauria continuat consultant la base de dades indefinidament, i probablement hauria trobat abans o després una via de sortida (una configuració canviada, un permís nou, una política mal revisada). L'incident s'hauria descobert setmanes o mesos després, o mai.

Aquest exercici resumeix la lliçó sencera: la prevenció va fallar —sempre acaba fallant en algun punt—, la contenció va funcionar, i la detecció va permetre reaccionar. Les tres són necessàries, i la que més es descuida és la tercera.

Hem construït l'estratègia de xarxa completa de Rutas Norte, per capes:

• La microsegmentació parteix de denegar per defecte als tres entorns, amb polítiques per component i no per namespace, i amb revisió periòdica de quines converses continuen sent necessàries.
• El control del trànsit sortint és la capa que decideix si un compromís es converteix en una fuga de dades. Quatre dels sis components de Rutas Norte no necessiten sortir a internet en absolut, i tancar-los la sortida és la mesura de més valor per menys cost de tota la lliçó.
• Les NetworkPolicies treballen amb IP, no amb noms de domini. Les sortides són la passarel·la de sortida, el proxy amb llista de dominis permesos (que a més registra els destins) o les polítiques toFQDNs de Cilium.
• Dins del clúster, després del TLS de l'Ingress, tot viatja en clar. Les opcions són TLS a l'aplicació (prioritari per a postgres-reserves), xifratge a nivell de CNI amb WireGuard (barat i efectiu entre nodes) o mTLS amb una malla de serveis.
• Una malla de serveis dona identitat criptogràfica per càrrega, mTLS automàtic i autorització L7, a canvi de complexitat operativa, recursos i latència. Rutas Norte no la necessita avui, i hem fixat criteris objectius per revisar aquella decisió. Istio (sidecar o ambient), Linkerd i Cilium Service Mesh cobreixen perfils diferents.
• Al perímetre: un únic punt d'entrada (res de NodePort), WAF adoptat gradualment, limitació de peticions i capçaleres de seguretat.
• El pla de control mereix revisió pròpia: apiserver no exposat, etcd xifrat i amb els Secrets reescrits, còpies de seguretat xifrades, kubelet autenticat sense port de només lectura, i nodes de control aïllats amb taints.
• El que li falta a NetworkPolicy és registre. Hubble, o el registre d'un proxy de sortida, converteix el sondeig intern i els intents d'exfiltració en una cosa visible i alertable.
• La confiança zero es resumeix a assumir el compromís: no "com evito que entrin", sinó "quan entrin, què poden fer i en quant me n'assabento".

Amb això, la xarxa de Rutas Norte està segmentada, amb la sortida controlada i amb visibilitat del que passa. Però fixa't en una cosa: tot el que hem fet en aquest mòdul protegeix el clúster en temps d'execució. Donem per fet que les imatges que executem són les que ens pensem.

I aquella suposició és fràgil. registry.rutasnorte.example/api-reserves:2.7.1 és una etiqueta, i una etiqueta es pot reassignar: la imatge que es va descarregar ahir pot no ser la d'avui. La imatge base sobre la qual es va construir pot contenir programari que ningú no ha revisat. Les dependències que es van instal·lar durant la construcció vénen de repositoris públics. I res, absolutament res, no impedeix avui que algú amb accés al registre pugi una imatge modificada amb el mateix nom i que el clúster l'executi sense piular, amb tots els nostres securityContext perfectament aplicats a un contenidor que fa una cosa diferent de la que ens pensem.

La lliçó següent, 08-05, Seguretat d'Imatges, recorre la cadena de subministrament completa: on es pot enverinar una imatge, com construir imatges mínimes, per què el digest és l'única referència realment reproduïble, com signar amb Cosign i —el més important— com fer que el clúster rebutgi qualsevol imatge que no estigui signada, amb la política d'admissió que ho garanteix.