Cerramos el módulo con la lección que arregla el agujero que arrastramos desde el módulo 3: cualquier pod del clúster puede conectarse a postgres-reservas:5432. Un pod comprometido, una dependencia maliciosa en una imagen o un despliegue equivocado en rutas-norte-dev tienen hoy acceso directo a la base de datos con el nombre, el DNI, el teléfono y el correo de todos los clientes de Rutas Norte. Las NetworkPolicies son el cortafuegos nativo de Kubernetes, y en esta lección construiremos el modelo de aislamiento de la plataforma paso a paso: denegar todo, abrir el DNS —el fallo que tumba el clúster entero y que casi todo el mundo comete una vez—, y autorizar una por una únicamente las conversaciones que la plataforma necesita, verificando cada regla con pods efímeros.

1. Demostrar el problema: la red es plana
2. El requisito imprescindible: un CNI que las implemente
3. Anatomía de una NetworkPolicy
4. El modelo aditivo: solo se permite, nunca se deniega
5. from/to: podSelector, namespaceSelector e ipBlock
6. El error más caro: Y frente a O
7. Paso 1: denegar todo en rutas-norte-pro
8. Paso 2: permitir DNS (o romperlo todo)
9. Paso 3: las conversaciones de la plataforma
10. Paso 4: el Ingress y la pasarela de pagos externa
11. Verificación sistemática
12. Limitaciones reales

Antes de arreglar nada, veámoslo. Lanzamos en producción un pod que no tiene ninguna relación con la plataforma: sin etiquetas de Rutas Norte, sin ServiceAccount dedicada, sin nada.

Todo funciona. Es la regla 2 del modelo de red de 04-01: todo pod puede hablar con todo pod sin NAT. No es un fallo: es el comportamiento especificado. Y sus implicaciones son serias:

Ya hemos puesto capas —identidad mínima con ServiceAccounts (03-06) y cuotas por entorno (03-04)—; falta la capa de red.

Aquí está el peligro silencioso de esta lección. Kubernetes define el objeto NetworkPolicy, pero no lo aplica. Quien lo aplica es el plugin CNI, y si el plugin no lo implementa el objeto se crea sin ningún error ni aviso, kubectl get networkpolicy lo lista con normalidad, kubectl describe muestra las reglas perfectamente… y el tráfico sigue pasando exactamente igual. Tendrás una política de seguridad que no protege nada y una falsa sensación de estar cubierto. Como vimos en 04-01, Flannel no implementa NetworkPolicy, y es el CNI por defecto de muchísimas instalaciones de laboratorio, incluida la de minikube.

Alternativa: --cni=cilium, que además da políticas L7 y observabilidad con Hubble. Pero nunca confíes en el nombre del plugin: verifica con una prueba real (ejercicio 1). La idea es crear un pod diana en un namespace de usar y tirar, comprobar que responde, aplicar un deny-all de ingress y comprobar que deja de responder; si sigue respondiendo, tu CNI ignora las políticas. Hazlo siempre en un clúster nuevo, antes de escribir una sola política de verdad.

Tres avisos sobre policyTypes, que es donde más se falla: si lo omites, Kubernetes lo infiere (incluye Ingress siempre y Egress solo si hay bloque egress), así que escríbelo explícitamente; policyTypes: [Ingress] con ingress: [] significa "denegar toda la entrada", distinto de no tener el campo; y policyTypes: [Ingress, Egress] sin reglas es el aislamiento total. Y el punto clave: una NetworkPolicy tiene namespace y su podSelector solo mira dentro del suyo. Para proteger los tres entornos hacen falta las políticas en los tres.

El modelo mental que hay que fijar antes de escribir nada:

De ahí salen cuatro reglas de oro: sin políticas, todo pasa (el estado de Rutas Norte hasta ahora); en cuanto UNA política selecciona a un pod en una dirección, ese pod queda aislado en esa dirección y solo pasa lo explícitamente permitido; las políticas son aditivas y no existe "denegar" —no hay campo deny, la unión de todas las que seleccionan al pod define lo permitido y basta con que una lo autorice—; y no hay prioridades ni orden, ni order ni "la última gana".

