Introducción

En esta página se ofrece una descripción general de las políticas de red de proyectos en Google Distributed Cloud (GDC) aislado.

Las políticas de red de un proyecto definen reglas de entrada o de salida. A diferencia de las políticas de red de Kubernetes, solo puedes especificar un tipo de política por política. Cada regla de una política se puede configurar con la acción Permitir (valor predeterminado) o Denegar.

En el caso del tráfico de un proyecto, GDC aplica de forma predeterminada a cada proyecto una política de red de proyecto predefinida, la política intraproyecto.

Los servicios y las cargas de trabajo de un proyecto están aislados de los servicios y las cargas de trabajo externos de forma predeterminada. Sin embargo, los servicios y las cargas de trabajo de diferentes espacios de nombres de proyectos y de la misma organización pueden comunicarse entre sí aplicando políticas de red de tráfico entre proyectos.

Del mismo modo, para conectar servicios y cargas de trabajo a un destino fuera de tu proyecto en otra organización, se necesita una aprobación explícita. Debes inhabilitar la protección contra la filtración externa de datos para permitir el tráfico externo a la organización.

Las reglas de cortafuegos de entrada y salida son los componentes principales de las políticas de red de un proyecto y determinan qué tipos de tráfico se permiten o se deniegan en tu red. Para definir reglas de cortafuegos para el espacio de nombres de tu proyecto en GDC, usa la consola de GDC.

Seguridad y conectividad

De forma predeterminada, los servicios y las cargas de trabajo de un proyecto están aislados dentro de ese proyecto. No pueden comunicarse con servicios y cargas de trabajo externos sin configurar una política de red.

Para definir una política de red para el espacio de nombres de tu proyecto en GDC, usa el recurso ProjectNetworkPolicy. Este recurso te permite definir políticas que permiten la comunicación dentro de los proyectos, entre proyectos, con direcciones IP externas y desde direcciones IP externas. Además, solo puedes transferir cargas de trabajo de un proyecto si inhabilitas la protección contra la filtración externa de datos del proyecto.

Las políticas de red de proyectos de GDC son acumulativas. La aplicación resultante de una carga de trabajo es una coincidencia cualquiera para el flujo de tráfico con la unión de todas las políticas aplicadas a esa carga de trabajo. Cuando hay varias políticas, las reglas de cada política se combinan de forma acumulativa, lo que permite el tráfico si coincide con al menos una de las reglas.

Las reglas de Deny explícitas tienen prioridad absoluta sobre las reglas de Allow. Si un flujo de tráfico coincide con una regla Deny, se rechaza, aunque lo permitan otra regla o las políticas predeterminadas de la plataforma.

Además, después de aplicar una sola política que seleccione una carga de trabajo, se denegará todo el tráfico que no especifiques (modo de denegación predeterminado). Por lo tanto, cuando aplique una o varias políticas que seleccionen una carga de trabajo como asunto, solo se permitirá el tráfico que se haya permitido explícitamente (y no se haya denegado explícitamente).

Cuando usas una dirección IP conocida que asignas al proyecto, se realiza una traducción de direcciones de red (NAT) de origen en el tráfico saliente de la organización.

Políticas de red de proyectos globales

Puedes crear políticas de red de proyecto globales. El ámbito de las políticas de red de proyectos globales abarca un universo de GDC. Cada universo de GDC puede constar de varias zonas de GDC organizadas en regiones interconectadas que comparten un plano de control. Por ejemplo, un universo que consta de dos regiones con tres zonas cada una podría tener este aspecto: us-virginia1-a, us-virginia1-b, us-virginia1-c y eu-ams1-a, eu-ams1-b, eu-ams1-c.

El ámbito de las políticas de red de proyectos zonales se limita a las zonas especificadas en el momento de la creación. Cada zona es un dominio de desastres independiente. Una zona gestiona la infraestructura, los servicios, las APIs y las herramientas que usan un plano de control local.

Para obtener más información sobre los recursos globales en un universo de GDC, consulta el artículo Descripción general de multizona.

Puedes crear políticas de red de proyectos globales mediante la API Networking Kubernetes Resource Model (KRM). Usa la versión de la API networking.global.gdc.goog para crear recursos globales.

Puedes crear políticas de red de proyectos zonales mediante la API KRM o la consola de GDC. Usa la versión de la API networking.gdc.goog para crear recursos zonales.

Políticas de red que permiten todo

Puedes crear políticas de red que permitan todo para establecer reglas de acceso predeterminadas y generales para un proyecto.

