Crea 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) aislado.

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

De forma predeterminada, los servicios y las cargas de trabajo de un proyecto están aislados de los servicios y las cargas de trabajo externos. Sin embargo, los servicios y las cargas de trabajo de diferentes espacios de nombres del proyecto y dentro 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 nivel global en todas las zonas. Para obtener más información sobre los recursos globales en un universo de GDC, consulta la descripción general de varias zonas.

Si se necesita la aplicación de políticas de tráfico entre proyectos en una sola zona, consulta Crea una política entre proyectos a nivel de la carga de trabajo para una sola zona.

Antes de comenzar

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

  • Los roles de identidad y acceso necesarios Para administrar las políticas de un proyecto específico, necesitas el rol de project-networkpolicy-admin. Para los entornos de varias zonas en los que necesitas administrar políticas que abarcan todas las zonas, necesitas el rol de global-project-networkpolicy-admin. Para obtener más información, consulta Cómo preparar roles y acceso predefinidos.
  • Un proyecto existente Para obtener más información, consulta Cómo crear un proyecto.

Crea una política entre proyectos

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

Crea una política de entrada entre proyectos

Para que las cargas de trabajo o los servicios del proyecto permitan conexiones de otras cargas de trabajo en otro proyecto dentro de tu organización, debes configurar una regla de firewall de entrada para permitir 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 firewall nueva y permitir el tráfico entrante de las cargas de trabajo en otro proyecto:

Console

  1. En la consola de GDC del proyecto que estás configurando, ve a Networking > Firewall en el menú de navegación para abrir la página Firewall.
  2. Haz clic en Crear en la barra de acciones para comenzar a crear una nueva regla de firewall.
  3. En la página Detalles de la regla de firewall, completa la siguiente información:

    1. En el campo Nombre, ingresa un nombre válido para tu regla de firewall.
    2. En la sección Dirección del tráfico, selecciona Entrada para permitir el tráfico entrante de cargas de trabajo en otros proyectos.
    3. En la sección Objetivo, selecciona una de las siguientes opciones:
      • Todas las cargas de trabajo del usuario: Permite conexiones a las cargas de trabajo del proyecto que estás configurando.
      • Servicio: Indica que esta regla de firewall tiene como objetivo un servicio específico dentro del proyecto que estás configurando.
    4. Si tu destino es un servicio del proyecto, selecciona el nombre del servicio en la lista de servicios disponibles en el menú desplegable Servicio.
    5. En la sección De, selecciona una de las siguientes dos opciones:
      • Todos los proyectos: Permite conexiones desde cargas de trabajo en todos los proyectos de la misma organización.
      • Otro proyecto y Todas las cargas de trabajo del usuario: Permiten conexiones desde cargas de trabajo en otro proyecto de la misma organización.
    6. Si solo quieres transferir cargas de trabajo desde otro proyecto, selecciona un proyecto al que puedas acceder desde la lista de proyectos en el menú desplegable ID del proyecto.
    7. Si tu objetivo son todas las cargas de trabajo del usuario, selecciona una de las siguientes opciones en la sección Protocolos y puertos:
      • Permitir todo: Permite conexiones con cualquier protocolo o puerto.
      • Protocolos y puertos especificados: Permiten conexiones solo con los protocolos y puertos que especificas en los campos correspondientes de la regla de firewall de entrada.
  4. En la página Detalles de la regla de firewall, haz clic en Crear.

Ahora permitiste las conexiones de otras cargas de trabajo del proyecto dentro de la misma organización. Después de crear la regla de firewall, esta se mostrará en una tabla en la página Firewall.

API

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

Reemplaza GLOBAL_API_SERVER por la ruta de acceso del archivo kubeconfig del servidor de la API global. Para obtener más información, consulta Servidores de API globales y zonales. Si aún no generaste un archivo kubeconfig para el servidor de la API, consulta Accede para obtener más detalles.

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 segundo caso, necesitas una política recíproca en el proyecto PROJECT_2. Aplica la política de reciprocidad:

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.

Crea una política de salida entre proyectos

Cuando otorgas una política de tráfico de entrada entre proyectos para permitir que las cargas de trabajo de un proyecto permitan conexiones de cargas de trabajo en otro proyecto, esta acción 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 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 robo 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 se excluyen de la aplicación de la política, por lo que no necesitas políticas adicionales.

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

  1. En la consola de GDC del proyecto que estás configurando, ve a Networking > Firewall en el menú de navegación para abrir la página Firewall.
  2. Haz clic en Crear en la barra de acciones para comenzar a crear una nueva regla de firewall.
  3. En la página Detalles de la regla de firewall, completa la siguiente información:

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

Ahora permitiste las conexiones a otras cargas de trabajo del proyecto dentro de la misma organización. Después de crear la regla de firewall, esta se mostrará en una tabla en la página Firewall.

Crea una política entre proyectos a nivel de la carga de trabajo

Las políticas de red a nivel de la carga de trabajo ofrecen un control detallado sobre la comunicación entre cargas de trabajo individuales en todos los 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.

