Hemos cerrado dos dimensiones de la seguridad de Rutas Norte. Con RBAC (08-01) controlamos quién puede hacer qué contra la API. Con los contextos de seguridad (08-02) y las políticas de admisión (08-03) controlamos qué puede hacer un contenedor una vez está corriendo, y conseguimos que el clúster lo haga cumplir por sí solo.

Queda una dimensión entera: qué puede hablar con qué. Y aquí ya hicimos trabajo importante en 04-06, cuando pusimos una NetworkPolicy deny-all en rutas-norte-pro y autorizamos cada conversación una a una. Pero entonces señalamos tres límites incómodos que dejamos aparcados:

1. Las NetworkPolicies trabajan en L3/L4: entienden de IP y de puertos, no de rutas HTTP ni de métodos. api-reservas puede llegar a postgres-reservas, sí, pero la política no distingue entre una consulta legítima y un volcado completo de la tabla de clientes.
2. No registran nada. Un intento de conexión denegado es completamente invisible. Si alguien está sondeando la red interna, no nos enteramos.
3. Dentro del clúster, todo el tráfico viaja sin cifrar una vez pasado el TLS del Ingress (04-05). Quien pueda observar la red del nodo ve las consultas a postgres-reservas en claro, con nombres, DNI y teléfonos incluidos.

Y hay una cuarta cosa de la que apenas hemos hablado: el tráfico saliente. Es la vía natural por la que sale una base de datos de clientes.

Esta lección no repite la sintaxis de NetworkPolicy: la das por sabida y la usamos. Lo que construimos aquí es la estrategia de red completa de una plataforma en producción, por capas.

Advertencia importante. El diseño de la arquitectura de red de una plataforma de producción debe revisarlo un profesional de seguridad, que evaluará el modelo de amenazas concreto. Y como el tráfico de Rutas Norte transporta datos personales de clientes —nombre, DNI, teléfono y correo—, las decisiones sobre cifrado en tránsito, control de salida y registro de flujos deben conocerlas y aprobarlas también el responsable de cumplimiento normativo. El enfoque de esta lección es exclusivamente defensivo: entender los caminos por los que puede fugarse información para cerrarlos y detectarlos.

1. Las capas de defensa en red
2. Microsegmentación como principio
3. Control del tráfico saliente
4. El problema de las IP frente a los nombres de dominio
5. Cifrado en tránsito dentro del clúster
6. Qué es una malla de servicio y qué cuesta
7. Istio, Linkerd y Cilium comparados
8. Políticas de autorización de nivel 7
9. Protección del perímetro
10. Seguridad del plano de control
11. Registro y visibilidad del tráfico
12. Confianza cero aplicada a Rutas Norte
13. Errores comunes y consejos
14. Ejercicios
15. Conclusión

La seguridad de red no es un mecanismo: es una serie de capas, cada una de las cuales asume que la anterior puede fallar. Este es el modelo completo que vamos a construir.

El orden importa: cada capa se justifica por lo que ocurriría si la anterior fallase. Si el WAF no detiene un ataque, el Ingress todavía valida el certificado. Si alguien consigue ejecutar código en tienda-web, la microsegmentación impide que llegue a postgres-reservas. Si consiguiera llegar, el mTLS impediría que se hiciera pasar por api-reservas. Y si todo lo anterior fallase, el control de salida impediría que los datos salieran del clúster.

La microsegmentación consiste en tratar cada carga de trabajo como su propio segmento de red, con reglas explícitas de qué puede hablar con qué. Es lo contrario del modelo tradicional de "red interna de confianza detrás de un cortafuegos".

En una red clásica, el cortafuegos separaba "dentro" de "fuera", y dentro todo el mundo se hablaba. En un clúster de Kubernetes, por defecto, todos los pods pueden hablar con todos los pods de todos los namespaces. Un curl desde tienda-web llega a postgres-reservas sin obstáculo.

Recuerda lo que dijimos en 02-06: un namespace no es una frontera de seguridad por sí solo. Sin NetworkPolicies, rutas-norte-dev y rutas-norte-pro están en la misma red plana.

La consecuencia práctica: si alguien consigue ejecutar código en tienda-web —el componente más expuesto, porque atiende directamente a internet— tiene acceso de red a toda la plataforma. La microsegmentación convierte eso en "tiene acceso de red a api-reservas, y solo al puerto 8080".

Principio 1: denegar por defecto en los tres entornos.

En 04-06 aplicamos deny-all en rutas-norte-pro. Eso no basta. rutas-norte-dev y rutas-norte-pre también lo necesitan, por dos razones:

• Si desarrollo y preproducción están abiertos, una política que funciona ahí puede fallar en producción, y el fallo se descubre en el peor momento.
• Un pod comprometido en rutas-norte-dev sin restricciones de red puede alcanzar rutas-norte-pro, porque la red del clúster es plana.

En 08-03 resolvimos esto elegantemente con una política de Kyverno que genera la deny-all en todo namespace nuevo de Rutas Norte, con synchronize: true para que vuelva si alguien la borra. Es la garantía de que ningún namespace futuro nazca abierto.

Principio 2: políticas por componente, no por namespace.

Es tentador escribir "todo lo de rutas-norte-pro puede hablar con todo lo de rutas-norte-pro". Es un error: reproduce dentro del namespace el mismo modelo plano que queríamos evitar.

