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

En este ejemplo, se muestra cómo puedes migrar las 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 host de ejemplo antes de la migración:

Proyecto host antes de la migración

En el diagrama, 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 buckets de Cloud Storage y están protegidos por el perímetro de servicio.
  • Perímetro de servicio. 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.

Proyecto host después de la migración

En el diagrama, 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 puede acceder al bucket de Cloud Storage en service-project-2.
  • Perímetro-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 puede acceder 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 las redes y los recursos 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 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
  • Programar la configuración del perímetro de ejecución de prueba
  • Verificar la configuración de la ejecución de prueba
  • Aplicar la configuración de ejecución de prueba

Obtén los detalles de las redes de VPC y del perímetro

En este ejemplo, antes de comenzar 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 la 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

Con el siguiente comando, se obtienen 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 modo de ejecución de prueba de ejemplo. 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 ejecución de prueba

En este ejemplo, usarás el comando de ejecución de prueba para actualizar el perímetro perimeter-1 y quitar network-host-project y service-project-2, y agregar VPC1. Luego, ejecuta el comando de ejecución de prueba para crear un perímetro nuevo 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 quitar el proyecto 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 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

Con el siguiente comando, se crea el perímetro perimeter-2 y se agregan 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 ejecución de prueba

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

Para enumerar 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 enumerar 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, en los registros de auditoría de network-host-project para acceder a service-project-2 desde VM1, aparece el siguiente error de ejecución de prueba:

    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 ejecución de prueba, y las solicitudes de VM2 a service-project-1 tienen el siguiente error de ejecución de prueba en los registros de auditoría para 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 ejecución de prueba

Debes aplicar todos los parámetros de configuración de la ejecución de prueba al mismo tiempo, en una única transacción atómica.

Para aplicar la configuración 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 la configuración de 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