Exemple de migration de réseaux VPC dans des périmètres distincts

Cet exemple montre comment migrer des réseaux VPC d'un projet hôte existant, qui se trouve déjà dans un périmètre de service, vers des périmètres distincts.

Dans cet exemple, le projet hôte est constitué de deux réseaux VPC. Deux projets de service hébergent leurs ressources Cloud Storage.

Le schéma suivant illustre la configuration du périmètre d'un exemple de projet hôte avant la migration:

Projet hôte avant la migration

Le schéma de l'architecture présente les composants suivants:

  • Projet hôte : Le projet hôte contient deux réseaux VPC VPC1 et VPC2.
  • Projets de service : Les projets de service service-project-1 et service-project-2 contiennent des buckets Cloud Storage et sont protégés par le périmètre de service.
  • Périmètre : Le périmètre de service perimeter-1 protège l'ensemble du projet hôte et des projets de service. La VM VM1 dans le réseau VPC VPC1 et la VM VM2 dans le réseau VPC VPC2 peuvent accéder aux ressources de service-project-1 et de service-project-2.

Le schéma suivant illustre la configuration du périmètre du projet hôte après la migration.

Projet hôte après la migration

Le schéma de l'architecture présente les composants suivants:

  • Perimeter-1 : Ce périmètre protège le réseau VPC VPC1 et le projet de service service-project-1. La VM VM1 peut accéder au bucket Cloud Storage dans service-project-1, mais ne peut pas accéder au bucket Cloud Storage dans service-project-2.
  • Perimeter-2 : Ce périmètre protège le réseau VPC VPC2 et le projet de service service-project-2. La VM VM2 peut accéder au bucket Cloud Storage dans service-project-2, mais ne peut pas accéder au bucket Cloud Storage dans service-project-1.

Dans cet exemple de migration, les modifications de configuration sont effectuées en mode de simulation, puis vérifiées avant d'appliquer la configuration de simulation. Ce processus garantit que les réseaux et les ressources VPC sont protégés, et que le trafic de production de VPC1 vers service-project-1 et de VPC2 à service-project-2 n'est pas interrompu pendant la migration.

Ce processus comprend les étapes suivantes :

  • Obtenir les détails des réseaux VPC et du périmètre
  • Définir une configuration de périmètre de simulation
  • Vérifier la configuration de simulation
  • Appliquer la configuration de simulation

Obtenir les détails des réseaux VPC et du périmètre

Dans cet exemple, avant de commencer la migration, vous devez obtenir la liste des réseaux VPC et des détails du périmètre.

Lister les réseaux VPC dans le projet hôte

La commande suivante répertorie les réseaux VPC dans le projet "network-host-project" :

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

Cet exemple génère la sortie suivante :

    NAME  SUBNET_MODE  BGP_ROUTING_MODE  IPV4_RANGE  GATEWAY_IPV4
    vpc1  AUTO         REGIONAL
    vpc2  AUTO         REGIONAL
  

Obtenir les détails du périmètre

La commande suivante permet d'obtenir les détails du périmètre:

    gcloud access-context-manager perimeters describe perimeter-1
  

Cet exemple génère la sortie suivante :

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>

Le <numéro de règle d'accès> est utilisé dans les exemples de commandes du mode de simulation. Vous pouvez également configurer une stratégie d'accès par défaut à l'aide de la commande suivante:

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

Définir une configuration de simulation

Dans cet exemple, vous utilisez la commande de simulation pour mettre à jour le périmètre perimeter-1 afin de supprimer network-host-project et service-project-2, et d'ajouter VPC1. Ensuite, exécutez la commande de simulation pour créer un périmètre perimeter-2, puis ajouter service-project-2 et VPC2.

Mettre à jour la configuration de dry run

La commande suivante met à jour le périmètre perimeter-1 pour supprimer network-host-project et service-project-2, puis ajoute 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>
  

Créer un périmètre en mode de simulation

La commande suivante crée le périmètre perimeter-2, et ajoute service-project-2 et 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>
  

Vérifier la configuration de simulation

Dans cet exemple, exécutez les commandes suivantes pour vous assurer qu'il n'y a pas d'erreurs de dry run entre VPC1 et service-project-1, et VPC2 vers service-project-2:

Pour répertorier les buckets Cloud Storage dans service-project-1, connectez-vous à VM1, qui se trouve dans VPC1, puis exécutez la commande suivante:

    gsutil ls -p service-project-1
  

Pour répertorier les buckets Cloud Storage dans service-project-2, exécutez la commande suivante:

    gsutil ls -p service-project-2
  

Les commandes s'exécutent correctement, car la configuration de simulation n'affecte pas le trafic de production. Toutefois, l'erreur de dry run suivante apparaît dans les journaux d'audit pour network-host-project pour l'accès à service-project-2 à partir de 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>"
    }
    ]
  

De même, les requêtes Cloud Storage de VM2 à service-project-2 ne comportent pas d'erreurs de dry run, et les requêtes de VM2 à service-project-1 présentent l'erreur de simulation suivante dans les journaux d'audit pour 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>"
    }
    ]
  

Appliquer la configuration de simulation

Vous devez appliquer toutes les configurations de simulation en même temps dans une même transaction atomique.

Pour appliquer les configurations de simulation, exécutez la commande suivante:

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

Après avoir appliqué les configurations de simulation, exécutez la commande suivante pour décrire perimeter-1:

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

Cet exemple génère le résultat suivant, dans lequel network-host-project et service-project-2 sont supprimés, et VPC1 est ajouté à 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
  

Exécutez la commande suivante pour décrire perimeter-2:

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

Cet exemple génère le résultat suivant, dans lequel service-project-2 et VPC2 sont ajoutés à 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