Crear políticas de red entre proyectos

En esta página se proporcionan instrucciones para configurar políticas de red de tráfico entre proyectos en Google Distributed Cloud (GDC) con air gap.

El tráfico entre proyectos hace referencia a la comunicación entre servicios y cargas de trabajo de diferentes espacios de nombres de proyectos, pero dentro de la misma organización.

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.

De forma predeterminada, estas políticas se aplican a todas las zonas del mundo. Para obtener más información sobre los recursos globales en un universo de GDC, consulta el artículo Descripción general de las multizonas.

Si necesitas aplicar medidas de cumplimiento del tráfico entre proyectos en una sola zona, consulta Crear una política entre proyectos a nivel de carga de trabajo de una sola zona.

Antes de empezar

Para configurar políticas de red de tráfico entre proyectos, debes tener lo siguiente:

  • Los roles de identidad y acceso necesarios. Para gestionar las políticas de un proyecto específico, necesitas el rol project-networkpolicy-admin. En los entornos multizona en los que necesites gestionar políticas que abarquen todas las zonas, debes tener el rol global-project-networkpolicy-admin. Para obtener más información, consulta Preparar roles y acceso predefinidos.
  • Un proyecto que ya tengas. Para obtener más información, consulta Crear un proyecto.

Crear una política entre proyectos

Puedes definir políticas de tráfico entre proyectos de entrada o salida para gestionar la comunicación entre proyectos.

Crear una política de acceso multiproyecto

Para que las cargas de trabajo o los servicios de un proyecto permitan las conexiones de otras cargas de trabajo de otro proyecto de tu organización, debes configurar una regla de cortafuegos de entrada que permita el tráfico entrante de otras cargas de trabajo del proyecto.

Esta política se aplica a todas las zonas de tu organización.

Sigue estos pasos para crear una regla de cortafuegos y permitir el tráfico entrante de cargas de trabajo de otro proyecto:

Consola

  1. En la consola de GDC del proyecto que estés configurando, ve a Redes > Firewall en el menú de navegación para abrir la página Firewall.
  2. Haga clic en Crear en la barra de acciones para empezar a crear una regla de cortafuegos.
  3. En la página Detalles de regla de cortafuegos, rellena la siguiente información:

    1. En el campo Nombre, introduce un nombre válido para la regla de cortafuegos.
    2. En la sección Dirección del tráfico, selecciona Entrada para permitir el tráfico entrante de cargas de trabajo de otros proyectos.
    3. En la sección Objetivo, seleccione una de las siguientes opciones:
      • Todas las cargas de trabajo de los usuarios: permite las conexiones a las cargas de trabajo del proyecto que estás configurando.
      • Servicio: indica que esta regla de cortafuegos está dirigida a un servicio específico del proyecto que estás configurando.
    4. Si tu objetivo es un servicio de proyecto, selecciona el nombre del servicio en la lista de servicios disponibles del menú desplegable Servicio.
    5. En la sección De, seleccione una de las dos opciones siguientes:
      • Todos los proyectos: permite las conexiones de las cargas de trabajo de todos los proyectos de la misma organización.
      • Otro proyecto y Todas las cargas de trabajo del usuario: permiten conexiones de cargas de trabajo de otro proyecto de la misma organización.
    6. Si solo quieres transferir cargas de trabajo de otro proyecto, selecciona un proyecto al que tengas acceso en la lista del menú desplegable ID de proyecto.
    7. Si tu objetivo son todas las cargas de trabajo de los usuarios, selecciona una de las siguientes opciones en la sección Protocolos y puertos:
      • Permitir todo: permite las conexiones mediante cualquier protocolo o puerto.
      • Protocolos y puertos especificados: permite las conexiones que usen solo los protocolos y puertos que especifiques en los campos correspondientes de la regla de cortafuegos de entrada.
  4. En la página Detalles de la regla de cortafuegos, haz clic en Crear.

Ahora has permitido las conexiones de otras cargas de trabajo del mismo proyecto dentro de la misma organización. Una vez creada la regla de cortafuegos, se mostrará en una tabla de la página Cortafuegos.

API

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. Aplica la política:

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

Sustituye GLOBAL_API_SERVER por la ruta kubeconfig del servidor de la API global. Para obtener más información, consulta Servidores de APIs globales y zonales. Si aún no has generado un archivo kubeconfig para el servidor de la API, consulta Iniciar sesión para obtener más información.

El comando anterior permite que PROJECT_2 vaya a PROJECT_1, pero no permite las conexiones iniciadas desde PROJECT_1 a PROJECT_2. Para este último, necesitas una política recíproca en el proyecto PROJECT_2. Aplica la política recíproca:

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

Ahora se permiten las conexiones hacia y desde PROJECT_1 y PROJECT_2.

