Esempio di migrazione delle reti VPC in perimetri distinti

Questo esempio mostra come eseguire la migrazione delle reti VPC di un già inserito in un perimetro di servizio, in perimetri separati.

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

Il seguente diagramma mostra la configurazione perimetrale 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 VPC VPC1 e VPC2.
  • Progetti di servizio. 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 host di progetti e servizi. 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 perimetrale del progetto host durante 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 a Cloud Storage bucket Cloud Storage in service-project-1, ma non possono accedere al bucket Cloud Storage a 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 a Cloud Storage bucket Cloud Storage in service-project-2, ma non possono accedere al bucket Cloud Storage a 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 simulata
  • Applica la configurazione dry run

Ottieni i dettagli delle reti VPC e del perimetro

In questo esempio, prima di avviare la migrazione, devi ottenere l'elenco di reti e del perimetro.

Elenca le reti VPC nel progetto host

Il comando seguente 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>

<numero criterio di accesso> utilizzata nei comandi di esempio della modalità dry run. Puoi anche configurare un criterio di accesso predefinito con il seguente comando:

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

Imposta 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. Poi esegui il comando dry-run per creare un nuovo perimetro perimeter-2 e aggiungere service-project-2 e VPC2.

Aggiorna la configurazione di prova

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>

Crea un nuovo perimetro in modalità dry run

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

Verificare la configurazione della prova

In questo esempio, esegui questi comandi per assicurarti che non ci siano errori di prova dalle ore VPC1 alle ore service-project-1 e dalle ore VPC2 alle ore service-project-2:

Per elencare i bucket Cloud Storage in service-project-1, accedi a VM1, che si trova in VPC1 ed esegui questo 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, il seguente errore di prova viene visualizzato negli audit log per network-host-project per accedere 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>"
    }
    ]

Applica la configurazione dry run

Devi applicare tutte le configurazioni di prova contemporaneamente in una 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 dry run, esegui questo 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