Crea una política entre proyectos a nivel de la carga de trabajo de entrada

  • Para crear una política entre proyectos a nivel de la 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
    

    Reemplaza lo siguiente:

    • GLOBAL_API_SERVER: Es la ruta de acceso de kubeconfig del servidor de la API global. Para obtener más información, consulta Servidores de API globales y zonales. Si aún no generaste un archivo kubeconfig para el servidor de la API, consulta Acceder para obtener más detalles.
    • PROJECT_1: Es el nombre del proyecto que recibe el tráfico.
    • PROJECT_2: Es el nombre del proyecto desde el que proviene el tráfico.
    • SUBJECT_LABEL_KEY: Es la clave de la etiqueta que se usa para seleccionar las cargas de trabajo de origen. Por ejemplo, app, tier o role.
    • SUBJECT_LABEL_VALUE: Es el valor asociado con el 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: Es la clave de la etiqueta que se usa para seleccionar las cargas de trabajo de destino.
    • TARGET_LABEL_VALUE: Es el valor asociado con el TARGET_LABEL_KEY. Especifica qué cargas de trabajo son el destino del tráfico permitido.

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

  • Para crear una política entre proyectos a nivel de la 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
    

    Reemplaza lo siguiente:

    • GLOBAL_API_SERVER: Es la ruta de acceso de kubeconfig del servidor de la API global. Para obtener más información, consulta Servidores de API globales y zonales. Si aún no generaste un archivo kubeconfig para el servidor de la API, consulta Acceder para obtener más detalles.
    • PROJECT_1: Es el nombre del proyecto que envía el tráfico.
    • PROJECT_2: Es el nombre del proyecto que recibe el tráfico.
    • SUBJECT_LABEL_KEY: Es la clave de la etiqueta que se usa para seleccionar las cargas de trabajo de origen. Por ejemplo, app, tier o role.
    • SUBJECT_LABEL_VALUE: Es el valor asociado con el 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: Es la clave de la etiqueta que se usa para seleccionar las cargas de trabajo de destino.
    • TARGET_LABEL_VALUE: Es el valor asociado con el TARGET_LABEL_KEY. Especifica qué cargas de trabajo son el destino del tráfico permitido.

Crea una política entre proyectos a nivel de la carga de trabajo de una sola zona

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

Crea una política entre proyectos a nivel de la carga de trabajo de entrada de una sola zona

  1. Para crear una política entre proyectos a nivel de la 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
    

    Reemplaza lo siguiente:

    • GLOBAL_API_SERVER: Es la ruta de acceso de kubeconfig del servidor de la API global. Para obtener más información, consulta Servidores de API globales y zonales. Si aún no generaste un archivo kubeconfig para el servidor de la API, consulta Acceder para obtener más detalles.
    • PROJECT_1: Es el nombre del proyecto que recibe el tráfico.
    • PROJECT_2: Es el nombre del proyecto desde el que proviene el tráfico.
    • SUBJECT_LABEL_KEY: Es la clave de la etiqueta que se usa para seleccionar las cargas de trabajo de origen. Por ejemplo, app, tier o role.
    • SUBJECT_LABEL_VALUE: Es el valor asociado con el 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: Es la clave de la etiqueta que se usa para seleccionar las cargas de trabajo de destino.
    • TARGET_LABEL_VALUE: Es el valor asociado con el TARGET_LABEL_KEY. Especifica qué cargas de trabajo son el destino del tráfico permitido.
    • ZONE_SUBJECT_LABEL_KEY: Es la clave de la etiqueta que se usa para seleccionar la zona de origen. Por ejemplo, zone o region.
    • ZONE_SUBJECT_LABEL_VALUE: Es el valor asociado con el 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: Es la clave de la etiqueta que se usa para seleccionar la zona de destino.
    • ZONE_TARGET_LABEL_VALUE: Es el valor asociado con el ZONE_TARGET_LABEL_KEY. Especifica qué zona es el destino del tráfico permitido.

Crea una política entre proyectos a nivel de la carga de trabajo de salida de una sola zona

  • Para crear una política entre proyectos a nivel de la carga de trabajo de salida 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
    

    Reemplaza lo siguiente:

    • GLOBAL_API_SERVER: Es la ruta de acceso de kubeconfig del servidor de la API global. Para obtener más información, consulta Servidores de API globales y zonales. Si aún no generaste un archivo kubeconfig para el servidor de la API, consulta Acceder para obtener más detalles.
    • PROJECT_1: Es el nombre del proyecto que envía el tráfico.
    • PROJECT_2: Es el nombre del proyecto que recibe el tráfico.
    • SUBJECT_LABEL_KEY: Es la clave de la etiqueta que se usa para seleccionar las cargas de trabajo de origen. Por ejemplo, app, tier o role.
    • SUBJECT_LABEL_VALUE: Es el valor asociado con el 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: Es la clave de la etiqueta que se usa para seleccionar las cargas de trabajo de destino.
    • TARGET_LABEL_VALUE: Es el valor asociado con el TARGET_LABEL_KEY. Especifica qué cargas de trabajo son el destino del tráfico permitido.
    • ZONE_SUBJECT_LABEL_KEY: Es la clave de la etiqueta que se usa para seleccionar la zona de origen. Por ejemplo, zone o region.
    • ZONE_SUBJECT_LABEL_VALUE: Es el valor asociado con el 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: Es la clave de la etiqueta que se usa para seleccionar la zona de destino.
    • ZONE_TARGET_LABEL_VALUE: Es el valor asociado con el ZONE_TARGET_LABEL_KEY. Especifica qué zona es el destino del tráfico permitido.