Crear una política de salida entre proyectos

Cuando concedes una política de tráfico entre proyectos de entrada para permitir que las cargas de trabajo de un proyecto acepten conexiones de cargas de trabajo de otro proyecto, esta acción también 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 en el proyecto original.

Por ejemplo, si creas una política que permite el tráfico de PROJECT_1 a PROJECT_2 y la protección contra la filtración de datos está inhabilitada, debes crear una política de entrada en PROJECT_2 y una política de salida en PROJECT_1. Sin embargo, los paquetes de respuesta están excluidos de la aplicación de la política, por lo que no necesita ninguna política adicional.

Sigue estos pasos para crear una regla de cortafuegos y permitir el tráfico saliente de las cargas de trabajo de un proyecto:

  1. En la consola de GDC del proyecto que estés configurando, ve a Redes > Firewall en el menú de navegación para abrir la página Firewall.
  2. Haga clic en Crear en la barra de acciones para empezar a crear una regla de cortafuegos.
  3. En la página Detalles de regla de cortafuegos, rellena la siguiente información:

    1. En el campo Nombre, introduce un nombre válido para la regla de cortafuegos.
    2. En la sección Dirección del tráfico, selecciona Salida para indicar que esta regla de cortafuegos controla el tráfico saliente.
    3. En la sección Objetivo, seleccione una de las siguientes opciones:
      • Todas las cargas de trabajo del usuario: permite las conexiones de las cargas de trabajo del proyecto que estés configurando.
      • Servicio: indica que esta regla de cortafuegos está dirigida a un servicio específico del proyecto que estás configurando.
    4. Si tu objetivo es un servicio de proyecto, selecciona el nombre del servicio en la lista de servicios disponibles del menú desplegable Servicio.
    5. En la sección Para, seleccione una de las dos opciones siguientes:
      • Todos los proyectos: permite las conexiones a las cargas de trabajo de todos los proyectos de la misma organización.
      • Otro proyecto y Todas las cargas de trabajo del usuario: permiten conexiones a cargas de trabajo de otro proyecto de la misma organización.
    6. Si solo quiere transferir cargas de trabajo a otro proyecto, seleccione un proyecto al que pueda acceder en la lista de proyectos del menú desplegable ID de proyecto.
    7. Si tu objetivo son todas las cargas de trabajo de los usuarios, selecciona una de las siguientes opciones en la sección Protocolos y puertos:
      • Permitir todo: permite las conexiones mediante cualquier protocolo o puerto.
      • Protocolos y puertos especificados: permite las conexiones solo con los protocolos y puertos que especifiques en los campos correspondientes de la regla de cortafuegos de salida.
  4. En la página Detalles de la regla de cortafuegos, haz clic en Crear.

Ahora has permitido las conexiones a otras cargas de trabajo del proyecto dentro de la misma organización. Una vez creada la regla de cortafuegos, se mostrará en una tabla de la página Cortafuegos.

Crear una política multiproyecto a nivel de carga de trabajo

Las políticas de red a nivel de carga de trabajo ofrecen un control granular sobre la comunicación entre cargas de trabajo individuales de diferentes proyectos. Esta granularidad permite un control más estricto del acceso a la red, lo que mejora la seguridad y el uso de los recursos.

Crear una política multiproyecto a nivel de carga de trabajo de entrada

  • Para crear una política entre proyectos a nivel de carga de trabajo de entrada, crea y aplica el siguiente recurso personalizado:

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
    apiVersion: networking.global.gdc.goog/v1
    kind: ProjectNetworkPolicy
    metadata:
     namespace: PROJECT_1
     name: allow-cross-project-inbound-traffic-from-target-to-subject
    spec:
     policyType: Ingress
     subject:
       subjectType: UserWorkload
       workloadSelector:
         matchLabels:
           SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
     ingress:
     - from:
       - projectSelector:
           projects:
             matchNames:
             - PROJECT_2
           workloads:
             matchLabels:
               TARGET_LABEL_KEY: TARGET_LABEL_VALUE
    EOF
    

    Haz los cambios siguientes:

    • GLOBAL_API_SERVER: la ruta de kubeconfig del servidor de la API global. Para obtener más información, consulta Servidores de APIs globales y zonales. Si aún no has generado un archivo kubeconfig para el servidor de la API, consulta Iniciar sesión para obtener más información.
    • PROJECT_1: nombre del proyecto que recibe el tráfico.
    • PROJECT_2: nombre del proyecto del que procede el tráfico.
    • SUBJECT_LABEL_KEY: la clave de la etiqueta usada para seleccionar las cargas de trabajo de origen. Por ejemplo, app, tier o role.
    • SUBJECT_LABEL_VALUE: el valor asociado a SUBJECT_LABEL_KEY. Especifica qué cargas de trabajo son la fuente del tráfico permitido. Por ejemplo, si SUBJECT_LABEL_KEY es app y SUBJECT_LABEL_VALUE es backend, las cargas de trabajo con la etiqueta app: backend son la fuente de tráfico.
    • TARGET_LABEL_KEY: la clave de la etiqueta usada para seleccionar las cargas de trabajo de destino.
    • TARGET_LABEL_VALUE: el valor asociado a TARGET_LABEL_KEY. Especifica qué cargas de trabajo son el destino del tráfico permitido.

