Tanquem el mòdul amb la lliçó que arregla el forat que arrosseguem des del mòdul 3: qualsevol pod del clúster es pot connectar a postgres-reserves:5432. Un pod compromès, una dependència maliciosa en una imatge o un desplegament equivocat a rutas-norte-dev tenen avui accés directe a la base de dades amb el nom, el DNI, el telèfon i el correu de tots els clients de Rutas Norte. Les NetworkPolicies són el tallafocs natiu de Kubernetes, i en aquesta lliçó construirem el model d'aïllament de la plataforma pas a pas: denegar-ho tot, obrir el DNS —la fallada que tomba el clúster sencer i que gairebé tothom comet un cop—, i autoritzar una per una únicament les converses que la plataforma necessita, verificant cada regla amb pods efímers.

1. Demostrar el problema: la xarxa és plana
2. El requisit imprescindible: un CNI que les implementi
3. Anatomia d'una NetworkPolicy
4. El model additiu: només es permet, mai es denega
5. from/to: podSelector, namespaceSelector i ipBlock
6. L'error més car: I davant d'O
7. Pas 1: denegar-ho tot a rutas-norte-pro
8. Pas 2: permetre el DNS (o trencar-ho tot)
9. Pas 3: les converses de la plataforma
10. Pas 4: l'Ingress i la passarel·la de pagaments externa
11. Verificació sistemàtica
12. Limitacions reals

Abans d'arreglar res, vegem-ho. Llancem en producció un pod que no té cap relació amb la plataforma: sense etiquetes de Rutas Norte, sense ServiceAccount dedicada, sense res.

Tot funciona. És la regla 2 del model de xarxa de 04-01: tot pod pot parlar amb tot pod sense NAT. No és una fallada: és el comportament especificat. I les seves implicacions són serioses:

Ja hem posat capes —identitat mínima amb ServiceAccounts (03-06) i quotes per entorn (03-04)—; falta la capa de xarxa.

Aquí hi ha el perill silenciós d'aquesta lliçó. Kubernetes defineix l'objecte NetworkPolicy, però no l'aplica. Qui l'aplica és el plugin CNI, i si el plugin no l'implementa l'objecte es crea sense cap error ni avís, kubectl get networkpolicy el llista amb normalitat, kubectl describe mostra les regles perfectament… i el trànsit continua passant exactament igual. Tindràs una política de seguretat que no protegeix res i una falsa sensació d'estar cobert. Com vam veure a 04-01, Flannel no implementa NetworkPolicy, i és el CNI per defecte de moltíssimes instal·lacions de laboratori, inclosa la de minikube.

Alternativa: --cni=cilium, que a més dona polítiques L7 i observabilitat amb Hubble. Però no confiïs mai en el nom del plugin: verifica-ho amb una prova real (exercici 1). La idea és crear un pod diana en un namespace d'usar i llençar, comprovar que respon, aplicar un deny-all d'ingress i comprovar que deixa de respondre; si continua responent, el teu CNI ignora les polítiques. Fes-ho sempre en un clúster nou, abans d'escriure una sola política de debò.

Tres avisos sobre policyTypes, que és on més es falla: si l'omets, Kubernetes l'infereix (inclou Ingress sempre i Egress només si hi ha bloc egress), així que escriu-lo explícitament; policyTypes: [Ingress] amb ingress: [] significa "denegar tota l'entrada", diferent de no tenir el camp; i policyTypes: [Ingress, Egress] sense regles és l'aïllament total. I el punt clau: una NetworkPolicy té namespace i el seu podSelector només mira dins del seu. Per protegir els tres entorns calen les polítiques als tres.

El model mental que cal fixar abans d'escriure res:

D'aquí surten quatre regles d'or: sense polítiques, tot passa (l'estat de Rutas Norte fins ara); tan bon punt UNA política selecciona un pod en una direcció, aquell pod queda aïllat en aquella direcció i només passa allò explícitament permès; les polítiques són additives i no existeix "denegar" —no hi ha camp deny, la unió de totes les que seleccionen el pod defineix el que és permès i n'hi ha prou que una ho autoritzi—; i no hi ha prioritats ni ordre, ni order ni "l'última guanya".

Conseqüència pràctica: no pots fer una excepció restrictiva. Si una política permet a tot rutas-norte-pro arribar a postgres-reserves, no en pots afegir una altra que digui "menys aquest pod": cal eliminar el permís ampli i enumerar els permesos. Un altre detall que confon: ingress i egress s'avaluen per separat i als dos extrems, així que perquè api-reserves parli amb postgres-reserves calen dues autoritzacions —l'egress de l'emissor i l'ingress del receptor—, i si en falta qualsevol no hi ha connexió; és la causa número u de "he permès el trànsit i continua sense funcionar". Finalment, les polítiques actuen sobre connexions i els CNI que les implementen segueixen l'estat, així que la resposta torna sense necessitar una regla de tornada.

Hi ha exactament tres maneres d'identificar l'altre extrem.

Un podSelector dins de from/to no pot arribar a altres namespaces; per a això hi ha el següent.

Kubernetes afegeix a cada namespace l'etiqueta kubernetes.io/metadata.name amb el seu nom, cosa que evita etiquetar-los a mà; tot i així convé posar etiquetes pròpies i estables (kubectl label namespace rutas-norte-pro entorn=pro).

Dues advertències: no serveix per a pods —encara que tècnicament una IP de pod sigui en un CIDR, la implementació ho tracta com a trànsit extern i no és fiable; per a pods, selectors— i except només resta del cidr d'aquell mateix bloc, no és una denegació global. El patró 0.0.0.0/0 amb except de les xarxes privades és l'estàndard per dir "pot sortir a internet, però no pot pivotar cap a la xarxa interna de l'empresa".

Aquest apartat és el que més incidents de seguretat reals evita. Comparem dos fragments que es diferencien en un guionet:

La versió A obre la base de dades a namespaces sencers. És una fallada que s'escola amb facilitat en una revisió de codi perquè el YAML sembla dir el contrari, i el clúster no dona cap avís: la política s'aplica i funciona, només que permet molt més del previst. Regla mnemotècnica: cada guionet de la llista from és un "O"; els camps dins d'un mateix element són un "I". La mateixa distinció s'aplica als elements d'ingress (llista de regles unides per O) i a ports dins d'una regla.

Comencem pel fonament: tancar-ho tot, i després obrir el just, encara que durant uns minuts la plataforma quedi trencada.

La plataforma està completament trencada, i és el que volíem: a partir d'aquí cada regla serà una decisió conscient i documentada. És el mínim privilegi aplicat a la xarxa. Nota important: kubectl exec, kubectl logs i les sondes de salut del kubelet (07-01) no es veuen afectats, perquè vénen del node i no d'un altre pod; per això pots continuar depurant amb un clúster totalment tancat.

Aquesta és la fallada clàssica de les NetworkPolicies, i mereix apartat propi perquè el seu símptoma despista moltíssim. Amb deny-all actiu cap pod no pot parlar amb CoreDNS, i als logs d'api-reserves es veu això:

El símptoma no és "connexió rebutjada": és una fallada de resolució de noms després de diversos segons d'espera, la fallada tipus 1 de 04-03. La confusió típica és investigar CoreDNS, que està perfectament sa, en lloc de mirar la política d'egress acabada d'aplicar. Agreujant: un deny-all d'egress a kube-system deixa sense DNS tot el clúster; no apliquis mai polítiques àmplies als namespaces del sistema.

Tres detalls que cal respectar:

1. podSelector: {}: el DNS el necessiten tots els pods, sense excepció. És la primera regla que s'escriu sempre.
2. UDP i TCP al 53. El TCP s'oblida constantment. El DNS cau a TCP quan la resposta no cap en un paquet UDP, i en un Service headless amb molts pods això passa: el símptoma és demolidor, funciona gairebé sempre i falla de manera aparentment aleatòria.
3. namespaceSelector + podSelector sense guionet, perquè sigui la intersecció: CoreDNS dins de kube-system. Amb guionet obriries tot kube-system. Verifica a més l'etiqueta real d'aquells pods (kubectl get pods -n kube-system --show-labels | grep dns); en algunes distribucions és k8s-app: coredns.

Enumerem, una a una, les connexions legítimes de Rutas Norte:

Res més: botiga-web no parla amb la base de dades (serveix una SPA estàtica), redis-cache no inicia connexions i postgres-reserves no surt enlloc.

La primera és la política que justifica tota la lliçó: cap altre pod del clúster no pot ja intentar obrir una connexió a la base de dades amb les dades personals. I recorda que allow-dns-egress i la segona se sumen: api-reserves surt al DNS, a PostgreSQL i a Redis, i a res més. L'egress de worker-notificacions és anàleg, amb PostgreSQL i el correu corporatiu.

El controlador viu a ingress-nginx, així que necessitem namespaceSelector:

Dos detalls: els ports són els del contenidor (targetPort), no els del Service, perquè les polítiques veuen el trànsit real que arriba al pod i kube-proxy ja va traduir el port al node d'origen (04-01) —posar el 80 en lloc del 8080 produeix un 503 a l'Ingress que costa molt de relacionar amb una política—; i matchExpressions de 02-07 resol l'"un o l'altre" al podSelector.

És fora del clúster, a pagos.proveedorexterno.example: els selectors no serveixen, cal fer servir ipBlock.

Punts delicats: un ExternalName no ajuda aquí, perquè el Service passarella-pagaments de 04-02 només crea un CNAME i el trànsit real va a una IP externa que cal autoritzar per ipBlock; les polítiques treballen amb IP, no amb noms, així que si el proveïdor canvia de rang la connexió es trenca sense avís —fes servir el rang que publica i documenta, no la IP que retorni un dig avui—; el DNS ja està permès per la política del pas 2, sense la qual api-reserves ni podria resoldre el nom; i si no hi ha rangs estables, l'alternativa és un proxy de sortida amb llista blanca per domini, o Cilium, amb polítiques FQDN.

Tot el que no apareix en aquell diagrama està denegat.

Una política sense verificar és una suposició: cal comprovar les dues cares.

I la prova que dona sentit a tot, amb el pod intrús de l'apartat 1:

Temps d'espera esgotat. El forat que arrossegàvem des del mòdul 3 està tancat. Fixa't en el detall: és temps esgotat, no "connexió rebutjada", perquè les NetworkPolicies descarten els paquets en silenci, sense enviar un RST. Aquesta signatura serveix per diagnosticar:

Són imprescindibles i també clarament limitades. Cal saber què no fan.

El que aportarien Cilium o una malla a Rutas Norte: permetre només GET /disponibilitat i POST /reserves en lloc de "el port 3000 sencer"; identitat basada en certificats, de manera que crear un pod amb app: api-reserves no n'hi hagi prou per suplantar el component; visibilitat de fluxos permesos i denegats, que converteix "això es queda penjat" en "aquesta política concreta ho va descartar"; i polítiques per nom de domini per a la passarel·la de pagaments.

Res d'això treu valor al que hem construït: les NetworkPolicies són la capa base i la que exigeix qualsevol auditoria. L'estratègia completa s'estudia a 08-04.

• Escriure polítiques amb un CNI que les ignora. S'apliquen sense error i no protegeixen res. Verifica-ho sempre amb una prova real, no amb el nom del plugin.
• Oblidar el DNS. El primer deny-all d'egress trenca la resolució a tot el namespace i el símptoma (EAI_AGAIN) no apunta a la política: la regla de DNS és sempre la primera que s'escriu. I permetre només UDP al 53 falla de manera intermitent: autoritza UDP i TCP.
• El guionet de més a from. Converteix un I en un O i obre namespaces sencers. Rellegeix-ho a cada revisió de codi.
• Autoritzar només una direcció (calen l'egress de l'emissor i l'ingress del receptor), o fer servir el port del Service en lloc del targetPort: les polítiques veuen el port del contenidor.
• Aplicar deny-all a kube-system. Pots deixar sense DNS, sense mètriques i sense Ingress tot el clúster.
• Esperar un "denegar" explícit (no existeix: per restringir cal treure el permís ampli) o confondre timed out amb connection refused: el primer fa olor de política, el segon de procés caigut.
• Consell: aplica les polítiques primer a rutas-norte-dev, verifica l'script de comprovació i només llavors promociona a pre i pro. Un deny-all mal calculat en producció és una caiguda total.
• Consell: anomena els fitxers amb prefix numèric (np-00-deny-all, np-01-allow-dns, ...) perquè l'ordre de lectura reflecteixi l'ordre de construcció.
• Consell: documenta cada política amb la conversa de negoci que autoritza. "worker-notificacions llegeix la reserva per enviar el correu" envelleix molt millor que "permet 5432".

Determina quin CNI hi ha instal·lat i demostra amb una prova pràctica —no amb el nom del plugin— si les NetworkPolicies s'apliquen. Si no, recrea el perfil amb Calico i repeteix.

Aplica en ordre deny-all, la regla de DNS i les polítiques dels apartats 9 i 10, documentant després de cada pas què funciona i què deixa de funcionar. En acabar, executa l'script de verificació i comprova que el pod intrus ja no arriba a la base de dades.

T'arriba aquesta política per revisar. Identifica la fallada, explica què permet de més i corregeix-la.

Exercici 1

Amb Flannel el curl respondrà (les ignora); amb Calico o Cilium esgotarà el temps. Si cal reconstruir, minikube delete -p rutas-norte i recrear el perfil amb --cni=calico.

Exercici 2

Exercici 3

La fallada són els dos guionets a from: el podSelector i el namespaceSelector són elements diferents de la llista, així que es combinen amb O. El que permet de més és enorme: qualsevol pod, de qualsevol namespace etiquetat entorn: pro, pot connectar a redis-cache:6379. La intenció era "només api-reserves" i el resultat és "tot l'entorn de producció"; un pod compromès en qualsevol namespace de producció podria llegir i enverinar la memòria cau de disponibilitat de places.

Correcció: unir tots dos selectors en un sol element (un I), o simplement deixar el podSelector, atès que la política ja viu a rutas-norte-pro.

Has tancat el forat: vas començar demostrant amb un pod intrús que sense NetworkPolicies la xarxa és plana i que qualsevol contenidor del clúster arriba a la base de dades amb les dades personals dels clients, i has acabat amb aquella mateixa prova esgotant el temps d'espera. Pel camí has fixat el que més importa. Primer, que Kubernetes defineix l'objecte però no l'aplica: ho fa el CNI, i un plugin com Flannel accepta les teves polítiques sense una sola advertència i no filtra res, per la qual cosa l'única garantia acceptable és una prova pràctica a cada clúster. Segon, el model additiu: mentre cap política no seleccioni un pod, tot passa; tan bon punt una ho fa, aquell pod queda aïllat en aquella direcció i només passa allò explícitament permès; les polítiques se sumen, no hi ha prioritats i no existeix denegar, cosa que significa que no hi caben excepcions restrictives. Tercer, que calen les dues direccions: l'egress de l'emissor i l'ingress del receptor. I domines els tres selectors —podSelector per al mateix namespace, namespaceSelector per creuar-los i ipBlock amb except per a allò extern— i sobretot la diferència entre I i O, aquell guionet de més que converteix "només api-reserves" en "tot l'entorn de producció" sense que el clúster digui res.

Has construït el model complet de rutas-norte-pro en l'ordre correcte: deny-all primer, encara que trenqui la plataforma; DNS després, amb UDP i TCP cap a CoreDNS, evitant la fallada clàssica el símptoma de la qual (EAI_AGAIN) apunta a tot arreu menys a la política que acabes d'aplicar; i després cada conversa de negoci autoritzada una a una: api-reserves i worker-notificacions cap a PostgreSQL, api-reserves cap a Redis, el controlador d'Ingress cap a la botiga i l'API pels seus targetPort, i api-reserves cap a la passarel·la de pagaments per ipBlock. Tot verificat per totes dues cares, sabent que un timed out fa olor de política i un connection refused de procés caigut. I coneixes els límits: L3/L4, sense identitat criptogràfica, sense registre de denegacions i sense noms de domini, allà on entren Cilium o una malla de servei (08-04).

Amb això acaba el mòdul 4 i Rutas Norte és per primera vegada una plataforma real i accessible. Els clients entren per https://www.rutasnorte.example, les agències consumeixen https://api.rutasnorte.example, els certificats es renoven sols, el descobriment entre components va per DNS i la xarxa està segmentada de manera que només les converses legítimes són possibles.

Queda una peça que arrosseguem des del mòdul 2 amb una nota de "PROVISIONAL" al manifest: postgres-reserves no té emmagatzematge persistent. El seu Deployment desa les dades dins del contenidor, així que cada reinici del pod —un rollout, un desallotjament, la caiguda d'un node— esborra totes les reserves i tots els clients. El mòdul 5, Emmagatzematge a Kubernetes, resol exactament això: volums, PersistentVolumes i PersistentVolumeClaims, classes d'emmagatzematge, aprovisionament dinàmic amb expansió i snapshots, i còpies de seguretat i restauració. És el mòdul que converteix Rutas Norte en una plataforma en què es pot confiar.