La diferencia es enorme y el coste es escribir seis políticas en lugar de una.

Principio 3: revisión periódica de qué conversaciones siguen siendo necesarias.

Las políticas de red se degradan igual que el RBAC. Se añade un permiso para depurar y se queda. Se retira un componente y su política sobrevive. Se cambia un puerto y se deja el viejo "por si acaso".

La matriz de comunicaciones autorizadas de Rutas Norte, tal como quedó en 04-06, debe caber en una tabla y revisarse cada trimestre:

Cada fila debe tener un porqué vivo. Una pregunta útil en la revisión: si borro esta regla ahora mismo, ¿qué se rompe? Si nadie lo sabe, hay que averiguarlo (en preproducción) o quitarla.

Un guion para detectar políticas huérfanas:

Esa política sobrevivió al componente que protegía. No es peligrosa por sí misma, pero es ruido que dificulta la revisión, y si mañana alguien despliega algo con esa etiqueta hereda permisos que nadie decidió.

Aquí está, probablemente, el hueco más grave que queda en Rutas Norte.

Piensa en la secuencia de un incidente:

1. Alguien encuentra un fallo en api-reservas y consigue ejecutar código.
2. El proceso tiene acceso legítimo a postgres-reservas: puede leer la tabla de clientes con nombres, DNI, teléfonos y correos.
3. Ahora necesita sacar esos datos del clúster.

El paso 3 es el que convierte un compromiso en una fuga de datos. Sin control de salida, el paso 3 es trivial: una petición HTTPS a cualquier servidor de internet.

Regla que hay que interiorizar: la política de entrada limita quién entra; la política de salida limita qué puede salir. Casi todo el mundo escribe la primera y olvida la segunda. Y la segunda es la que decide si un incidente se queda en "alguien ejecutó código" o escala a "se filtraron los datos personales de 200.000 clientes".

La mayoría de las guías de NetworkPolicy solo hablan de Ingress. Comprueba tus políticas: si policyTypes no incluye Egress, el tráfico de salida está completamente abierto.

Auditemos qué salidas son legítimas:

Cuatro de los seis componentes no necesitan salir a internet en absoluto. Eso es lo primero que hay que aprovechar: cerrarles la salida por completo es gratis y elimina la vía de exfiltración para la mayor parte de la plataforma.

Recordando que en 04-06 dejamos deny-all con policyTypes: [Ingress, Egress], cada componente necesita explícitamente su salida. Lo mínimo universal es DNS:

Sin esto, ningún pod resuelve nombres y todo falla de una forma muy confusa: los servicios no se encuentran entre sí aunque las políticas de ingreso estén bien. Es el error más frecuente al activar Egress por primera vez.

api-reservas necesita llegar a pagos.proveedorexterno.example. Aquí es donde aparece el problema del apartado siguiente, pero veamos primero la solución con ipBlock:

Lo importante de este manifiesto no es lo que permite, sino lo que no permite: api-reservas no puede conectar con ninguna otra dirección de internet. Si alguien consigue ejecutar código ahí y quiere enviar la tabla de clientes a un servidor propio, la conexión no sale.

Nota sobre ipBlock y las IP privadas: ipBlock se refiere a IP de red, y los pods del clúster también tienen IP. Un ipBlock: 0.0.0.0/0 incluiría todo el tráfico interno del clúster. Cuando se quiere "todo internet menos la red interna", hay que usar except:

Esto es "cualquier destino público en el 443", que es mucho más laxo que la lista de rangos del proveedor y no lo recomendamos para api-reservas. Lo incluimos porque es un patrón que aparece a menudo y conviene entender por qué es peor: permite enviar datos a cualquier servidor de internet que hable HTTPS.

Recuerda de 06-04 que la conexión con la pasarela de pagos pasa por un contenedor embajador dentro del pod de api-reservas. Eso tiene una consecuencia de red importante: como los contenedores de un pod comparten el namespace de red, la política se aplica al pod entero, no al contenedor. El embajador y el contenedor principal tienen exactamente los mismos permisos de red.

El embajador aporta otras ventajas —centraliza los reintentos, la lógica de tiempo de espera y las credenciales de la pasarela— pero no es un límite de seguridad de red. Si quisiéramos que solo el embajador pudiera hablar con la pasarela, tendría que ser un pod aparte con su propia política.

Es un buen ejemplo de una confusión común: el patrón embajador es un patrón de arquitectura, no de aislamiento.

Aquí llega la limitación estructural de las NetworkPolicies.

Las NetworkPolicies estándar de Kubernetes trabajan con direcciones IP y rangos CIDR. No entienden de nombres de dominio. No existe un campo to: dnsName: pagos.proveedorexterno.example.

Y esto no es un descuido: las políticas se traducen a reglas de cortafuegos en el kernel del nodo, que actúa sobre paquetes IP. Cuando el paquete llega ahí, el nombre ya se resolvió y no queda rastro de él.

Problema 1: las IP cambian. Los servicios en la nube rotan direcciones. La documentación del proveedor de pagos puede publicar rangos hoy y cambiarlos en tres meses. Si tu ipBlock se queda desfasado, los pagos dejan de funcionar y el diagnóstico es especialmente ingrato porque nada en los logs dice "una NetworkPolicy ha bloqueado esto".

