Exemplo de migração de redes VPC em perímetros separados

Este exemplo mostra como migrar redes VPC de um projeto host, que já está em um perímetro de serviço, para perímetros separados.

Neste exemplo, o projeto host consiste em duas redes VPC. Dois projetos de serviço hospedam os recursos do Cloud Storage.

O diagrama a seguir mostra a configuração de perímetro de um projeto host de exemplo antes da migração:

O diagrama da arquitetura mostra os seguintes componentes:

• Projeto host. O projeto host contém duas redes VPC VPC1 e VPC2.
• Projetos de serviço. Os projetos de serviço service-project-1 e service-project-2 contêm buckets do Cloud Storage e são protegidos pelo perímetro de serviço.
• Perímetro. O perímetro de serviço perimeter-1 protege todo o projeto host e os projetos de serviço. A VM VM1 na rede VPC VPC1 e a VM VM2 na rede VPC VPC2 podem acessar recursos em service-project-1 e service-project-2.

No diagrama a seguir, mostramos a configuração do perímetro do projeto host após a migração.

O diagrama da arquitetura mostra os seguintes componentes:

• Perímetro-1. Esse perímetro protege a rede VPC VPC1 e o projeto de serviço service-project-1. A VM VM1 pode acessar o bucket do Cloud Storage em service-project-1, mas não o bucket em service-project-2.
• Perímetro-2. Esse perímetro protege a rede VPC VPC2 e o projeto de serviço service-project-2. A VM VM2 pode acessar o bucket do Cloud Storage em service-project-2, mas não o bucket em service-project-1.

Neste exemplo de migração, as mudanças de configuração são feitas no modo de simulação e verificadas antes de a configuração ser aplicada. Esse processo garante que as redes e os recursos da VPC sejam protegidos e que o tráfego de produção de VPC1 para service-project-1 e de VPC2 para service-project-2 não seja interrompido durante a migração.

O processo consiste nas etapas a seguir.

• Acessar as redes VPC e os detalhes do perímetro
• Definir uma configuração de perímetro de simulação
• Verificar a configuração de simulação
• Aplicar a configuração de simulação

Acessar as redes VPC e os detalhes do perímetro

Neste exemplo, antes de iniciar a migração, você precisa ver a lista de redes VPC e detalhes do perímetro.

Listar as redes VPC no projeto host

O comando a seguir lista as redes VPC no network-host-project:

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

Este exemplo produz a saída a seguir:

    NAME  SUBNET_MODE  BGP_ROUTING_MODE  IPV4_RANGE  GATEWAY_IPV4
    vpc1  AUTO         REGIONAL
    vpc2  AUTO         REGIONAL
  

Acessar os detalhes do perímetro

O comando a seguir recebe os detalhes do perímetro:

    gcloud access-context-manager perimeters describe perimeter-1
  

Este exemplo produz a saída a seguir:

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>

O <número da política de acesso> é usado nos comandos de modo de simulação. Também é possível configurar uma política de acesso padrão com o seguinte comando:

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

Definir uma configuração de simulação

Neste exemplo, use o comando de simulação para atualizar o perímetro perimeter-1 para remover network-host-project, service-project-2 e adicionar VPC1. Em seguida, execute o comando de simulação para criar um novo perímetro perimeter-2 e adicionar service-project-2 e VPC2.

Atualizar a configuração de simulação

O comando a seguir atualiza o perímetro perimeter-1 para remover network-host-project, service-project-2 e adiciona 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>
  

Criar um novo perímetro no modo de simulação

O comando a seguir cria o perímetro perimeter-2 e adiciona service-project-2 e VPC1:

    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 a configuração de simulação

Neste exemplo, execute os seguintes comandos para garantir que não haja erros de simulação de VPC1 a service-project-1 e de VPC2 a service-project-2:

Para listar os buckets do Cloud Storage em service-project-1, faça login em VM1, que está em VPC1 e execute o seguinte comando:

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

Para listar os buckets do Cloud Storage em service-project-2, execute o seguinte comando:

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

Os comandos são executados com êxito porque a configuração de simulação não afeta o tráfego de produção. No entanto, o seguinte erro de simulação aparece nos registros de auditoria de network-host-project para acessar service-project-2 em 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>"
    }
    ]
  

Da mesma forma, as solicitações do Cloud Storage de VM2 para service-project-2 não têm erros de simulação, e as solicitações de VM2 para service-project-1 têm o seguinte erro de simulação nos registros de auditoria do 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 a configuração de simulação

É preciso aplicar todas as configurações de simulação de uma só vez em uma transação atômica.

Observação: ao aplicar uma configuração de simulação, todas as configurações de simulação na política de acesso serão aplicadas. Verifique se as configurações de simulação de todos os perímetros na política de acesso são consistentes com as configurações aplicadas.

Para aplicar as configurações de simulação, execute o seguinte comando:

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

Depois de aplicar as configurações de simulação, execute o seguinte comando para descrever perimeter-1:

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

Este exemplo produz a seguinte saída, em que network-host-project e service-project-2 são removidos e VPC1 é adicionado 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
  

Execute o seguinte comando para descrever perimeter-2:

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

Este exemplo produz o seguinte resultado em que service-project-2 e VPC2 são adicionados 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