Acerca de las políticas de red de varias redes


En esta página, se explica cómo controlar el flujo de tráfico de red entre Pods y Services mediante reglas de firewall a nivel de Pod.

Las políticas de red para aplicaciones te ayudan a definir reglas de tráfico de comunicación entre Pods. Controla cómo los Pods se comunican entre sí dentro de sus aplicaciones y con extremos externos. Puedes habilitar la política de red en las redes de Pods en clústeres de Google Kubernetes Engine (GKE) edición Enterprise que tienen habilitadas varias redes. Puedes aplicar políticas de red en interfaces de Pod adicionales que corresponden a las redes de Pods especificadas por el usuario.

Por qué usar políticas de red de varias redes

Es posible que quieras usar políticas de red de varias redes en las siguientes situaciones:

  • Seguridad de red mejorada: deseas aislar y proteger cargas de trabajo o datos sensibles mediante la definición de políticas de red para redes de Pods específicas. Las políticas de red de varias redes limitan la exposición y reducen la superficie de ataque.

  • Control de tráfico detallado: quieres lograr un control preciso sobre el flujo de tráfico entre Pods y Services en diferentes redes de Pods, lo que permite topologías de red complejas y requisitos de seguridad.

  • Entornos de multiusuario: deseas crear redes aisladas para diferentes usuarios o aplicaciones y asegurarte de que no puedan interferir en la comunicación de cada una, a la vez que mantienes el control sobre el acceso a la red dentro de cada red de Pods.

  • Optimiza el uso de recursos: Debes implementar políticas de red en redes de Pods específicas para asignar recursos de manera eficiente y priorizar el tráfico según los requisitos de la aplicación, lo que mejora el rendimiento y la confiabilidad.

  • Seguridad para las funciones de red en contenedores (CNF): Debes segregar el tráfico de administración del tráfico del plano de datos dentro del mismo Pod, lo que evita posibles violaciones de la seguridad y acceso no autorizado.

Cómo funcionan las políticas de red de varias redes con redes de Pods

En el siguiente diagrama, se ilustra cómo las políticas de red, que se aplican a las redes de Pods específicas mediante anotaciones, controlan el flujo de tráfico entre Pods dentro de un clúster de GKE.

funcionamiento de políticas de red de varias redes

En el diagrama anterior, se muestran varios nodos trabajadores que ejecutan Pods (aplicaciones en contenedores) y cómo se comunican dentro del mismo nodo o entre diferentes nodos mediante la infraestructura de red. También se ilustra el uso de políticas de red para controlar el flujo de tráfico y la segmentación de la red mediante VPC y subredes a fin de mejorar la seguridad y la organización.

  1. Aísla el tráfico con políticas de red orientadas: Las políticas de red solo afectan el tráfico en la red de Pods “azul” debido a la anotación networking.gke.io/network: blue-Pod-network. El tráfico en la red de Pods predeterminada permanece sin restricción.
  2. Aplica el tráfico unidireccional con políticas de red de Pods: En el diagrama anterior, las políticas de red permiten que el Pod1 envíe tráfico al Pod2 en la red de Pods “azul”. El Pod2 no puede enviar tráfico de vuelta al Pod1 en la misma red. La política de red para Pods etiquetados como “test-app-2” funciona como un canal unidireccional. Permite específicamente el tráfico saliente solo hacia los Pods etiquetados como “test-app-3”, lo que evita la comunicación con otros Pods como “test-app-1”.
  3. Permite el tráfico saliente de forma predeterminada: Si no se define ninguna política de salida para un Pod (Pod1 en este ejemplo), todo el tráfico saliente se permite de forma predeterminada en la interfaz de red “azul”.
  4. Garantiza la compatibilidad de las funciones existentes: Todas las opciones de políticas de red de GKE estándar, como los selectores de etiquetas y los bloques de direcciones IP, funcionan con políticas de red de varias redes.
  5. Controla el alcance de la política de red con anotaciones:
    1. Si creas una política de red sin anotación, GKE aplica políticas de red de varias redes a todas las interfaces de red en los Pods del espacio de nombres seleccionado, sin importar las redes de Pods a las que estén conectados.
    2. Si incluyes la anotación y especificas el nombre de una red de Pods válida (por ejemplo, networking.gke.io/network: blue-Pod-network), GKE aplica la política a los Pods conectados a esa red de Pods específica.
    3. Si la anotación hace referencia a la red de Pods que no existe en tu clúster, GKE no aplica la política de red a ningún Pod. Esto se debe a que no hay Pods conectados a la red inexistente especificada.
  6. Mantén la comunicación entre redes para Pods con interfaces de red múltiples: Si aplicas una política de red para restringir el tráfico en una red de Pods específica dentro de un Pod, no afectará el tráfico en otras redes de Pods conectadas al mismo Pod.

Ventajas

Los siguientes son los beneficios de usar políticas de red de varias redes:

  • Seguridad mejorada: Puedes mitigar los riesgos asociados con el acceso no autorizado y el movimiento lateral dentro del clúster de GKE si aplicas políticas de red a un nivel detallado.

  • Flexibilidad y personalización: puedes adaptar las políticas de red a fin de satisfacer tus necesidades específicas de seguridad y administración del tráfico para diferentes redes de Pods mediante la adaptación de distintas cargas de trabajo y aplicaciones.

  • Administración de redes simplificada: Puedes evitar la creación excesiva de redes de Pods y tener un control detallado sobre la comunicación si usas políticas de red, lo que simplifica la administración de redes y reduce la complejidad.

  • Optimización de costos: si evitas la necesidad de crear varias redes de Pods, puedes optimizar el uso de recursos y reducir los costos asociados con la infraestructura de red.

  • Protección mejorada para CNF: Puedes garantizar la seguridad y la integridad de las implementaciones de CNF si aíslas la administración y el tráfico del plano de datos, y aplicas políticas de red específicas a cada implementación.

¿Qué sigue?

Controla el flujo de tráfico entre Pods y Services a nivel de Pod