Problema 2: un rango es más de lo que quieres. 203.0.113.0/24 son 256 direcciones. Si el proveedor comparte infraestructura, ese rango puede incluir servidores de otros clientes suyos. Has autorizado la salida a 256 destinos para llegar a uno.

Problema 3: el escenario inverso es peor. Si un servicio legítimo comparte IP con un servicio de almacenamiento genérico (algo habitual en las nubes públicas), autorizar el primero autoriza el segundo, y ahí sí hay una vía de exfiltración.

Es la opción más portátil y la que da mejor visibilidad. Un Squid o un proxy dedicado en un pod, con una lista de dominios:

Las aplicaciones se configuran con HTTPS_PROXY, y la NetworkPolicy solo permite salir hacia el proxy:

Ventaja decisiva: el proxy registra cada destino solicitado, permitido o denegado. Eso resuelve parcialmente el problema de la falta de registro de las NetworkPolicies, al menos para el tráfico saliente, que es el que más importa vigilar.

Inconveniente honesto: una aplicación que ignore las variables HTTPS_PROXY se salta el proxy. Por eso la NetworkPolicy sigue siendo necesaria: impide la salida directa, obligando a pasar por el proxy aunque la aplicación no coopere. Las dos capas juntas funcionan; ninguna por separado.

Si el CNI es Cilium, la CiliumNetworkPolicy permite escribir el nombre directamente:

Cómo funciona: Cilium intercepta las respuestas DNS del pod, ve qué IP devolvió pagos.proveedorexterno.example y programa dinámicamente la regla para esa IP, con el tiempo de vida que indique el registro DNS. Si mañana el proveedor cambia de IP, la política sigue funcionando sin que nadie toque nada.

Es, con diferencia, la solución más elegante. Su coste es la dependencia del CNI: adoptar Cilium es una decisión de plataforma que va mucho más allá de esta política.

Un enfoque en dos tiempos:

1. Ahora: ipBlock con los rangos publicados por el proveedor, más un trabajo programado mensual que verifique que siguen siendo válidos y avise si cambian. Es la solución que funciona con cualquier CNI y no requiere nuevas piezas.
2. A medio plazo: proxy de salida con lista de permitidos, principalmente por el registro de destinos. Si en algún momento se migra a Cilium (cosa que también aportaría las ventajas del apartado 11), se sustituyen las políticas por toFQDNs.

Y la comprobación que hay que automatizar en cualquier caso:

Esta prueba debe ejecutarse en rutas-norte-pre en cada despliegue. Es la verificación de la capa que impide una fuga de datos personales, y como tal debería estar en el expediente que revisa el responsable de cumplimiento.

En 04-05 pusimos TLS en el Ingress con cert-manager: el tráfico entre el navegador del cliente y la plataforma va cifrado hasta https://www.rutasnorte.example. Perfecto. Pero ¿qué pasa después del Ingress?

Todo lo que hay a la derecha del Ingress viaja sin cifrar por la red del clúster. Y por ese tramo pasan, en claro:

• Las consultas SQL con nombres, DNI, teléfonos y correos de clientes.
• Las respuestas de la API con los datos de las reservas.
• Las credenciales de la base de datos, en el saludo inicial de cada conexión.

Esta es la pregunta que decide si merece la pena el esfuerzo:

Fíjate en cómo se conectan las lecciones: en 08-02 prohibimos hostNetwork y CAP_NET_RAW, y en 08-03 hicimos que el clúster lo rechace. Ese trabajo es lo que hace que el tráfico interno sin cifrar sea un riesgo aceptable en muchos escenarios. El cifrado interno es la defensa para cuando esa capa falla, o cuando la normativa lo exige explícitamente.

Es lo que ya hacemos con la pasarela de pagos (el embajador habla HTTPS). Para el tráfico interno significaría configurar PostgreSQL con ssl = on, generar certificados, distribuirlos y configurar cada cliente.

Ventaja: cifra el tramo que más importa (los datos personales) con poco despliegue. Inconveniente: hay que hacerlo componente a componente, gestionar la rotación de certificados y confiar en que cada cliente verifique realmente el certificado (muchos clientes de base de datos, por defecto, no lo hacen).

Para Rutas Norte, cifrar específicamente la conexión con postgres-reservas es una medida de alto valor y coste moderado, y probablemente el primer paso a dar.

Varios CNI pueden cifrar automáticamente todo el tráfico entre nodos con WireGuard o IPsec.

Ese último punto es la limitación esencial: el cifrado del CNI protege contra quien observe la red entre nodos, pero no aporta identidad por servicio. tienda-web y api-reservas en el mismo nodo se hablan igual de en claro, y ninguno puede demostrar criptográficamente quién es.

Aun así, la relación valor/esfuerzo es excelente. Si el CNI lo soporta, actívalo.

Es el siguiente apartado, porque da mucho más que cifrado.

Una malla de servicio (service mesh) es una capa de infraestructura que se ocupa de la comunicación entre servicios, sacándola del código de las aplicaciones.

En el modelo clásico, se inyecta un proxy sidecar (habitualmente Envoy) en cada pod. Todo el tráfico que entra y sale del pod pasa por ese proxy, que es quien aplica el cifrado, la autorización y la recogida de métricas. La aplicación no se entera: sigue haciendo http://api-reservas:8080.