Consecuencia práctica: no puedes hacer una excepción restrictiva. Si una política permite a todo rutas-norte-pro llegar a postgres-reservas, no puedes añadir otra que diga "menos este pod": hay que eliminar el permiso amplio y enumerar los permitidos. Otro detalle que confunde: ingress y egress se evalúan por separado y en ambos extremos, así que para que api-reservas hable con postgres-reservas hacen falta dos autorizaciones —el egress del emisor y el ingress del receptor—, y si falta cualquiera no hay conexión; es la causa número uno de "he permitido el tráfico y sigue sin funcionar". Por último, las políticas actúan sobre conexiones y los CNI que las implementan siguen el estado, así que la respuesta vuelve sin necesitar una regla de vuelta.

Hay exactamente tres formas de identificar el otro extremo.

Un podSelector dentro de from/to no puede alcanzar otros namespaces; para eso está el siguiente.

Kubernetes añade a cada namespace la etiqueta kubernetes.io/metadata.name con su nombre, lo que evita etiquetarlos a mano; aun así conviene poner etiquetas propias y estables (kubectl label namespace rutas-norte-pro entorno=pro).

Dos advertencias: no sirve para pods —aunque técnicamente una IP de pod esté en un CIDR, la implementación lo trata como tráfico externo y no es fiable; para pods, selectores— y except solo resta del cidr de ese mismo bloque, no es una denegación global. El patrón 0.0.0.0/0 con except de las redes privadas es el estándar para decir "puede salir a internet, pero no puede pivotar hacia la red interna de la empresa".

Este apartado es el que más incidentes de seguridad reales evita. Comparemos dos fragmentos que se diferencian en un guion:

La versión A abre la base de datos a namespaces enteros. Es un fallo que se cuela con facilidad en una revisión de código porque el YAML parece decir lo contrario, y el clúster no da ningún aviso: la política se aplica y funciona, solo que permite mucho más de lo previsto. Regla mnemotécnica: cada guion de la lista from es un "O"; los campos dentro de un mismo elemento son un "Y". La misma distinción aplica a los elementos de ingress (lista de reglas unidas por O) y a ports dentro de una regla.

Empezamos por el cimiento: cerrar todo, y después abrir lo justo, aunque durante unos minutos la plataforma quede rota.

La plataforma está completamente rota, y es lo que queríamos: a partir de aquí cada regla será una decisión consciente y documentada. Es el mínimo privilegio aplicado a la red. Nota importante: kubectl exec, kubectl logs y las sondas de salud del kubelet (07-01) no se ven afectados, porque vienen del nodo y no de otro pod; por eso puedes seguir depurando con un clúster totalmente cerrado.

Este es el fallo clásico de las NetworkPolicies, y merece apartado propio porque su síntoma despista muchísimo. Con deny-all activo ningún pod puede hablar con CoreDNS, y en los logs de api-reservas se ve esto:

El síntoma no es "conexión rechazada": es un fallo de resolución de nombres tras varios segundos de espera, el fallo tipo 1 de 04-03. La confusión típica es investigar CoreDNS, que está perfectamente sano, en lugar de mirar la política de egress recién aplicada. Agravante: un deny-all de egress en kube-system deja sin DNS a todo el clúster; nunca apliques políticas amplias en los namespaces del sistema.

Tres detalles que hay que respetar:

1. podSelector: {}: el DNS lo necesitan todos los pods, sin excepción. Es la primera regla que se escribe siempre.
2. UDP y TCP en el 53. Se olvida el TCP constantemente. El DNS cae a TCP cuando la respuesta no cabe en un paquete UDP, y en un Service headless con muchos pods eso pasa: el síntoma es demoledor, funciona casi siempre y falla de forma aparentemente aleatoria.
3. namespaceSelector + podSelector sin guion, para que sea la intersección: CoreDNS dentro de kube-system. Con guion abrirías todo kube-system. Verifica además la etiqueta real de esos pods (kubectl get pods -n kube-system --show-labels | grep dns); en algunas distribuciones es k8s-app: coredns.

Enumeramos, una a una, las conexiones legítimas de Rutas Norte:

Nada más: tienda-web no habla con la base de datos (sirve una SPA estática), redis-cache no inicia conexiones y postgres-reservas no sale a ningún sitio.

La primera es la política que justifica toda la lección: ningún otro pod del clúster puede ya intentar abrir una conexión a la base de datos con los datos personales. Y recuerda que allow-dns-egress y la segunda se suman: api-reservas sale al DNS, a PostgreSQL y a Redis, y a nada más. El egress de worker-notificaciones es análogo, con PostgreSQL y el correo corporativo.

