Política de red

Para definir una política de red para cargas de trabajo de máquinas virtuales a nivel del espacio de nombres del proyecto, usa el recurso ProjectNetworkPolicy, una política de red multiclúster para Google Distributed Cloud air-gapped (GDC). Te permite definir políticas, lo que permite 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, define 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 de entrada de otras cargas de trabajo del mismo proyecto. Puedes quitarlo, pero ten cuidado, ya que esto deniega la comunicación de la carga de trabajo tanto entre proyectos como entre 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 distintos espacios de nombres de proyectos pero 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 permitir que las cargas de trabajo del otro proyecto transfieran datos.

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. Si quieres acceder a tu VM en PROJECT_1 desde una fuente que esté en PROJECT_2, también puedes usar esta política. 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.

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 necesitas 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

Para permitir el tráfico de entrada entre diferentes organizaciones, se debe aplicar un ProjectNetworkPolicy que permita el tráfico de clientes externos de la organización a tu proyecto. Por ejemplo, puedes conectarte a la VM mediante SSH.

No es necesario que haya una política de salida correspondiente para el tráfico de respuesta. El tráfico de retorno se permite de forma implícita.

Si quieres acceder a tu VM en PROJECT_1 desde una fuente que no pertenezca a la organización en la que reside la VM, debes aplicar la siguiente política. Debes obtener y usar el CIDR que contiene tu dirección IP de origen. El CIDR debe estar en notación network/len. Por ejemplo, 192.0.2.0/21 es un valor válido.

1. Configura y aplica tu Ingress ProjectNetworkPolicy siguiendo el ejemplo de kubectl. Aplica la política a todas las cargas de trabajo de los usuarios en PROJECT_1. Permite el tráfico entrante a todos los hosts de CIDR, que se encuentran fuera de la organización.

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-external-traffic
   spec:
     policyType: Ingress
     subject:
       subjectType: UserWorkload
     ingress:
      - from:
        - ipBlock:
            cidr: CIDR
   EOF
   

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

Para habilitar la transferencia de datos a servicios externos a la organización, personaliza la política de red de tu proyecto, ProjectNetworkPolicy. Como la prevención de la exfiltración de datos está habilitada de forma predeterminada, tu salida personalizada ProjectNetworkPolicy muestra un error de validación en el campo de estado y el plano de datos lo ignora. Este proceso se lleva a cabo de forma predeterminada.

Como se indica en Seguridad y conectividad, las cargas de trabajo pueden transferir datos cuando permites la exfiltración de datos de un proyecto determinado. El tráfico que permites que se transfieran datos es una traducción de direcciones de red (NAT) de origen que usa una dirección IP conocida asignada al proyecto. Seguridad y conectividad también proporciona detalles sobre la aplicación de la política de red del proyecto (ProjectNetworkPolicy).

No se necesita una política de entrada correspondiente para el tráfico de respuesta. El tráfico de retorno se permite de forma implícita.

Habilita tu política de salida personalizada:

1. Configura y aplica tu propio Egress personalizado ProjectNetworkPolicy siguiendo el ejemplo de kubectl. 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.

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 aparece un error de validación en el estado.

4. 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.

   personalizado.

5. 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	Ruta de 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.