La identidad por carga de trabajo es la joya de la corona y merece que la entendamos bien. Sin malla, cuando postgres-reservas recibe una conexión desde una IP, lo único que sabe es que viene de esa IP. Con la NetworkPolicy sabemos que esa IP corresponde a un pod con la etiqueta app: api-reservas... pero las etiquetas las pone quien crea el pod, y una IP se puede suplantar.

Con mTLS, postgres-reservas recibe un certificado que dice spiffe://cluster.local/ns/rutas-norte-pro/sa/api-reservas, firmado por la autoridad certificadora del clúster, que nadie más puede falsificar. Eso sí es identidad. Y encaja perfectamente con las ServiceAccounts de 03-06.

Esta es la parte que las presentaciones comerciales pasan por encima:

Ese último punto tiene un ejemplo directo en Rutas Norte: el CronJob informes-ocupacion termina su trabajo, pero el sidecar sigue corriendo y el Job nunca se marca como completado. Hay soluciones (contenedores sidecar nativos desde 1.29, o llamar al punto de terminación del proxy), pero es exactamente el tipo de fricción imprevista que aparece.

Vamos a responder con honestidad, porque es una decisión cara.

Argumentos a favor:

• Transporta datos personales entre servicios y el cifrado interno es exigible en un análisis de riesgo serio.
• La autorización L7 permitiría reglas como "solo tienda-web puede hacer POST /reservas", que NetworkPolicy no puede expresar.
• La identidad criptográfica elimina la suplantación de servicios.

Argumentos en contra:

• Son seis componentes. Una malla brilla con decenas o cientos de microservicios y comunicaciones complejas.
• El grafo de llamadas es casi lineal: tienda-web → api-reservas → postgres-reservas/redis-cache. No hay una topología que justifique una capa de encaminamiento.
• El equipo de plataforma es pequeño. Añadir una malla mal operada puede empeorar la seguridad (certificados caducados, políticas mal entendidas, actualizaciones aplazadas).
• Buena parte del beneficio se consigue más barato: cifrado del CNI para el tránsito, TLS en PostgreSQL para lo crítico, y NetworkPolicies estrictas para la segmentación.

Decisión para Rutas Norte: no, todavía no. El plan alternativo:

1. Activar el cifrado WireGuard del CNI (una opción de configuración).
2. Configurar TLS en postgres-reservas, que es donde están los datos personales.
3. Mantener las NetworkPolicies estrictas con control de salida.
4. Revisar la decisión cuando se cumpla alguno de estos criterios objetivos: más de quince servicios, comunicación entre varios equipos que no se coordinan, un requisito normativo explícito de mTLS, o la necesidad real de despliegues canary por porcentaje de tráfico.

Y una recomendación general que va más allá de este curso:

Una malla de servicio es una respuesta excelente a un problema que hay que tener primero. Adoptarla "porque es lo moderno", sin la complejidad que la justifica, añade riesgo operativo sin añadir seguridad neta. Si la operas mal, es peor que no tenerla.

Dicho esto, hay que conocerla, porque el día que la plataforma crezca será la respuesta correcta. Vamos con las opciones.

Istio en modo sidecar si necesitas el conjunto de funciones más completo: encaminamiento sofisticado, multiclúster complejo, integración con pasarelas de API, extensiones con WebAssembly. Es la opción con más capacidad y también la que más cuesta operar. Necesitas gente dedicada.

Istio en modo ambient es la evolución que ataca el principal reproche al modelo sidecar: el coste por pod. En lugar de un proxy en cada pod, hay un agente por nodo (ztunnel) que da mTLS y L4, y solo se despliega un proxy L7 (waypoint) donde de verdad hace falta autorización de nivel 7. Reduce muchísimo el consumo y elimina el problema de los Jobs que no terminan. Si hoy tuviéramos que elegir Istio, sería este modo.

Linkerd si quieres mTLS y observabilidad con la mínima complejidad. Su proxy en Rust es notablemente ligero y su filosofía es hacer pocas cosas y hacerlas bien. Para una plataforma como Rutas Norte, si algún día hiciera falta una malla, esta sería la primera candidata: cubre lo que necesitamos (mTLS, identidad, autorización básica) sin la superficie de Istio.

Cilium Service Mesh si ya usas Cilium como CNI. Al integrar la malla en el CNI evitas una capa completa: el mTLS y las políticas L4 se aplican en eBPF, dentro del kernel, sin proxy. Solo se despliega Envoy para las políticas L7. Es la opción más eficiente, y además trae las políticas por nombre de dominio del apartado 4 y la visibilidad de Hubble del apartado 11. La contrapartida es que ata la decisión de la malla a la del CNI.

Este es el hueco concreto que NetworkPolicy no puede llenar, y conviene verlo con un ejemplo real.

Nuestra política actual dice: tienda-web puede conectar con api-reservas en el puerto 8080. Eso es todo lo que puede expresar. En cuanto la conexión está abierta, tienda-web puede hacer:

Una política L7 sí puede distinguir. Veamos cómo se expresaría con Istio, tomando el ejemplo del enunciado: solo api-reservas puede hacer POST /reservas.

