Resumen

  • Kubernetes describe NetworkPolicy como comportamiento deseado para Pods seleccionados. Sus reglas de ingreso y salida son aditivas, y una conexión entre Pods necesita permiso tanto de salida en origen como de ingreso en destino.
  • La documentación también limita la inferencia: sin un controlador de red que la implemente, el objeto no tiene efecto; el tratamiento es eventual, la API no muestra cuándo ocurrió, y el efecto sobre conexiones existentes queda definido por la implementación.
  • Para afirmar algo sobre un flujo se necesitan registros distintos de la revisión de política, el estado de selectores y extremos, la implementación de red, la observación temporal de la conexión y cualquier decisión aparte de identidad o aplicación.

La frase «denegar por defecto» puede hacer que un manifiesto YAML parezca un resultado de seguridad ya consumado. No lo es. El valor de NetworkPolicy es declarativo: permite aislar Pods seleccionados para ingreso, salida o ambos, y describir las conexiones que deben seguir permitidas. Es una decisión sobre una frontera deseada. No es prueba de que una conexión concreta fue denegada, de que una conexión permitida llegó a establecerse o de que una carga quedó segura.

El modelo del recurso marca el primer límite. NetworkPolicySpec representa el comportamiento deseado. Una política selecciona Pods, declara aislamiento Ingress o Egress y contiene reglas. Los efectos no son sobrescrituras ordenadas; se suman. Cuando un Pod está aislado en una dirección, las conexiones permitidas son la unión de las reglas de todas las políticas que le aplican. Para que un Pod origen alcance un Pod destino, la salida del origen y el ingreso del destino deben permitir la conexión. Esa regla explica un conjunto de políticas; no entrega la dirección observada, el puerto, el protocolo, la hora, el proceso, el camino del paquete ni el resultado de una conexión.

El estado de los selectores es otro hecho. Un podSelector, namespaceSelector o ipBlock no es una lista permanente de extremos concretos. Las etiquetas cambian, los Pods se reemplazan y el enrutamiento de Service puede alterar el camino. Kubernetes advierte además que mecanismos de ingreso o salida pueden reescribir direcciones. Cuando eso ocurre, no está definido si la reescritura sucede antes o después del procesamiento de NetworkPolicy; el comportamiento puede variar entre plugin, proveedor cloud, implementación de Service o combinación. Un manifiesto puede describir el alcance esperado sin resolver cómo se representó un paquete concreto en el punto de aplicación.

La capa de implementación es una evidencia diferente. Kubernetes indica que el plugin de red implementa NetworkPolicy. Si se crea un recurso sin un controlador que la implemente, no produce efecto, aunque la API siga presente. No es una acusación contra un producto ni un administrador. Significa que un objeto aceptado por el servidor API sólo prueba esa aceptación: no prueba la capacidad, configuración, salud ni actividad del componente de plano de datos.

El tiempo estrecha todavía más la conclusión. Kubernetes dice que una política creada será manejada finalmente, pero la API no informa el instante exacto. También describe vistas levemente inconsistentes mientras cambian Pods o políticas. Si una modificación afecta una conexión existente, el resultado depende de la implementación. No son excepciones retóricas: son razones para no exigir a una instantánea de configuración que narre una ejecución que no conserva.

La cobertura de protocolo también importa. NetworkPolicy se define para conexiones TCP, UDP y, opcionalmente, SCTP de capa 4. Para otros protocolos el comportamiento puede variar entre plugins. Una frontera aparente no debe convertirse en una afirmación universal sobre cada paquete, ruta hostNetwork, malla, cifrado, identidad, autenticación, DNS, autorización de aplicación o entrega. Cada una de esas superficies requiere evidencia propia.

Daniel Kade propone un recibo de flujo de cinco partes. Primero, la revisión de política: espacio de nombres, identidad del objeto, generación o captura inmutable, selector, dirección, reglas y hora de observación. Segundo, el estado de selectores y extremos: etiquetas de Pod y Namespace, mapeo de IP o endpoint y momento exacto de lectura. Tercero, la implementación de red: capacidad declarada, versión, configuración relevante y evidencia de salud. Cuarto, una observación de conexión limitada en el tiempo con origen y destino tal como fueron vistos, protocolo, puerto, dirección, resultado, colector y límites de cobertura.

Quinto, un registro independiente de identidad de carga, autorización, TLS, DNS, respuesta de aplicación o despliegue. Los detalles sensibles pueden protegerse sin fusionar los registros.

El método permite contar resultados normales sin inventar una historia. Una política correcta puede coexistir con una falla ajena que impida una conexión. Un flujo permitido en ambas direcciones puede fracasar en DNS, TLS, autenticación o aplicación. Una política puede ser aceptada por la API antes de que un plugin concreto la haga efectiva. Nada de ello demuestra una falla o un incidente. Demuestra por qué un manifiesto no debe cargar por sí solo la historia de un flujo.

Fuentes

  1. Kubernetes — Network Policies
  2. Kubernetes — Services, Load Balancing, and Networking
  3. Referencia API de Kubernetes — NetworkPolicy v1