Escribir una NetworkPolicy es fácil; comprobar que hace lo que crees, no tanto
Red Hat detalla los fallos más repetidos al aplicar políticas de red en OpenShift, desde la ausencia de default-deny hasta el puerto 5353 de OVN-Kubernetes.
Un NetworkPolicy que se aplica sin errores no garantiza que el tráfico esté donde crees. Red Hat ha publicado la tercera entrega de su serie sobre zero trust en OpenShift y el tema es justo ese: la distancia entre la intención de una política de red y lo que ocurre de verdad dentro del clúster. El texto repasa los fallos de configuración que se repiten incluso entre arquitectos con años de Kubernetes a la espalda, y varios son específicos de OVN-Kubernetes.
El default-deny que falta y el egress que nadie escribe
Dos NetworkPolicy por pod, una para la aplicación y otra para la base de datos, y la sensación de haber cerrado el paso. Sin una política default-deny de base, cualquier pod que no encaje en ninguna regla existente se mueve sin restricciones: resuelve todos los servicios por DNS, cruza namespaces y sale a internet. Las políticas por pod son puertas cerradas en mitad de un campo abierto. En el Layered Zero Trust Validated Pattern lo comprobaron desplegando un pod intruso en el namespace qtodo: llegó a Vault, al central de Advanced Cluster Security y a la red pública, con la base de datos como única pieza a salvo.
La salida de tráfico es la que casi nadie mira. Sin reglas de egress, un pod comprometido enumera recursos contra el API server, alcanza servidores de mando y control y exfiltra lo que encuentre. En el patrón citado el DNS se limita a CoreDNS, el acceso al API server solo lo tienen los pods que realmente lo necesitan y la salida a internet está denegada salvo justificación explícita.
Trampas de plataforma
Con OVN-Kubernetes el DNS escucha en el puerto 5353, no en el 53: una regla que permite egress al 53 no sirve para nada. Los endpoints del API server son IPs de nodo después del DNAT, así que no se pueden seleccionar por namespace y toca una regla de solo puerto 6443. El router de OpenShift cambia de comportamiento según el endpointPublishingStrategy (HostNetwork, NodePortService o LoadBalancerService); con HostNetwork la IP de origen es la del nodo y hay que usar la etiqueta policy-group.network.openshift.io/ingress. Y cualquier pod con hostNetwork: true queda fuera del alcance de las NetworkPolicy, como los agentes de SPIRE: eso se documenta como excepción conocida, no se ignora.
Falta la prueba que decide de verdad. Aplicar la política en un clúster en marcha, verificar todos los flujos, reiniciar los pods críticos —SPIRE vuelve a atestiguar, Keycloak reconecta con PostgreSQL, Vault se reincorpora—, revisar los logs por si hay errores de conexión y limpiar. Solo cuando ese ensayo pasa, el cambio llega a Git. La trampa final está en las plantillas: Helm puede entregar un booleano como cadena, y una condición del tipo {{- if .Values.networkPolicy.enabled }} no renderiza la política, no da error y te deja creyendo que hay aislamiento. La forma correcta:
{{- if eq (.Values.networkPolicy.enabled | toString) "true" }}
El patrón sigue los principios de NIST SP 800-207, donde la política de red es la última línea de defensa cuando no hay tiempo para parchear. Lo incómodo no es escribirla, sino el fallo silencioso: pipeline en verde, plantilla sin errores y ningún aislamiento real.