Con action: ALLOW, todo lo que no encaje con ninguna regla se deniega. Es el mismo principio de denegación por defecto de las NetworkPolicies, ahora aplicado a métodos y rutas HTTP.

Observa la línea clave:

Eso no es una etiqueta ni una IP: es la identidad SPIFFE que la malla verifica criptográficamente en el saludo mTLS. Un pod no puede reclamar esa identidad sin tener la clave privada correspondiente. Y fíjate en que se basa en la ServiceAccount, cerrando el círculo con 03-06 y 08-01: la ServiceAccount pasa de ser solo la identidad ante la API a ser también la identidad ante los demás servicios.

Las dos son complementarias, no alternativas. La NetworkPolicy es la primera línea y la más barata; la política L7 es la afinación. Si tuvieras que quedarte con una, quédate con la NetworkPolicy: sin ella, la política L7 protege un servicio al que cualquiera puede seguir conectándose por otras vías.

Sin malla, la autorización L7 la hace la propia aplicación. api-reservas puede validar en su código quién le llama:

Funciona y para seis servicios es perfectamente razonable, pero tiene inconvenientes reales: hay que implementarlo en cada servicio, rotar los tokens a mano, y si alguien lee el Secret (RBAC, 08-01) puede suplantar al servicio. El mTLS de la malla resuelve las tres cosas automáticamente. Es exactamente el tipo de coste que va creciendo con el número de servicios y que, llegado un punto, justifica la malla.

Todo lo anterior protege el interior. Ahora, la puerta de entrada.

En 04-02 vimos los tipos de Service. Repasemos su implicación de seguridad:

Por qué NodePort no vale en producción:

• Abre el puerto en todos los nodos, incluidos los que no ejecutan el pod.
• Se salta el Ingress, y con él el TLS (04-05), el WAF y la limitación de peticiones.
• El puerto está en un rango alto y poco convencional, difícil de proteger con un cortafuegos convencional.
• No tiene nombre: cualquiera que alcance la IP del nodo llega al servicio.

Y recuerda de 08-02 que hostPort es todavía peor, porque ni siquiera hay un Service delante.

La regla de Rutas Norte: un único punto de entrada, el balanceador del Ingress. Todo lo demás es ClusterIP.

Un único LoadBalancer, el del Ingress. Cualquier otra línea en esa salida es una pregunta que hay que responder.

Un cortafuegos de aplicación web (WAF) inspecciona las peticiones HTTP y bloquea patrones de ataque conocidos: inyección SQL, ejecución de scripts entre sitios, recorrido de directorios. Con ingress-nginx se puede activar ModSecurity con el conjunto de reglas OWASP:

Advertencia seria sobre los WAF: un WAF mal ajustado bloquea peticiones legítimas. Si tienda-web deja de poder crear reservas porque una regla del WAF considera sospechoso un nombre con apóstrofe, has creado una incidencia. El procedimiento correcto es idéntico al del PSA en 08-03:

1. SecRuleEngine DetectionOnly: registra pero no bloquea.
2. Analizar los falsos positivos durante semanas de tráfico real.
3. Ajustar las reglas problemáticas.
4. Solo entonces, SecRuleEngine On.

Y la limitación de peticiones, por anotación en el Ingress:

Las cabeceras, una a una:

Un detalle sobre HSTS: max-age=31536000 son 365 días, y los navegadores lo recuerdan. Si algún día tu TLS deja de funcionar, los clientes que ya visitaron el sitio no podrán entrar por HTTP como alternativa. Es lo deseable desde el punto de vista de seguridad, pero hay que ser consciente antes de activarlo.

Un punto importante que se olvida: el autoescalado no es una defensa contra la denegación de servicio, es una forma de pagarla. Si api-reservas escala a 50 réplicas ante un ataque, has convertido una caída en una factura. El límite superior del HPA (09-01) es también un control de seguridad y de coste.

Todo lo anterior protege las cargas. El plano de control es el objetivo de mayor valor: quien lo controla, controla todo el clúster.

Una IP privada es buena señal. Si vieras una IP pública sin restricción de origen, es un hallazgo de seguridad de primer nivel.

En Kubernetes gestionado (10-06), los tres grandes proveedores permiten restringir el acceso al punto final. Es de las primeras cosas que hay que configurar en un clúster nuevo.

etcd guarda todo el estado del clúster, incluidos los Secrets. Como dijimos en 03-02, si etcd no está cifrado, los Secrets están en claro en el disco.

Cifrado en reposo:

Detalle importante: el orden de los proveedores importa. El primero se usa para escribir; todos se usan para leer. Tener identity: {} al final permite leer los objetos que se escribieron antes de activar el cifrado. Y tras activarlo, hay que reescribirlos:

Sin ese paso, los Secrets antiguos siguen en claro en etcd para siempre.

Otros controles de etcd:

Ese punto de las copias es fácil de pasar por alto y muy grave. En 05-06 hablamos de Velero y de los datos personales; una copia de etcd contiene, además, todas las credenciales del clúster. Debe cifrarse, almacenarse con acceso restringido y registrado, y probarse su restauración periódicamente.

Cada nodo ejecuta un kubelet con una API en el puerto 10250. Sin protección, permite listar pods, leer logs y ejecutar comandos en cualquier contenedor de ese nodo.

Comprobación:

Y una NetworkPolicy o regla de cortafuegos que impida a los pods alcanzar el puerto 10250 de los nodos es una defensa muy rentable, porque cierra una vía de escalada conocida.

Recuerda de 08-01 que el permiso get nodes/proxy es de nivel crítico precisamente por esto: permite hablar con el kubelet y, a través de él, ejecutar en cualquier pod del nodo.

Los nodos del plano de control no deben ejecutar cargas de aplicación. Kubernetes lo consigue con un taint (06-05):

Ese taint impide que se planifiquen pods normales ahí. La razón es directa: un pod en un nodo del plano de control está a un fallo de distancia de los certificados del clúster y de la base de datos de etcd.

Y hay que verificar que nadie lo ha tolerado por comodidad:

Solo componentes del sistema que legítimamente corren en todos los nodos. Si apareciera aquí un pod de rutas-norte-pro, hay que investigar por qué se puso esa tolerancia. Ojo con la tolerancia universal (operator: Exists sin key): tolera todos los taints, incluido el del plano de control, y a menudo se pone sin darse cuenta.

Volvemos al segundo límite que señalamos en 04-06: las NetworkPolicies no registran nada.

Cuando una NetworkPolicy deniega una conexión, el paquete se descarta en el kernel. No hay evento de Kubernetes, no hay log, no hay métrica. Desde el pod origen, la conexión simplemente agota su tiempo de espera.

Las consecuencias son dos, y las dos son malas:

Para operar: depurar "por qué mi servicio no conecta" es doloroso. Puede ser DNS, una política, un Service mal configurado o la aplicación. Nada te dice cuál.

Para la seguridad: si alguien compromete un pod y empieza a sondear la red interna, generará decenas de conexiones denegadas y no se enterará nadie. Justo la señal más clara de un movimiento lateral es invisible.

Hubble, el componente de observabilidad de Cilium, resuelve esto aprovechando que Cilium ya inspecciona cada paquete en eBPF.

Ver flujos en tiempo real:

Y lo que de verdad importa, las denegaciones:

Léelo con atención, porque esa salida cuenta una historia completa. tienda-web —el componente más expuesto— ha intentado, en cinco segundos: conectar con la base de datos de clientes, conectar con la caché, salir a internet por HTTPS y salir a internet por SSH. tienda-web no hace nada de eso en su funcionamiento normal. Es exactamente el patrón de alguien explorando qué puede alcanzar desde un pod comprometido.

Las políticas hicieron su trabajo: todo DROPPED. Pero sin Hubble, esto habría pasado completamente desapercibido.

Hubble expone métricas Prometheus, así que se integra directamente con el módulo 7:

Esa segunda alerta es de las más valiosas de toda la plataforma: avisa de una posible exfiltración de datos personales en curso. La ruta a Alertmanager y su encaminamiento son las del módulo 7; lo único nuevo es la fuente de la métrica.

Para Rutas Norte, sin Cilium hoy, la combinación práctica es: registro del proxy de salida para el tráfico externo (que es el crítico) y Falco para las conexiones anómalas, que veremos en la lección siguiente.

La confianza cero (zero trust) es un modelo que se resume en una frase: nunca confíes, verifica siempre. Nada se considera de confianza por su ubicación en la red.

La idea de asumir el compromiso es la que más cambia el diseño. No se trata de "cómo evito que entren", sino de "cuando entren, ¿qué pueden hacer y en cuánto tiempo me entero?".

Las tres prioridades que salen de esta tabla, por orden: control de salida, visibilidad del tráfico y revisión del plano de control. Todas atacan el mismo escenario: alguien ya está dentro.

Escribir solo políticas de Ingress. Si policyTypes no incluye Egress, la salida está abierta y con ella la vía de exfiltración. Es el error más grave y más frecuente de esta lección.

Activar Egress y olvidar el DNS. Todo deja de funcionar de una forma muy confusa: los nombres no resuelven y parece un problema de Service. La regla hacia kube-dns en el puerto 53, UDP y TCP, es la primera que hay que escribir.

Usar ipBlock: 0.0.0.0/0 sin except. Incluye la red interna del clúster, así que la política es mucho más permisiva de lo que parece.

Confiar en que los ipBlock de un proveedor externo no cambian. Cambian. Programa una verificación mensual o usa un proxy con lista de dominios.

Creer que el contenedor embajador aísla la red. Comparte el namespace de red con el resto del pod. Es un patrón de arquitectura, no un límite de seguridad.

Escribir políticas por namespace en lugar de por componente. Reproduce la red plana dentro del namespace. El coste de hacerlo bien son cinco políticas más.

Dejar rutas-norte-dev y rutas-norte-pre sin políticas. La red del clúster es plana entre namespaces, y una política que solo se prueba en producción se prueba en el peor momento.

Adoptar una malla de servicio sin necesitarla. Es infraestructura crítica: mal operada, empeora la seguridad. Define criterios objetivos para revisar la decisión.

Activar un WAF directamente en modo bloqueo. Bloqueará peticiones legítimas y tendrás una incidencia. DetectionOnly primero, semanas de análisis, y luego bloqueo.

Usar NodePort en producción "porque es más rápido de configurar". Se salta el TLS, el WAF y la limitación de peticiones, y abre el puerto en todos los nodos.

Olvidar que el autoescalado no defiende de la denegación de servicio. Convierte una caída en una factura. Pon un límite superior al HPA.

