Política de red

Para establecer una política de red para las cargas de trabajo de máquina virtual (VM) a nivel del espacio de nombres del proyecto, usa el recurso ProjectNetworkPolicy, una política de red de varios clústeres para el dispositivo aislado de Google Distributed Cloud (GDC). Te permite definir políticas, lo que permite la comunicación dentro de los proyectos, entre proyectos y con direcciones IP externas.

Para el tráfico dentro de un proyecto, GDC aplica una política de red del proyecto predefinida, la política intraproyecto, a cada proyecto de forma predeterminada. Para habilitar y controlar el tráfico entre proyectos dentro de la misma organización, debes definir políticas entre proyectos. Cuando hay varias políticas presentes, GDC combina de forma aditiva las reglas de cada proyecto. El GDC también permite el tráfico si coincide al menos una de las reglas.

Solicita permiso y acceso

Para realizar las tareas que se indican en esta página, debes tener el rol de administrador de ProjectNetworkPolicy. Pídele al administrador de IAM del proyecto que te otorgue el rol de administrador de NetworkPolicy del proyecto (project-networkpolicy-admin) en el espacio de nombres del proyecto en el que reside la VM.

Tráfico dentro del proyecto

De forma predeterminada, las cargas de trabajo de VM en un espacio de nombres del proyecto pueden comunicarse entre sí sin exponer servicios al mundo externo, incluso si las VMs forman parte de diferentes clústeres dentro del mismo proyecto.

Política de red de tráfico de entrada dentro del proyecto

Cuando creas un proyecto, creas un objeto ProjectNetworkPolicy base predeterminado en el servidor de la API de Management para permitir la comunicación dentro del proyecto. Esta política permite el tráfico de entrada de otras cargas de trabajo en el mismo proyecto. Puedes quitarlo, pero ten cuidado si lo haces, ya que esto deniega la comunicación de la carga de trabajo tanto dentro del proyecto como del contenedor.

Política de red de tráfico de salida dentro del proyecto

De forma predeterminada, no es necesario que realices ninguna acción en relación con la salida. Esto se debe a que, en ausencia de una política de salida, se permite todo el tráfico. Sin embargo, cuando estableces una sola política, solo se permite el tráfico que especifica la política.

Cuando inhabilitas la Prevención de robo de datos y aplicas un ProjectNetworkPolicy de salida al proyecto, como impedir el acceso a un recurso externo, usa una política obligatoria para permitir la salida dentro del proyecto:

kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_1
  name: allow-intra-project-egress-traffic
spec:
  policyType: Egress

  ingress:
  - from:
    - projects:
        matchNames:
        - PROJECT_1
EOF

Tráfico entre proyectos (dentro de la organización)

Las cargas de trabajo de VM de diferentes espacios de nombres de proyectos pero dentro de la misma organización pueden comunicarse entre sí aplicando una política de red entre proyectos.

Importante: Esta política solo se aplica a los proyectos dentro de la misma organización que provienen de diferentes espacios de nombres de proyectos. Para obtener información sobre el tráfico entre organizaciones, que requiere instrucciones específicas, ya que la Prevención de exfiltración de datos protege contra toda salida de este tipo de forma predeterminada, consulta la sección Tráfico entre organizaciones.

Política de red de tráfico de entrada entre proyectos

Para que las cargas de trabajo del proyecto permitan conexiones de otras cargas de trabajo en otro proyecto, debes configurar una política de entrada para permitir que las cargas de trabajo del otro proyecto ingresen.

La siguiente política permite que las cargas de trabajo en el proyecto PROJECT_1 permitan conexiones de cargas de trabajo en el proyecto PROJECT_2, así como el tráfico de retorno para los mismos flujos. Ejecuta el siguiente comando para aplicar la política:

kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_1
  name: allow-ingress-traffic-from-PROJECT_2
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
  ingress:
  - from:
    - projects:
        matchNames:
        - PROJECT_2
EOF

El comando anterior permite que PROJECT_2 vaya a PROJECT_1, pero no permite las conexiones iniciadas desde PROJECT_1 a PROJECT_2. En el caso de la última, necesitas una política recíproca en el proyecto PROJECT_2. Ejecuta el siguiente comando para aplicar la política de reciprocidad:

kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_2
  name: allow-ingress-traffic-from-PROJECT_1
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
  ingress:
  - from:
    - projects:
        matchNames:
        - PROJECT_1
EOF

Ahora permitiste las conexiones iniciadas hacia PROJECT_1 y PROJECT_2, y desde ellas.

Usa las siguientes definiciones para tus variables.

Variable	Definición
MANAGEMENT_API_SERVER	Es la ruta de acceso kubeconfig del servidor de la API de Management.
PROJECT_1	Es el nombre de un proyecto de GDC que corresponde a PROJECT_1 en el ejemplo.
PROJECT_2	Es el nombre de un proyecto de GDC que corresponde a PROJECT_2 en el ejemplo.

