Esempio di migrazione delle reti VPC in perimetri separati

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 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 del perimetro di un progetto host di esempio 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.

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 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 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 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 subisca interruzioni durante la migrazione.

Il processo di migrazione prevede i seguenti passaggi:

• Recupero delle reti VPC e dei dettagli del perimetro
• Imposta una configurazione del perimetro di prova
• Verificare la configurazione di prova
• Forza la configurazione di prova

Recupero delle reti VPC e dei dettagli del perimetro

In questo esempio, prima di avviare 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-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
  

Recupera 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 del criterio di accesso> viene utilizzato nei comandi di esempio in 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>
  

Imposta una configurazione di prova

In questo esempio, utilizzerai il comando di prova per aggiornare il perimetro perimeter-1 al fine di 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.

Aggiorna la configurazione di prova

Il seguente comando aggiorna il perimetro perimeter-1 per rimuovere network-host-project, 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à di prova

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

In questo esempio, esegui i comandi seguenti per assicurarti che non ci siano errori di prova 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 questo comando:

    gsutil ls -p service-project-1
  

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

    gsutil ls -p service-project-2
  

I comandi vengono eseguiti correttamente perché la configurazione di prova non influisce sul traffico di produzione. Tuttavia, il seguente errore di prova viene visualizzato negli audit log di network-host-project 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 e le richieste da VM2 a service-project-1 presentano il seguente errore di prova 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>"
    }
    ]
  

Forza la configurazione di prova

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

Nota: quando applichi una configurazione di prova, vengono applicate tutte le configurazioni di prova all'interno del criterio di accesso. Assicurati che le configurazioni di prova di tutti i perimetri nel criterio di accesso siano coerenti con le configurazioni applicate.

Per applicare le configurazioni di prova, esegui questo comando:

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

Dopo aver applicato le configurazioni di prova, 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