Por qué la mayoría de clusters de Kubernetes siguen con la red plana

Por defecto, en un cluster de Kubernetes cualquier pod puede hablar con cualquier otro pod. No hay excepciones ni fricción, y no hace falta configurar nada. Es maravilloso para desarrollar rápido, y es exactamente el motivo por el que, cuando algo se compromete, no se queda contenido: se mueve.

Llevo bastante tiempo viendo el mismo patrón en clusters de producción. Hay NetworkPolicies en dos o tres namespaces “importantes”, y el resto sigue con red plana porque “ya lo haremos cuando toque”. Nunca toca.

Lo que suelo recomendar no es microsegmentar todo de golpe. Eso es inviable y genera tanto rechazo que se abandona a la primera incidencia. Es mejor un enfoque incremental:

Paso 1: default deny por namespace, empezando por los nuevos. Cualquier namespace que se cree a partir de ahora nace con una NetworkPolicy de deny-all como base. Es mucho más fácil imponer esto desde el primer día que añadirlo después.

Paso 2: egress antes que ingress. Casi todo el esfuerzo de seguridad se pone en controlar quién entra a un pod. Pero si un pod se compromete, lo que de verdad limita el daño es a dónde puede salir: otros namespaces, Internet o el metadata service del proveedor cloud. Controlar el egress suele dar más seguridad con el mismo esfuerzo.

Paso 3: los namespaces con datos sensibles primero. Si tienes que priorizar, empieza por donde viven la base de datos o el servicio de pagos, no por el namespace de un dashboard interno.

Paso 4: verificar, no asumir. Una NetworkPolicy mal escrita da una falsa sensación de seguridad. Antes de darla por buena, intenta la conexión que debería estar bloqueada y confirma que efectivamente falla.

Ninguna herramienta de escaneo te va a avisar de que tu cluster tiene la red plana con la urgencia con la que debería sonar esa alarma. Es una decisión que hay que tomar activamente.

¿Tenéis NetworkPolicies desplegadas en todos los namespaces de producción, o solo en los que “más preocupan”?

El capítulo completo de Network Policies, con manifiestos de default deny y control de egress listos para adaptar, está incluido en la muestra gratuita de mi manual “Seguridad y monitorización en Kubernetes”. [Descarga la muestra gratuita] en https://djimn.com  · Consigue el manual completo (950 páginas)