Acerca de las políticas de red multirred


En esta página se explica cómo controlar el flujo de tráfico de red entre pods y servicios 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 se comunican los pods entre sí en sus aplicaciones y con los endpoints externos. Puedes habilitar la política de red en redes de pods de clústeres de la edición Enterprise de Google Kubernetes Engine (GKE) que tengan habilitada la función de varias redes. Puedes aplicar políticas de red en interfaces de Pod adicionales que correspondan a redes de Pod especificadas por el usuario.

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

Puede que quieras usar políticas de red de varias redes en los siguientes casos:

  • Seguridad de red mejorada: quieres aislar y proteger cargas de trabajo o datos sensibles definiendo 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 del tráfico detallado: quieres controlar con precisión el flujo de tráfico entre pods y servicios en diferentes redes de pods, lo que permite topologías de red complejas y requisitos de seguridad.

  • Entornos multiinquilino: quieres crear redes aisladas para diferentes inquilinos o aplicaciones, de forma que no puedan interferir en la comunicación de los demás, pero manteniendo el control sobre el acceso a la red en cada red de pods.

  • Optimizar el uso de recursos: quieres implementar políticas de red en redes de pods específicas para asignar recursos de forma eficiente y priorizar el tráfico en función de los requisitos de las aplicaciones, lo que mejorará el rendimiento y la fiabilidad.

  • Seguridad para funciones de red en contenedores (CNFs): quieres separar el tráfico de gestión del tráfico del plano de datos en el mismo pod para evitar posibles brechas de seguridad y accesos no autorizados.

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

En el siguiente diagrama se muestra cómo las políticas de red, aplicadas a redes de pods específicas mediante anotaciones, controlan el flujo de tráfico entre los pods de un clúster de GKE.

funcionamiento de las políticas de red de varias redes

En el diagrama anterior se muestran varios nodos de trabajo 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 muestra el uso de políticas de red para controlar el flujo de tráfico y la segmentación de la red mediante VPCs y subredes para mejorar la seguridad y la organización.

  1. Aísla el tráfico con políticas de red específicas: las políticas de red solo afectan al tráfico de la red de pods "blue" debido a la anotación networking.gke.io/network: blue-Pod-network. El tráfico de la red de pods predeterminada no tiene restricciones.
  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 pod 1 envíe tráfico al pod 2 en la red de pods "azul". Pod2 no puede enviar tráfico de vuelta a Pod1 en la misma red. La política de red de los 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 impide 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), se permite todo el tráfico saliente de forma predeterminada en la interfaz de red "azul".
  4. Asegura la compatibilidad con las funciones actuales: todas las opciones de políticas de red estándar de GKE, como los selectores de etiquetas y los bloques de direcciones IP, funcionan con políticas de red de varias redes.
  5. Controla el ámbito 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 de los pods del espacio de nombres seleccionado, independientemente de las redes de pods a las que estén conectados.
    2. Si incluye la anotación y especifica 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 ningún pod conectado a la red especificada, que no existe.
  6. Mantiene la comunicación entre redes de los pods con varias interfaces de red: 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á al tráfico de otras redes de pods conectadas al mismo pod.

Ventajas

A continuación, se indican las ventajas de usar políticas de red de varias redes:

  • Seguridad mejorada: puedes mitigar los riesgos asociados al acceso no autorizado y al movimiento lateral dentro del clúster de GKE aplicando políticas de red a nivel granular.

  • Flexibilidad y personalización: puedes adaptar las políticas de red para satisfacer tus necesidades específicas de seguridad y gestión del tráfico de diferentes redes de pods, lo que te permite dar cabida a diversas cargas de trabajo y aplicaciones.

  • Gestión de redes simplificada: puedes evitar crear redes de pods excesivas y tener un control pormenorizado sobre la comunicación mediante políticas de red, lo que simplifica la gestión de redes y reduce la complejidad.

  • Optimización de costes: al no tener que crear numerosas redes de pods, puedes optimizar el uso de los recursos y reducir los costes asociados a la infraestructura de red.

  • Protección mejorada para CNFs: puedes garantizar la seguridad y la integridad de las implementaciones de CNFs aislando el tráfico de gestión y del plano de datos, y aplicando políticas de red específicas a cada implementación.

Siguientes pasos

Controlar el flujo de tráfico entre pods y servicios a nivel de pod