El controlador vive en ingress-nginx, así que necesitamos namespaceSelector:

Dos detalles: los puertos son los del contenedor (targetPort), no los del Service, porque las políticas ven el tráfico real que llega al pod y kube-proxy ya tradujo el port en el nodo de origen (04-01) —poner el 80 en lugar del 8080 produce un 503 en el Ingress que cuesta mucho relacionar con una política—; y matchExpressions de 02-07 resuelve el "uno u otro" en el podSelector.

Está fuera del clúster, en pagos.proveedorexterno.example: los selectores no sirven, hay que usar ipBlock.

Puntos delicados: un ExternalName no ayuda aquí, porque el Service pasarela-pagos de 04-02 solo crea un CNAME y el tráfico real va a una IP externa que hay que autorizar por ipBlock; las políticas trabajan con IPs, no con nombres, así que si el proveedor cambia de rango la conexión se rompe sin aviso —usa el rango que publica y documenta, no la IP que devuelva un dig hoy—; el DNS ya está permitido por la política del paso 2, sin la cual api-reservas ni podría resolver el nombre; y si no hay rangos estables, la alternativa es un proxy de salida con lista blanca por dominio, o Cilium, con políticas FQDN.

Todo lo que no aparece en ese diagrama está denegado.

Una política sin verificar es una suposición: hay que comprobar las dos caras.

Y la prueba que da sentido a todo, con el pod intruso del apartado 1:

Tiempo de espera agotado. El agujero que arrastrábamos desde el módulo 3 está cerrado. Fíjate en el detalle: es tiempo agotado, no "conexión rechazada", porque las NetworkPolicies descartan los paquetes en silencio, sin enviar un RST. Esa firma sirve para diagnosticar:

Son imprescindibles y también claramente limitadas. Hay que saber qué no hacen.

Lo que aportarían Cilium o una malla en Rutas Norte: permitir solo GET /disponibilidad y POST /reservas en lugar de "el puerto 3000 entero"; identidad basada en certificados, de modo que crear un pod con app: api-reservas no baste para suplantar al componente; visibilidad de flujos permitidos y denegados, que convierte "esto se queda colgado" en "esta política concreta lo descartó"; y políticas por nombre de dominio para la pasarela de pagos.

Nada de eso quita valor a lo construido: las NetworkPolicies son la capa base y la que exige cualquier auditoría. La estrategia completa se estudia en 08-04.

• Escribir políticas con un CNI que las ignora. Se aplican sin error y no protegen nada. Verifica siempre con una prueba real, no con el nombre del plugin.
• Olvidar el DNS. El primer deny-all de egress rompe la resolución en todo el namespace y el síntoma (EAI_AGAIN) no apunta a la política: la regla de DNS es siempre la primera que se escribe. Y permitir solo UDP en el 53 falla de forma intermitente: autoriza UDP y TCP.
• El guion de más en from. Convierte un Y en un O y abre namespaces enteros. Reléelo en cada revisión de código.
• Autorizar solo una dirección (hacen falta el egress del emisor y el ingress del receptor), o usar el puerto del Service en lugar del targetPort: las políticas ven el puerto del contenedor.
• Aplicar deny-all en kube-system. Puedes dejar sin DNS, sin métricas y sin Ingress a todo el clúster.
• Esperar un "denegar" explícito (no existe: para restringir hay que quitar el permiso amplio) o confundir timed out con connection refused: el primero huele a política, el segundo a proceso caído.
• Consejo: aplica las políticas primero en rutas-norte-dev, verifica el guion de comprobación y solo entonces promociona a pre y pro. Un deny-all mal calculado en producción es una caída total.
• Consejo: nombra los ficheros con prefijo numérico (np-00-deny-all, np-01-allow-dns, ...) para que el orden de lectura refleje el orden de construcción.
• Consejo: documenta cada política con la conversación de negocio que autoriza. "worker-notificaciones lee la reserva para enviar el correo" envejece mucho mejor que "permite 5432".

Determina qué CNI está instalado y demuestra con una prueba práctica —no con el nombre del plugin— si las NetworkPolicies se aplican. Si no, recrea el perfil con Calico y repite.