Cifrar etcd y no reescribir los Secrets existentes. Los antiguos siguen en claro. kubectl get secrets -A -o json | kubectl replace -f -.

No cifrar las copias de seguridad de etcd. Una copia de etcd contiene todos los Secrets del clúster.

Tolerancias universales. Un operator: Exists sin key tolera todos los taints, incluido el del plano de control, y suele ponerse sin darse cuenta.

Consejo de oro: dibuja el diagrama de qué habla con qué y comprueba que las políticas lo reproducen exactamente, ni una flecha más. Después, haz la pregunta clave: si compromenten este pod, ¿a dónde puede llegar y por dónde pueden sacar los datos? Si la respuesta a la segunda parte no es "a ningún sitio", hay trabajo pendiente en el egreso.

Cuatro de los seis componentes de Rutas Norte no necesitan salir a internet: tienda-web, postgres-reservas, redis-cache e informes-ocupacion. Escribe una única NetworkPolicy que les permita solo lo imprescindible dentro del clúster y les cierre por completo la salida a internet.

Ten en cuenta que:

• Todos necesitan DNS.
• postgres-reservas e informes-ocupacion deben poder hablar entre sí (el CronJob consulta la base de datos).
• tienda-web debe poder llegar a api-reservas.
• Todos deben poder ser consultados por Prometheus.

Incluye la orden que verificaría que la salida está efectivamente cerrada.

La dirección de Rutas Norte plantea desplegar Istio "porque es lo que usan las empresas grandes". Prepara una respuesta técnica de una página que incluya:

1. Qué problemas concretos resolvería en la plataforma actual.
2. Qué costaría, de forma cuantificada.
3. Qué alternativas más baratas cubren parte del beneficio.
4. Criterios objetivos y medibles para revisar la decisión.
5. Una recomendación clara.

A las 03:47 salta la alerta ConexionesDenegadasAnomalas. Consultas Hubble y obtienes:

1. ¿Qué está ocurriendo? Justifica tu lectura línea por línea.
2. ¿Qué capas de defensa han funcionado y cuáles no?
3. Enumera las acciones inmediatas, en orden de prioridad.
4. ¿Qué habría pasado sin control de salida? ¿Y sin Hubble?

Solución 1

Y la política de entrada para que Prometheus pueda raspar métricas (es Ingress, complementaria):

Una observación importante sobre la primera política: al usar un podSelector con matchExpressions que agrupa cuatro componentes, todos comparten las mismas reglas de salida. Eso significa que redis-cache técnicamente podría conectar con api-reservas:8080, aunque no lo haga.

Es un compromiso consciente entre concisión y precisión. La versión estrictamente correcta sería una política por componente, y es lo que recomendaríamos en producción siguiendo el principio 2 del apartado 2. Esta versión agrupada es aceptable porque el objetivo declarado del ejercicio —cerrar la salida a internet— se cumple igualmente, y ninguno de los permisos internos concedidos de más da acceso a datos personales. Documentar ese razonamiento es tan importante como el YAML.

Verificación:

Comprobar el DNS es tan importante como comprobar el bloqueo: una política de salida que bloquea internet y el DNS rompe la plataforma sin que sea evidente por qué.

Solución 2

Informe técnico: adopción de una malla de servicio en la plataforma Rutas Norte

1. Qué problemas resolvería

De seis problemas, uno es urgente (cifrado) y cinco son mejoras deseables sin urgencia.

2. Coste cuantificado

Con Istio en modo ambient o con Linkerd, la memoria y la latencia bajarían sustancialmente. La complejidad operativa y el riesgo de los primeros meses no.

3. Alternativas más baratas

Las dos primeras juntas cubren el 80 % del beneficio de seguridad por menos del 5 % del coste.

4. Criterios objetivos para revisar la decisión

Se reabrirá la evaluación cuando se cumpla cualquiera de estos:

• La plataforma supere los 15 servicios con comunicación entre ellos.
• Más de tres equipos desplieguen en el clúster sin coordinación diaria.
• Aparezca un requisito normativo o contractual explícito de mTLS entre servicios (por ejemplo, una certificación de un cliente corporativo).
• Se necesiten despliegues canary por porcentaje de tráfico que no se puedan aproximar con réplicas.
• Se necesite encaminamiento entre varios clústeres (11-05).
• El equipo de plataforma alcance 5 personas o más, con capacidad para dedicar una a la malla.

5. Recomendación

No adoptar una malla de servicio ahora. En su lugar, en este orden:

1. Activar WireGuard en el CNI (esta semana).
2. Configurar TLS en postgres-reservas (este trimestre).
3. Implantar visibilidad de flujos (este trimestre).
4. Revisar la decisión cada seis meses contra los criterios anteriores.

Si en el futuro se adopta, la primera candidata sería Linkerd por su relación entre beneficio y complejidad, o Istio en modo ambient si para entonces se necesita encaminamiento avanzado.

Nota final: esta recomendación es una valoración de arquitectura basada en el tamaño y la topología actuales. Debe validarla el profesional de seguridad de la organización, especialmente en lo relativo al cifrado del tráfico con datos personales, donde el responsable de cumplimiento normativo tiene la última palabra sobre qué nivel de protección es exigible.

Solución 3