Política de red de tráfico de salida entre proyectos

Cuando otorgas una política de tráfico entre proyectos de entrada para habilitar cargas de trabajo en un proyecto, PROJECT_1, para permitir conexiones desde cargas de trabajo en otro proyecto, PROJECT_2, esto también otorga el tráfico de retorno para los mismos flujos. Por lo tanto, no necesitas una política de red de tráfico entre proyectos de salida.

Tráfico entre organizaciones

Para conectar una carga de trabajo de VM a un destino fuera de tu proyecto que se encuentra en una organización diferente, se requiere aprobación explícita. Esa aprobación se debe a la prevención de robo de datos, que GDC habilita de forma predeterminada y evita que un proyecto tenga salida a cargas de trabajo fuera de la organización en la que reside el proyecto. En esta sección, se incluyen las instrucciones para agregar una política de salida específica y habilitar la robo de datos.

Política de red de tráfico de entrada entre organizaciones

Cuando configuras una política de red de salida entre organizaciones, no necesitas otorgar acceso de entrada. El tráfico de salida permitido desde la carga de trabajo fuera de tu organización pasa por un balanceador de cargas (LB), y ese tráfico de salida es una traducción de direcciones de red (NAT) de origen que usa una dirección IP que asignaste para el proyecto.

Política de red de tráfico de salida entre organizaciones

Para habilitar el tráfico de salida a servicios fuera de la organización, personaliza la política de red de tu proyecto, ProjectNetworkPolicy. Sin embargo, debido a que la prevención de robo de datos está habilitada de forma predeterminada, tu objeto Egress personalizado ProjectNetworkPolicy muestra un error de validación en el campo de estado, y el plano de datos lo ignora. Esto sucede por diseño.

Las cargas de trabajo pueden realizar una salida cuando permites el robo de datos para un proyecto determinado. El tráfico que permites que salga es una traducción de direcciones de red (NAT) de origen que usa una dirección IP conocida asignada al proyecto.

En estas instrucciones, se muestra cómo habilitar tu política de salida personalizada:

1. Configura y aplica tu propio Egress personalizado ProjectNetworkPolicy, siguiendo el ejemplo de la CLI de kubectl. Aplica la política a todas las cargas de trabajo de los usuarios en PROJECT_1. Permite el tráfico de salida a todos los hosts en CIDR, que residen fuera de la organización. Tu primer intento genera un error de estado necesario, lo que es intencional.

2. Aplica la configuración de ProjectNetworkPolicy:

   kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
   apiVersion: networking.gdc.goog/v1
   kind: ProjectNetworkPolicy
   metadata:
     namespace: PROJECT_1
     name: allow-egress-traffic-to-NAME
   spec:
     policyType: Egress
     subject:
       subjectType: UserWorkload
    egress:
     - to:
       - ipBlock:
           cidr: CIDR
   EOF
   

3. Cuando termines, confirma que ves un error de validación en tu estado.

   Importante: Solo se permite el tráfico de salida a destinos fuera de la organización de tu proyecto que permitas de forma explícita en la configuración de ProjectNetworkPolicy de salida. Se rechaza cualquier otro tráfico de salida. Por lo tanto, solo aplica un ProjectNetworkPolicy de salida personalizado cuando los requisitos exijan una política de este tipo.

4. Pídele al usuario administrador que inhabilite la Prevención de robo de datos. Esto habilita tu configuración y, al mismo tiempo, evita cualquier otro tráfico de salida.

   Importante: Si inhabilitas la prevención de robo de datos sin definir uno o más ProjectNetworkPolicys válidos, se permitirá todo el tráfico de salida a destinos fuera de la organización de tu proyecto. Nunca inhabilite esta opción sin antes completar el paso 1 para configurar su salida ProjectNetworkPolicy personalizada.

5. Revisa el ProjectNetworkPolicy que acabas de crear y verifica que el error en el campo de estado de validación haya desaparecido y que el estado Ready sea True, lo que indica que tu política está vigente:

   kubectl --kubeconfig MANAGEMENT_API_SERVER get projectnetworkpolicy
   allow-egress-traffic-to-NAME -n PROJECT_1 -o yaml
   

   Reemplaza las variables con las siguientes definiciones.

   Variable	Definición
   MANAGEMENT_API_SERVER	El archivo kubeconfig del servidor de la API de Management
   PROJECT_1	Es el nombre del proyecto de GDC.
   CIDR	Bloque de enrutamiento entre dominios sin clases (CIDR) del destino permitido.
   NAME	Es un nombre asociado con el destino.

   Después de aplicar esta política, y siempre que no hayas definido otras políticas de salida, se rechazará todo el tráfico de salida para PROJECT_1.