Esta página se ha traducido con Cloud Translation API.

Política de red

Para definir una política de red para cargas de trabajo de máquinas virtuales a nivel de espacio de nombres del proyecto, usa el recurso ProjectNetworkPolicy, una política de red multiclúster para el dispositivo aislado de Google Distributed Cloud (GDC). Te permite definir políticas que permiten la comunicación dentro de los proyectos, entre proyectos y con direcciones IP externas.

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. Para habilitar y controlar el tráfico entre proyectos de la misma organización, debes definir políticas entre proyectos. Cuando hay varias políticas, GDC combina de forma aditiva las reglas de cada proyecto. GDC también permite el tráfico si se cumple al menos una de las reglas.

Solicitar permiso y acceso

Para realizar las tareas que se indican en esta página, debes tener el rol de administrador de ProjectNetworkPolicy. Pide al administrador de gestión de identidades y accesos de tu proyecto que te conceda el rol Administrador de políticas de red de proyectos (project-networkpolicy-admin) en el espacio de nombres del proyecto en el que se encuentra la VM.

Tráfico entre proyectos

De forma predeterminada, las cargas de trabajo de las VMs de un espacio de nombres de un proyecto pueden comunicarse entre sí sin exponer servicios al mundo exterior, aunque las VMs formen parte de clústeres diferentes dentro del mismo proyecto.

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

Cuando creas un proyecto, se crea una base ProjectNetworkPolicy predeterminada en el servidor de la API Management para permitir la comunicación entre proyectos. Esta política permite el tráfico entrante de otras cargas de trabajo del mismo proyecto. Puedes quitarlo, pero ten cuidado, ya que esto deniega la comunicación entre proyectos y cargas de trabajo de contenedores.

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

De forma predeterminada, no tienes que hacer nada con respecto a la salida. Esto se debe a que, si no hay una política de salida, se permite todo el tráfico. Sin embargo, cuando se define una sola política, solo se permite el tráfico que especifica la política.

Cuando inhabilite la prevención de exfiltración de datos y aplique una ProjectNetworkPolicy de salida al proyecto, como impedir el acceso a un recurso externo, utilice una política obligatoria para permitir la salida entre proyectos:

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 máquinas virtuales 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.

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

Para que las cargas de trabajo de un proyecto permitan las conexiones de otras cargas de trabajo de otro proyecto, debes configurar una política de entrada para que las cargas de trabajo del otro proyecto puedan entrar.

La siguiente política permite que las cargas de trabajo del proyecto PROJECT_1 permitan las conexiones de las cargas de trabajo del proyecto PROJECT_2, así como el tráfico de retorno de 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. Para esto último, necesitas una política recíproca en el proyecto PROJECT_2. Ejecuta el siguiente comando para aplicar la política recíproca:

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 permites las conexiones iniciadas hacia y desde PROJECT_1 y PROJECT_2.

Usa las siguientes definiciones para tus variables.

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

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

Cuando concede una política de tráfico entre proyectos de entrada para habilitar cargas de trabajo en un proyecto (PROJECT_1) y permitir conexiones de cargas de trabajo en otro proyecto (PROJECT_2), también se concede el tráfico de retorno de los mismos flujos. Por lo tanto, no necesita una política de red de tráfico entre proyectos de salida.

Tráfico entre organizaciones

Para conectar una carga de trabajo de una VM a un destino fuera de tu proyecto que se encuentre en otra organización, se requiere una aprobación explícita. Esta aprobación se debe a la prevención de la exfiltración de datos, que GDC habilita de forma predeterminada e impide 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 añadir una política de salida específica y habilitar la exfiltración de datos.

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

Cuando hayas configurado una política de red de salida entre organizaciones, no tendrás que conceder acceso de entrada. El tráfico de salida permitido de la carga de trabajo fuera de tu organización pasa por un balanceador de carga y ese tráfico de salida es una traducción de direcciones de red (NAT) de origen que usa una dirección IP que has asignado al proyecto.

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

Para habilitar la salida a servicios externos a la organización, personaliza la política de red de tu proyecto, ProjectNetworkPolicy. Sin embargo, como la prevención de exfiltración de datos está habilitada de forma predeterminada, tu salida ProjectNetworkPolicy personalizada muestra un error de validación en el campo de estado y el plano de datos lo ignora. Esto ocurre por diseño.

Las cargas de trabajo pueden salir cuando permites la filtración externa de datos de 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 explica cómo habilitar tu política de salida personalizada:

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

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

Cuando termines, confirma que aparece un error de validación en el estado.

Importante: Solo se permite el tráfico de salida a destinos ajenos a la organización de tu proyecto que hayas permitido explícitamente en tu configuración de salida.ProjectNetworkPolicy Se deniega cualquier otro tráfico de salida. Por lo tanto, solo debes aplicar un Egress personalizado ProjectNetworkPolicy cuando los requisitos exijan una política de este tipo.
Pide al usuario administrador que inhabilite la prevención de filtración de datos. De esta forma, se habilita la configuración y se impide el resto del tráfico de salida.

Importante: Si inhabilitas la prevención de filtraciones externas de datos sin definir uno o varios ProjectNetworkPolicys válidos, se permitirá todo el tráfico de salida a destinos ajenos a la organización de tu proyecto. No inhabilite nunca esta opción sin haber completado primero el paso 1 para configurar su ProjectNetworkPolicysalida
personalizada.

Comprueba el ProjectNetworkPolicy que acabas de crear y verifica que ya no aparece el error en el campo de estado de validación y que el estado Ready es True, lo que indica que tu política está activa:

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

Sustituye las variables con las siguientes definiciones.

Variable	Definición
`MANAGEMENT_API_SERVER`	El archivo `kubeconfig` del servidor de la API Management.
`PROJECT_1`	El nombre del proyecto de GDC.
`CIDR`	El bloque de enrutamiento de interdominios sin clases (CIDR) del destino permitido.
`NAME`	Nombre asociado al destino.

Una vez que hayas aplicado esta política, y siempre que no hayas definido otras políticas de salida, se denegará todo el tráfico de salida de PROJECT_1.