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

En este ejemplo, se muestra cómo puedes migrar redes de VPC de un proyecto host existente, que ya se encuentra en un perímetro de servicio, a perímetros separados.

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 de 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 depósitos 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 en la red de VPC VPC1 y la VM VM2 en la red de VPC VPC2 pueden acceder a los recursos en 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:

• Perímetro-1. Este perímetro protege la red de VPC VPC1 y el proyecto de servicio service-project-1. La VM VM1 puede acceder al bucket de Cloud Storage en service-project-1, pero no al bucket de Cloud Storage en 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 bucket de Cloud Storage en service-project-2, pero no al bucket de Cloud Storage en service-project-1.

En este ejemplo de migración, los cambios de configuración se realizan en el modo de ejecución de prueba y luego se verifican antes de aplicar la configuración de ejecución de prueba. Este proceso garantiza que los recursos y las redes de VPC 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 interrumpe durante la migración.

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

• Obtén los detalles de las redes de VPC y el perímetro
• Configura una configuración de perímetro de prueba
• Verifica la configuración de la prueba de ejecución
• Aplica la configuración de la ejecución de prueba

Obtén los detalles de las redes de VPC y el 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.

Enumera las redes de VPC en el proyecto host

El siguiente comando enumera las redes de VPC en el proyecto de host de red:

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

En este ejemplo, se produce el siguiente resultado:

    NAME  SUBNET_MODE  BGP_ROUTING_MODE  IPV4_RANGE  GATEWAY_IPV4
    vpc1  AUTO         REGIONAL
    vpc2  AUTO         REGIONAL
  

Obtén los detalles del perímetro

El siguiente comando obtiene los detalles del perímetro:

    gcloud access-context-manager perimeters describe perimeter-1
  

En este ejemplo, se produce 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 <número de política de acceso> 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>
  

Cómo configurar una configuración de ejecución de prueba

En este ejemplo, usas el comando de ejecución de prueba para actualizar el perímetro perimeter-1 para quitar network-host-project, service-project-2 y agregar VPC1. Luego, ejecutas el comando de ejecución de prueba para crear un nuevo perímetro perimeter-2 y agregar service-project-2 y VPC2.

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

Actualiza la configuración de la ejecución de prueba

El siguiente comando actualiza el perímetro perimeter-1 para quitar network-host-project y service-project-2, y agrega 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>
  

Crea un perímetro nuevo en modo de ejecución de prueba

El siguiente comando crea el perímetro perimeter-2 y agrega service-project-2 y 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>
  

Verifica la configuración de la prueba de ejecución

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

Para obtener una lista de los buckets de Cloud Storage en service-project-1, accede a VM1, que se encuentra en VPC1, y ejecuta el siguiente comando:

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

Para obtener una lista de los buckets de Cloud Storage en service-project-2, ejecuta el siguiente comando:

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

Los comandos se ejecutan correctamente porque la configuración de ejecución de prueba no afecta el tráfico de producción. Sin embargo, el siguiente error de ejecución de prueba aparece en los registros de auditoría de network-host-project 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 sin conexión, y las solicitudes de VM2 a service-project-1 tienen el siguiente error de prueba sin conexión 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>"
    }
    ]
  

Aplica la configuración de la ejecución de prueba

Debes aplicar todas las configuraciones de la ejecución de prueba a la vez en una transacción atómica.

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

Para aplicar las configuraciones 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 la ejecución de prueba, ejecuta el siguiente comando para describir perimeter-1:

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

En este ejemplo, se produce el siguiente resultado en el que se quitan network-host-project y service-project-2, y se agrega 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 produce el siguiente resultado en el que se agregan 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