Puede configurar los siguientes tipos de políticas de red que permiten todo:

  • Política de red que permite todo: permite el tráfico hacia y desde cualquier origen, incluidos otros proyectos e IPs externas.
  • Política de red Allow-all-external: permite el tráfico hacia y desde direcciones IP externas a la organización.
  • Política de red que permite todos los proyectos: permite el tráfico hacia y desde todos los proyectos de la organización.

Para obtener más información, consulta Crear políticas de red de tráfico de permitir todo.

Políticas de red de denegación explícita

Puedes configurar reglas de denegación explícita en las políticas de red de proyectos para restringir la conectividad entre proyectos o bloques CIDR específicos.

Características y restricciones principales de las reglas de denegación:

  • Prioridad: las reglas de denegación tienen prioridad absoluta sobre las reglas de permiso (incluidas las políticas de la plataforma base).
  • Reglas de seguridad de salida: para evitar que se bloquee accidentalmente el tráfico de infraestructuras críticas, las reglas de denegación de salida excluyen automáticamente los espacios de nombres del sistema y los que no son de proyectos.
  • Restricción de peers: para garantizar una configuración segura, se necesitan reglas de denegación de entrada para especificar explícitamente un peer de origen. No puedes seleccionar todas las fuentes dejando vacío el peer de origen. No se permite dejar vacío el elemento de origen del mismo nivel y se rechazará la política.
  • No se puede denegar la salida con DEP: no puedes configurar reglas de denegación de salida cuando la protección contra la filtración externa de datos (DEP) está habilitada en el proyecto.

Para obtener más información, consulta Crear políticas de red de denegación.

Políticas de red a nivel de carga de trabajo

Puedes crear políticas de red a nivel de carga de trabajo para definir un control de acceso pormenorizado para máquinas virtuales y pods concretos de un proyecto. Estas políticas actúan como cortafuegos para tus cargas de trabajo, controlando el flujo de tráfico en función de las etiquetas para mejorar la seguridad y aislar las aplicaciones. Esta granularidad permite controlar de forma más estricta qué cargas de trabajo pueden comunicarse entre sí dentro de un proyecto y entre proyectos.

Las políticas de red a nivel de carga de trabajo también permiten aplicar PNP en una sola zona.

Para obtener más información, consulta Crear una política intraproyecto a nivel de carga de trabajo y Crear una política entre proyectos a nivel de carga de trabajo.

Preparar roles y accesos predefinidos

Para configurar las políticas de red de un proyecto, debes tener los roles de identidad y acceso necesarios:

  • Administrador de NetworkPolicy de proyecto: gestiona las políticas de red del proyecto en el espacio de nombres del proyecto. Pide al administrador de gestión de identidades y accesos de tu organización que te asigne el rol de clúster Administrador de NetworkPolicy de proyectos (project-networkpolicy-admin).
  • Administrador global de PNP: tiene permisos de escritura en todos los recursos de PNP multizona del espacio de nombres del proyecto global. Pide al administrador de gestión de identidades y accesos de tu organización que te asigne el rol de administrador global de PNP (global-project-networkpolicy-admin). Para obtener más información, consulta Descripciones de los roles predefinidos.

Consideraciones sobre la selección y el escalado de nodos

Al configurar políticas de red de proyectos para orientarlas a nodos específicos o usar intervalos CIDR amplios, las opciones de configuración de la política pueden afectar a la escalabilidad y al rendimiento. Ten en cuenta lo siguiente:

Impacto de los intervalos CIDR amplios en la escalabilidad

  • Comportamiento de 0.0.0.0/0: si se usa un CIDR amplio, como 0.0.0.0/0, en una regla ipBlocks, se incluirán todos los nodos del clúster, así como las IPs externas.
  • Escala: a cada nodo del clúster se le asigna una identidad CIDR única. Cada endpoint de carga de trabajo (VM o pod) tiene una tabla de políticas internas subyacente (un mapa BPF) que almacena sus reglas de red. En los clústeres grandes, las reglas ipBlocks amplias (como 0.0.0.0/0) aumentan el uso del mapa de políticas en el orden del número de nodos, ya que el sistema debe crear entradas para cada identidad CIDR de nodo único.
  • Práctica recomendada: Evita usar intervalos CIDR demasiado amplios en ipBlocks si tienes un número de nodos muy alto o un gran número de políticas complejas, ya que puedes alcanzar el límite de mapas de políticas por endpoint. Si un endpoint alcanza este límite, no se podrán aplicar nuevas políticas de red, lo que puede interrumpir la conectividad de red o impedir que se apliquen políticas a esa carga de trabajo.

Siguientes pasos