Esempio di migrazione delle reti VPC in perimetri separati

Questo esempio mostra come eseguire la migrazione delle reti VPC di un progetto host esistente (e già presente 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 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 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 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 che 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:

  • Perimetro 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.
  • Perimetro 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à dry run e poi verificate prima di applicare la configurazione dry run. Questo processo garantisce che le reti e le risorse 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.

Ecco cosa devi fare nel processo di migrazione:

  • Recupera i dettagli delle reti VPC e del perimetro
  • Crea una configurazione del perimetro in modalità dry run
  • Verifica la configurazione dry run
  • Applica la configurazione dry run

Recupera i dettagli delle reti VPC e del perimetro

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

Elenca le reti VPC nel progetto host

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

    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>

<access policy number> viene utilizzato nei comandi di modalità dry run di esempio. Puoi anche configurare una policy di accesso predefinita con il seguente comando:

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

Crea una configurazione dry run

In questo esempio, devi usare il comando dry run per aggiornare il perimetro perimeter-1 per rimuovere network-host-project e 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.

Se aggiungi un progetto a un perimetro in una policy di accesso diversa, devi prima rimuovere il progetto dai perimetri nella policy di accesso esistente. Per informazioni su come rimuovere un progetto da un perimetro, vedi Aggiorna un perimetro di servizio.

Aggiorna la configurazione dry run

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

In questo esempio, esegui i comandi in basso per assicurarti che non ci siano errori di dry run 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, ed esegui il comando seguente:

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

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

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

I comandi vengono eseguiti correttamente perché la configurazione dry run non influisce sul traffico di produzione. Tuttavia, negli audit log per network-host-project viene visualizzato il seguente errore di dry run 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 Cloud Storage da VM2 a service-project-2 non generano errori di dry run, mentre le richieste da VM2 a service-project-1 generano il seguente errore di dry run negli audit log 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 dry run contemporaneamente in un'unica transazione atomica.

Per applicare le configurazioni dry run, esegui questo 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 questo 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