Crear una política de salida entre proyectos a nivel de carga de trabajo

  • Para crear una política entre proyectos a nivel de carga de trabajo de salida, crea y aplica el siguiente recurso personalizado:

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
    apiVersion: networking.global.gdc.goog/v1
    kind: ProjectNetworkPolicy
    metadata:
      namespace: PROJECT_1
      name: allow-cross-project-outbound-traffic-to-subject-from-target
    spec:
      policyType: Egress
      subject:
        subjectType: UserWorkload
        workloadSelector:
          matchLabels:
            SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
      egress:
      - to:
        - projectSelector:
            projects:
              matchNames:
              - PROJECT_2
            workloads:
              matchLabels:
                TARGET_LABEL_KEY: TARGET_LABEL_VALUE
    EOF
    

    Haz los cambios siguientes:

    • GLOBAL_API_SERVER: la ruta de kubeconfig del servidor de la API global. Para obtener más información, consulta Servidores de APIs globales y zonales. Si aún no has generado un archivo kubeconfig para el servidor de la API, consulta Iniciar sesión para obtener más información.
    • PROJECT_1: el nombre del proyecto que envía el tráfico.
    • PROJECT_2: nombre del proyecto que recibe el tráfico.
    • SUBJECT_LABEL_KEY: la clave de la etiqueta usada para seleccionar las cargas de trabajo de origen. Por ejemplo, app, tier o role.
    • SUBJECT_LABEL_VALUE: el valor asociado a SUBJECT_LABEL_KEY. Especifica qué cargas de trabajo son la fuente del tráfico permitido. Por ejemplo, si SUBJECT_LABEL_KEY es app y SUBJECT_LABEL_VALUE es backend, las cargas de trabajo con la etiqueta app: backend son la fuente de tráfico.
    • TARGET_LABEL_KEY: la clave de la etiqueta usada para seleccionar las cargas de trabajo de destino.
    • TARGET_LABEL_VALUE: el valor asociado a TARGET_LABEL_KEY. Especifica qué cargas de trabajo son el destino del tráfico permitido.

Crear una política multiproyecto a nivel de carga de trabajo de una sola zona

Las políticas de red a nivel de carga de trabajo pueden aplicar PNP en una sola zona. Se pueden añadir etiquetas específicas a las cargas de trabajo de una sola zona, lo que te permite controlar la comunicación entre cargas de trabajo individuales de un proyecto o de diferentes proyectos de esa zona.

Crear una política multiproyecto a nivel de carga de trabajo de entrada de una sola zona

  1. Para crear una política multiproyecto a nivel de carga de trabajo de entrada de una sola zona, crea y aplica el siguiente recurso personalizado:

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
    apiVersion: networking.global.gdc.goog/v1
    kind: ProjectNetworkPolicy
    metadata:
      namespace: PROJECT_1
      name: allow-single-zone-cross-project-inbound-traffic-from-target-to-subject
    spec:
      policyType: Ingress
      subject:
        subjectType: UserWorkload
        workloadSelector:
          matchLabels:
            SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
            ZONE_SUBJECT_LABEL_KEY: ZONE_SUBJECT_LABEL_VALUE
      ingress:
      - from:
        - projectSelector:
            projects:
              matchNames:
              - PROJECT_2
            workloads:
              matchLabels:
                TARGET_LABEL_KEY: TARGET_LABEL_VALUE
                ZONE_TARGET_LABEL_KEY: ZONE_TARGET_LABEL_VALUE
    EOF
    

    Haz los cambios siguientes:

    • GLOBAL_API_SERVER: la ruta de kubeconfig del servidor de la API global. Para obtener más información, consulta Servidores de APIs globales y zonales. Si aún no has generado un archivo kubeconfig para el servidor de la API, consulta Iniciar sesión para obtener más información.
    • PROJECT_1: nombre del proyecto que recibe el tráfico.
    • PROJECT_2: nombre del proyecto del que procede el tráfico.
    • SUBJECT_LABEL_KEY: la clave de la etiqueta usada para seleccionar las cargas de trabajo de origen. Por ejemplo, app, tier o role.
    • SUBJECT_LABEL_VALUE: el valor asociado a SUBJECT_LABEL_KEY. Especifica qué cargas de trabajo son la fuente del tráfico permitido. Por ejemplo, si SUBJECT_LABEL_KEY es app y SUBJECT_LABEL_VALUE es backend, las cargas de trabajo con la etiqueta app: backend son la fuente de tráfico.
    • TARGET_LABEL_KEY: la clave de la etiqueta usada para seleccionar las cargas de trabajo de destino.
    • TARGET_LABEL_VALUE: el valor asociado a TARGET_LABEL_KEY. Especifica qué cargas de trabajo son el destino del tráfico permitido.
    • ZONE_SUBJECT_LABEL_KEY: la clave de la etiqueta utilizada para seleccionar la zona de origen. Por ejemplo, zone o region.
    • ZONE_SUBJECT_LABEL_VALUE: el valor asociado a ZONE_SUBJECT_LABEL_KEY. Especifica qué zona es la fuente del tráfico permitido. Por ejemplo, si ZONE_SUBJECT_LABEL_KEY es zone y ZONE_SUBJECT_LABEL_VALUE es us-central1-a, las cargas de trabajo con la etiqueta zone: us-central1-a son la fuente de tráfico.
    • ZONE_TARGET_LABEL_KEY: la clave de la etiqueta usada para seleccionar la zona de destino.
    • ZONE_TARGET_LABEL_VALUE: el valor asociado a ZONE_TARGET_LABEL_KEY. Especifica la zona de destino del tráfico permitido.