1. Qué está ocurriendo, línea por línea

La secuencia completa —cuatro segundos, tres puertos distintos hacia la misma IP externa, sondeo de servicios internos, y vuelta a la base de datos— no corresponde a ningún comportamiento legítimo de worker-notificaciones. La firma es la de un proceso comprometido buscando por dónde sacar información, y la última línea sugiere que sigue accediendo a datos.

Un detalle temporal importante: son las 03:47. El CronJob informes-ocupacion corre a las 03:00. Habrá que descartar que haya relación.

2. Capas que funcionaron y que no

3. Acciones inmediatas, por prioridad

Las órdenes de los dos primeros pasos:

Al quitar la etiqueta app, el ReplicaSet detecta que le falta una réplica y crea un pod nuevo y limpio: el servicio se recupera solo mientras el pod comprometido queda aislado para el análisis. Es una técnica que conviene tener ensayada antes de necesitarla.

4. Los escenarios contrafactuales

Sin control de salida: las tres conexiones a 192.0.2.55 habrían sido FORWARDED. El proceso tenía acceso legítimo a postgres-reservas, es decir, a la tabla de clientes con nombres, DNI, teléfonos y correos. Esto habría sido una fuga de datos personales consumada, con obligación de notificación a la autoridad de control y a los afectados. La política de egreso —esas líneas de YAML que casi nadie escribe— es lo único que separó un incidente contenido de una brecha de datos.

Sin Hubble: no habría alerta. Las conexiones denegadas son silenciosas: sin registro de flujos, el pod comprometido habría seguido consultando la base de datos indefinidamente, y probablemente habría encontrado antes o después una vía de salida (una configuración cambiada, un permiso nuevo, una política mal revisada). El incidente se habría descubierto semanas o meses después, o nunca.

Este ejercicio resume la lección entera: la prevención falló —siempre acaba fallando en algún punto—, la contención funcionó, y la detección permitió reaccionar. Las tres son necesarias, y la que más se descuida es la tercera.

Hemos construido la estrategia de red completa de Rutas Norte, por capas:

• La microsegmentación parte de denegar por defecto en los tres entornos, con políticas por componente y no por namespace, y con revisión periódica de qué conversaciones siguen siendo necesarias.
• El control del tráfico saliente es la capa que decide si un compromiso se convierte en una fuga de datos. Cuatro de los seis componentes de Rutas Norte no necesitan salir a internet en absoluto, y cerrarles la salida es la medida de mayor valor por menor coste de toda la lección.
• Las NetworkPolicies trabajan con IP, no con nombres de dominio. Las salidas son la pasarela de salida, el proxy con lista de dominios permitidos (que además registra los destinos) o las políticas toFQDNs de Cilium.
• Dentro del clúster, tras el TLS del Ingress, todo viaja en claro. Las opciones son TLS en la aplicación (prioritario para postgres-reservas), cifrado a nivel de CNI con WireGuard (barato y efectivo entre nodos) o mTLS con una malla de servicio.
• Una malla de servicio da identidad criptográfica por carga, mTLS automático y autorización L7, a cambio de complejidad operativa, recursos y latencia. Rutas Norte no la necesita hoy, y hemos fijado criterios objetivos para revisar esa decisión. Istio (sidecar o ambient), Linkerd y Cilium Service Mesh cubren perfiles distintos.
• En el perímetro: un único punto de entrada (nada de NodePort), WAF adoptado gradualmente, limitación de peticiones y cabeceras de seguridad.
• El plano de control merece revisión propia: apiserver no expuesto, etcd cifrado y con los Secrets reescritos, copias de seguridad cifradas, kubelet autenticado sin puerto de solo lectura, y nodos de control aislados con taints.
• Lo que le falta a NetworkPolicy es registro. Hubble, o el registro de un proxy de salida, convierte el sondeo interno y los intentos de exfiltración en algo visible y alertable.
• La confianza cero se resume en asumir el compromiso: no "cómo evito que entren", sino "cuando entren, qué pueden hacer y en cuánto me entero".

Con esto, la red de Rutas Norte está segmentada, con la salida controlada y con visibilidad de lo que ocurre. Pero fíjate en algo: todo lo que hemos hecho en este módulo protege el clúster en tiempo de ejecución. Damos por sentado que las imágenes que ejecutamos son las que creemos.

Y esa suposición es frágil. registry.rutasnorte.example/api-reservas:2.7.1 es una etiqueta, y una etiqueta se puede reasignar: la imagen que se descargó ayer puede no ser la de hoy. La imagen base sobre la que se construyó puede contener software que nadie ha revisado. Las dependencias que se instalaron durante la construcción vienen de repositorios públicos. Y nada, absolutamente nada, impide hoy que alguien con acceso al registro suba una imagen modificada con el mismo nombre y que el clúster la ejecute sin rechistar, con todos nuestros securityContext perfectamente aplicados a un contenedor que hace algo distinto de lo que creemos.

La siguiente lección, 08-05, Seguridad de Imágenes, recorre la cadena de suministro completa: dónde se puede envenenar una imagen, cómo construir imágenes mínimas, por qué el digest es la única referencia realmente reproducible, cómo firmar con Cosign y —lo más importante— cómo hacer que el clúster rechace cualquier imagen que no esté firmada, con la política de admisión que lo garantiza.