Ejemplo de migración de redes de VPC a perímetros independientes

En este ejemplo se muestra cómo migrar redes de VPC de un proyecto host que ya está en un perímetro de servicio a perímetros independientes.

En este ejemplo, el proyecto host consta de dos redes de VPC. Dos proyectos de servicio alojan sus recursos de Cloud Storage.

En el siguiente diagrama se muestra la configuración del perímetro de un proyecto host de ejemplo antes de la migración:

En el diagrama de arquitectura se muestran los siguientes componentes:

• Proyecto host. El proyecto host contiene dos redes de VPC: VPC1 y VPC2.
• Proyectos de servicio. Los proyectos de servicio service-project-1 y service-project-2 contienen segmentos de Cloud Storage y están protegidos por el perímetro de servicio.
• Perímetro. El perímetro de servicio perimeter-1 protege todo el proyecto host y los proyectos de servicio. La VM VM1 de la red de VPC VPC1 y la VM VM2 de la red de VPC VPC2 pueden acceder a los recursos de service-project-1 y service-project-2.

En el siguiente diagrama se muestra la configuración del perímetro del proyecto host después de la migración.

En el diagrama de arquitectura se muestran los siguientes componentes:

• Perimeter-1. Este perímetro protege la red de VPC VPC1 y el proyecto de servicio service-project-1. La VM VM1 puede acceder al segmento de Cloud Storage de service-project-1, pero no al de service-project-2.
• Perimeter-2. Este perímetro protege la red de VPC VPC2 y el proyecto de servicio service-project-2. La VM VM2 puede acceder al segmento de Cloud Storage de service-project-2, pero no al de service-project-1.

En este ejemplo de migración, los cambios de configuración se realizan en modo de prueba de funcionamiento y, a continuación, se verifican antes de aplicar la configuración de prueba de funcionamiento. Este proceso asegura que las redes de VPC y los recursos estén protegidos, y que el tráfico de producción de VPC1 a service-project-1 y de VPC2 a service-project-2 no se interrumpa durante la migración.

El proceso de migración consta de los siguientes pasos:

• Obtener los detalles de las redes de VPC y del perímetro
• Configurar un perímetro de prueba
• Verificar la configuración de la prueba
• Aplicar la configuración de prueba de funcionamiento

Obtener los detalles de las redes de VPC y del perímetro

En este ejemplo, antes de iniciar la migración, debes obtener la lista de redes de VPC y los detalles del perímetro.

Lista de redes de VPC del proyecto host

El siguiente comando muestra las redes de VPC del proyecto network-host-project:

    gcloud compute networks list --project=network-host-project
  

Este ejemplo genera el siguiente resultado:

    NAME  SUBNET_MODE  BGP_ROUTING_MODE  IPV4_RANGE  GATEWAY_IPV4
    vpc1  AUTO         REGIONAL
    vpc2  AUTO         REGIONAL
  

Obtener los detalles del perímetro

El siguiente comando obtiene los detalles del perímetro:

    gcloud access-context-manager perimeters describe perimeter-1
  

Este ejemplo genera el siguiente resultado:

name: accessPolicies/<access policy number>/servicePerimeters/perimeter-1
status:
…
  resources:
  - projects/<network-host-project number>
  - projects/<service-project-1 number>
  - projects/<service-project-2 number>

El <access policy number> se usa en los comandos de ejemplo del modo de ejecución de prueba. También puedes configurar una política de acceso predeterminada con el siguiente comando:

    gcloud alpha config set access_context_manager/policy<access policy number>
  

Configurar una prueba de funcionamiento

En este ejemplo, se usa el comando de ejecución de prueba para actualizar el perímetro perimeter-1 para quitar network-host-project y service-project-2, y añadir VPC1. A continuación, ejecuta el comando de prueba para crear un perímetro perimeter-2 y añadir service-project-2 y VPC2.

Si añades un proyecto a un perímetro en una política de acceso diferente, primero debes quitarlo de los perímetros de la política de acceso actual. Para obtener información sobre cómo quitar un proyecto de un perímetro, consulta Actualizar un perímetro de servicio.

Actualizar la configuración de la prueba