Aplica en orden deny-all, la regla de DNS y las políticas de los apartados 9 y 10, documentando tras cada paso qué funciona y qué deja de funcionar. Al terminar, ejecuta el guion de verificación y comprueba que el pod intruso ya no llega a la base de datos.

Te llega esta política para revisar. Identifica el fallo, explica qué permite de más y corrígela.

Ejercicio 1

Con Flannel el curl responderá (las ignora); con Calico o Cilium agotará el tiempo. Si hay que reconstruir, minikube delete -p rutas-norte y recrear el perfil con --cni=calico.

Ejercicio 2

Ejercicio 3

El fallo son los dos guiones en from: el podSelector y el namespaceSelector son elementos distintos de la lista, así que se combinan con O. Lo que permite de más es enorme: cualquier pod, de cualquier namespace etiquetado entorno: pro, puede conectar a redis-cache:6379. La intención era "solo api-reservas" y el resultado es "todo el entorno de producción"; un pod comprometido en cualquier namespace de producción podría leer y envenenar la caché de disponibilidad de plazas.

Corrección: unir ambos selectores en un solo elemento (un Y), o simplemente dejar el podSelector, dado que la política ya vive en rutas-norte-pro.

Has cerrado el agujero: empezaste demostrando con un pod intruso que sin NetworkPolicies la red es plana y que cualquier contenedor del clúster llega a la base de datos con los datos personales de los clientes, y has terminado con esa misma prueba agotando el tiempo de espera. En el camino has fijado lo que más importa. Primero, que Kubernetes define el objeto pero no lo aplica: lo hace el CNI, y un plugin como Flannel acepta tus políticas sin una sola advertencia y no filtra nada, por lo que la única garantía aceptable es una prueba práctica en cada clúster. Segundo, el modelo aditivo: mientras ninguna política seleccione a un pod, todo pasa; en cuanto una lo hace, ese pod queda aislado en esa dirección y solo pasa lo explícitamente permitido; las políticas se suman, no hay prioridades y no existe denegar, lo que significa que no caben excepciones restrictivas. Tercero, que hacen falta las dos direcciones: el egress del emisor y el ingress del receptor. Y dominas los tres selectores —podSelector para el mismo namespace, namespaceSelector para cruzarlos e ipBlock con except para lo externo— y sobre todo la diferencia entre Y y O, ese guion de más que convierte "solo api-reservas" en "todo el entorno de producción" sin que el clúster diga nada.

Has construido el modelo completo de rutas-norte-pro en el orden correcto: deny-all primero, aunque rompa la plataforma; DNS después, con UDP y TCP hacia CoreDNS, evitando el fallo clásico cuyo síntoma (EAI_AGAIN) apunta a todas partes menos a la política que acabas de aplicar; y luego cada conversación de negocio autorizada una a una: api-reservas y worker-notificaciones hacia PostgreSQL, api-reservas hacia Redis, el controlador de Ingress hacia la tienda y la API por sus targetPort, y api-reservas hacia la pasarela de pagos por ipBlock. Todo verificado por ambas caras, sabiendo que un timed out huele a política y un connection refused a proceso caído. Y conoces los límites: L3/L4, sin identidad criptográfica, sin registro de denegaciones y sin nombres de dominio, ahí donde entran Cilium o una malla de servicio (08-04).

Con esto termina el módulo 4 y Rutas Norte es por primera vez una plataforma real y accesible. Los clientes entran por https://www.rutasnorte.example, las agencias consumen https://api.rutasnorte.example, los certificados se renuevan solos, el descubrimiento entre componentes va por DNS y la red está segmentada de modo que solo las conversaciones legítimas son posibles.

Queda una pieza que arrastramos desde el módulo 2 con una nota de "PROVISIONAL" en el manifiesto: postgres-reservas no tiene almacenamiento persistente. Su Deployment guarda los datos dentro del contenedor, así que cada reinicio del pod —un rollout, un desalojo, la caída de un nodo— borra todas las reservas y todos los clientes. El módulo 5, Almacenamiento en Kubernetes, resuelve exactamente eso: volúmenes, PersistentVolumes y PersistentVolumeClaims, clases de almacenamiento, aprovisionamiento dinámico con expansión y snapshots, y copias de seguridad y restauración. Es el módulo que convierte a Rutas Norte en una plataforma en la que se puede confiar.