Esempio di migrazione delle reti VPC in perimetri distinti

Questo esempio mostra come eseguire la migrazione delle reti VPC di un progetto host esistente, che si trova già in un perimetro di servizio, in perimetri distinti.

In questo esempio, il progetto host è costituito da due reti VPC. Due progetti di servizio ospitano le risorse Cloud Storage.

Il seguente diagramma mostra la configurazione del perimetro di un progetto host di esempio prima della migrazione:

Progetto host prima della migrazione

Il diagramma dell'architettura mostra i seguenti componenti:

  • Progetto host. Il progetto host contiene due reti VPCVPC1 e VPC2.
  • Progetti di servizi. I progetti di servizio service-project-1 e service-project-2 contengono bucket Cloud Storage e sono protetti dal perimetro di servizio.
  • Perimetro. Il perimetro di servizio perimeter-1 protegge l'intero progetto host e i progetti di servizio. La VM VM1 nella rete VPC VPC1 e la VM VM2 nella rete VPC VPC2 possono accedere alle risorse sia in service-project-1 sia in service-project-2.

Il seguente diagramma mostra la configurazione del perimetro del progetto host dopo la migrazione.

Progetto host dopo la migrazione

Il diagramma dell'architettura mostra i seguenti componenti:

  • Perimeter-1. Questo perimetro protegge la rete VPC VPC1 e il progetto di servizio service-project-1. La VM VM1 può accedere al bucket Cloud Storage in service-project-1, ma non può accedere al bucket Cloud Storage in service-project-2.
  • Perimeter-2. Questo perimetro protegge la rete VPC VPC2 e il progetto di servizio service-project-2. La VM VM2 può accedere al bucket Cloud Storage in service-project-2, ma non può accedere al bucket Cloud Storage in service-project-1.

In questo esempio di migrazione, le modifiche alla configurazione vengono apportate in modalità di prova e poi verificate prima di applicare la configurazione di prova. Questo processo garantisce che le risorse e le reti VPC siano protette e che il traffico di produzione da VPC1 a service-project-1 e da VPC2 a service-project-2 non venga interrotto durante la migrazione.

La procedura di migrazione prevede i seguenti passaggi:

  • Ottieni i dettagli delle reti VPC e del perimetro
  • Configurare una configurazione del perimetro di prova
  • Verifica la configurazione della prova secca
  • Applicare la configurazione di prova

Ottieni i dettagli delle reti VPC e del perimetro

In questo esempio, prima di iniziare la migrazione, devi ottenere l'elenco delle reti VPC e i dettagli del perimetro.

Elenca le reti VPC nel progetto host

Il seguente comando elenca le reti VPC nel progetto network-host:

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

Questo esempio produce il seguente output:

    NAME  SUBNET_MODE  BGP_ROUTING_MODE  IPV4_RANGE  GATEWAY_IPV4
    vpc1  AUTO         REGIONAL
    vpc2  AUTO         REGIONAL

Visualizza i dettagli del perimetro

Il seguente comando recupera i dettagli del perimetro:

    gcloud access-context-manager perimeters describe perimeter-1

Questo esempio produce il seguente output:

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>

Il <numero criterio di accesso> viene utilizzato nei comandi di esempio della modalità di prova. Puoi anche configurare un criterio di accesso predefinito con il seguente comando:

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

Configurare una configurazione di prova

In questo esempio, utilizzi il comando di prova per aggiornare il perimetro perimeter-1 per rimuovere network-host-project, service-project-2 e aggiungere VPC1. Quindi, esegui il comando di prova per creare un nuovo perimetro perimeter-2 e aggiungi service-project-2 e VPC2.

Se aggiungi un progetto a un perimetro in un criterio di accesso diverso, devi prima rimuovere il progetto dai perimetri nel criterio di accesso esistente. Per informazioni su come rimuovere un progetto da un perimetro, consulta Aggiornare un perimetro di servizio.

Aggiorna la configurazione del dry run

Il seguente comando aggiorna il perimetro perimeter-1 per rimuovere network-host-project, service-project-2 e aggiungere 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>

Creare un nuovo perimetro in modalità di prova

Il comando seguente crea il perimetro perimeter-2 e aggiunge 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>

Verifica la configurazione del dry run

In questo esempio, esegui i seguenti comandi per assicurarti che non ci siano errori di prova simulata da VPC1 a service-project-1 e da VPC2 a service-project-2:

Per elencare i bucket Cloud Storage in service-project-1, accedi a VM1, che si trova in VPC1 esegui il seguente comando:

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

Per elencare i bucket Cloud Storage in service-project-2, esegui il seguente comando:

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

I comandi vengono eseguiti correttamente perché la configurazione della prova non influisce sul traffico di produzione. Tuttavia, nei log di controllo per network-host-project viene visualizzato il seguente errore di prova secca per l'accesso a service-project-2 da 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>"
    }
    ]

Analogamente, le richieste di Cloud Storage da VM2 a service-project-2 non presentano errori di prova secca, mentre le richieste da VM2 a service-project-1 presentano il seguente errore di prova secca nei log di controllo per 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>"
    }
    ]

Applicare la configurazione di prova

Devi applicare tutte le configurazioni di prova contemporaneamente in una singola transazione atomica.

Per applicare le configurazioni di prova, esegui il seguente comando:

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

Dopo aver applicato le configurazioni di prova, esegui il seguente comando per descrivere perimeter-1:

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

Questo esempio produce il seguente output in cui network-host-project e service-project-2 vengono rimossi e VPC1 viene aggiunto 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

Esegui il seguente comando per descrivere perimeter-2:

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

Questo esempio produce il seguente output in cui service-project-2 e VPC2 vengono aggiunti 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