El siguiente comando actualiza el perímetro perimeter-1 para quitar network-host-project y service-project-2, y añade VPC1:

    gcloud access-context-manager perimeters dry-run update perimeter-1
     --remove-resources="projects/<network-host-project number>,projects/<service-project-2 number>"
     --add-resources="//compute.googleapis.com/projects/network-host-project/global/networks/vpc1"
     --policy=<access policy number>
  

Crear un perímetro en modo de prueba

El siguiente comando crea el perímetro perimeter-2 y añade service-project-2, y añade VPC2:

    gcloud access-context-manager perimeters dry-run create perimeter-2
    --title=perimeter-2 --type="regular"
    --resources="projects/<service-project-2 number>,//compute.googleapis.com/projects/network-host-project/global/networks/vpc2"
    --restricted-services="storage.googleapis.com"
    --policy=<access policy number>
  

Verificar la configuración de la prueba

En este ejemplo, ejecuta los siguientes comandos para asegurarte de que no hay errores de prueba de funcionamiento de VPC1 a service-project-1 y de VPC2 a service-project-2:

Para ver una lista de los segmentos de Cloud Storage de service-project-1, inicia sesión en VM1, que se encuentra en VPC1 y ejecuta el siguiente comando:

    gcloud storage ls --project=service-project-1
  

Para enumerar los segmentos de Cloud Storage de service-project-2, ejecuta el siguiente comando:

    gcloud storage ls --project=service-project-2
  

Los comandos se ejecutan correctamente porque la configuración de prueba no afecta al tráfico de producción. Sin embargo, en los registros de auditoría de network-host-project aparece el siguiente error de prueba: para acceder a service-project-2 desde VM1:

    egressViolations: [
    0: {
    servicePerimeter: "accessPolicies/<access policy number>/servicePerimeters/perimeter-1"
    source: "//compute.googleapis.com/projects/network-host-project/global/networks/VPC1"
    sourceType: "Network"
    targetResource: "projects/<service-project-2 number>"
    }
    ]
  

Del mismo modo, las solicitudes de Cloud Storage de VM2 a service-project-2 no tienen errores de prueba y las solicitudes de VM2 a service-project-1 tienen el siguiente error de prueba en los registros de auditoría de network-host-project:

    egressViolations: [
    0: {
    servicePerimeter: "accessPolicies/<access policy number>/servicePerimeters/perimeter-2"
    source: "//compute.googleapis.com/projects/network-host-project/global/networks/VPC2"
    sourceType: "Network"
    targetResource: "projects/<service-project-1 number>"
    }
    ]
  

Aplicar la configuración de prueba de funcionamiento

Debes aplicar todas las configuraciones de prueba simultáneamente en una transacción atómica.

Nota: Cuando implementas una configuración de prueba, se implementan todas las configuraciones de prueba de la política de acceso. Asegúrate de que las configuraciones de prueba de todos los perímetros de la política de acceso sean coherentes con las configuraciones aplicadas.

Para aplicar las configuraciones de ejecución de prueba, ejecuta el siguiente comando:

    gcloud access-context-manager perimeters dry-run enforce-all --policy=<access policy number>
  

Después de aplicar las configuraciones de prueba de funcionamiento, ejecuta el siguiente comando para describir perimeter-1:

    gcloud access-context-manager perimeters describe perimeter-1 --policy=<access policy number>
  

En este ejemplo se genera el siguiente resultado, en el que se quitan network-host-project y service-project-2 y se añade VPC1 a perimeter-1.

    name: accessPolicies/<access policy number>/servicePerimeters/perimeter-1
    status:
    …
    resources:
    - projects/<service-project-1 number>
    - //compute.googleapis.com/projects/<network-host-project>/global/networks/VPC1
  

Ejecuta el siguiente comando para describir perimeter-2:

    gcloud access-context-manager perimeters describe perimeter-2 --policy=<access policy number>
  

En este ejemplo se genera el siguiente resultado, en el que se añaden service-project-2 y VPC2 a perimeter-2.

    name: accessPolicies/<access policy number>/servicePerimeters/perimeter-2
    status:
    …
    resources:
    - projects/<service-project-2 number>
    - //compute.googleapis.com/projects/<network-host-project>/global/networks/VPC2
    title: perimeter-2