Crear una política multiproyecto a nivel de carga de trabajo de salida de una sola zona

  • Para crear una política de salida entre proyectos a nivel de carga de trabajo de una sola zona, crea y aplica el siguiente recurso personalizado:

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
    apiVersion: networking.global.gdc.goog/v1
    kind: ProjectNetworkPolicy
    metadata:
      namespace: PROJECT_1
      name: allow-single-zone-cross-project-outbound-traffic-to-subject-from-target
    spec:
      policyType: Egress
      subject:
        subjectType: UserWorkload
        workloadSelector:
          matchLabels:
            SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
            ZONE_SUBJECT_LABEL_KEY: ZONE_SUBJECT_LABEL_VALUE
      egress:
      - to:
        - projectSelector:
            projects:
              matchNames:
              - PROJECT_2
            workloads:
              matchLabels:
                TARGET_LABEL_KEY: TARGET_LABEL_VALUE
                ZONE_TARGET_LABEL_KEY: ZONE_TARGET_LABEL_VALUE
    EOF
    

    Haz los cambios siguientes:

    • GLOBAL_API_SERVER: la ruta de kubeconfig del servidor de la API global. Para obtener más información, consulta Servidores de APIs globales y zonales. Si aún no has generado un archivo kubeconfig para el servidor de la API, consulta Iniciar sesión para obtener más información.
    • PROJECT_1: el nombre del proyecto que envía el tráfico.
    • PROJECT_2: nombre del proyecto que recibe el tráfico.
    • SUBJECT_LABEL_KEY: la clave de la etiqueta usada para seleccionar las cargas de trabajo de origen. Por ejemplo, app, tier o role.
    • SUBJECT_LABEL_VALUE: el valor asociado a SUBJECT_LABEL_KEY. Especifica qué cargas de trabajo son la fuente del tráfico permitido. Por ejemplo, si SUBJECT_LABEL_KEY es app y SUBJECT_LABEL_VALUE es backend, las cargas de trabajo con la etiqueta app: backend son la fuente de tráfico.
    • TARGET_LABEL_KEY: la clave de la etiqueta usada para seleccionar las cargas de trabajo de destino.
    • TARGET_LABEL_VALUE: el valor asociado a TARGET_LABEL_KEY. Especifica qué cargas de trabajo son el destino del tráfico permitido.
    • ZONE_SUBJECT_LABEL_KEY: la clave de la etiqueta utilizada para seleccionar la zona de origen. Por ejemplo, zone o region.
    • ZONE_SUBJECT_LABEL_VALUE: el valor asociado a ZONE_SUBJECT_LABEL_KEY. Especifica qué zona es la fuente del tráfico permitido. Por ejemplo, si ZONE_SUBJECT_LABEL_KEY es zone y ZONE_SUBJECT_LABEL_VALUE es us-central1-a, las cargas de trabajo con la etiqueta zone: us-central1-a son la fuente de tráfico.
    • ZONE_TARGET_LABEL_KEY: la clave de la etiqueta usada para seleccionar la zona de destino.
    • ZONE_TARGET_LABEL_VALUE: el valor asociado a ZONE_TARGET_LABEL_KEY. Especifica la zona de destino del tráfico permitido.