Exemplo de migração de redes VPC para 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 inclui 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 inclui 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:

• Perimeter-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.
• Perimeter-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 teste e verificadas antes de aplicar a configuração. 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 envolve as etapas a seguir:

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

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 extrai 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 do modo de teste. 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 teste

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

Se quiser adicionar um projeto a um perímetro em uma política de acesso diferente, primeiro remova o projeto dos perímetros na política de acesso atual. Para saber como remover um projeto de um perímetro, consulte Atualizar um perímetro de serviço.

Atualizar a configuração de teste

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

O comando a seguir cria o perímetro perimeter-2 e adiciona service-project-2 e 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 a configuração de teste

Neste exemplo, execute os seguintes comandos para garantir que não haja erros de teste 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 teste não afeta o tráfego de produção. No entanto, o seguinte erro de teste 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 teste, e as solicitações de VM2 para service-project-1 apresentam o seguinte erro 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 teste

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

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

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

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

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

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

Este exemplo gera 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 gera 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