Cette page a été traduite par l'API Cloud Translation.

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

Cet exemple montre comment migrer les réseaux VPC d'une qui se trouve déjà dans un périmètre de service, en 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:

Héberger le projet 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.
Perimètre Le périmètre de service perimeter-1 protège l'ensemble de l'hôte de projet et de service. La VM VM1 dans le réseau VPC VPC1 et la VM VM2 du réseau VPC VPC2 peut accéder aux ressources du réseau VPC service-project-1 et 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 d'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 à l'instance Cloud Storage bucket dans service-project-1, mais ne peut pas accéder au bucket Cloud Storage dans le pays suivant : 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 pas au bucket Cloud Storage dans service-project-1.

Dans cet exemple de migration, les modifications de configuration sont effectuées en mode simulation, puis validé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 à 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 la 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 et les détails d'un périmètre.

Lister les réseaux VPC du projet hôte

La commande suivante liste les réseaux VPC du 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 en mode dry run. Vous pouvez également configurer une règle d'accès par défaut à l'aide de la commande suivante:

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

Configurer une configuration de simulation

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

Mettre à jour la configuration de simulation

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

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

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

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

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

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

Les commandes s'exécutent correctement, car la configuration de simulation n'affecte pas l'environnement de production du trafic. Toutefois, l'erreur de dry run suivante apparaît dans les journaux d'audit pour network-host-project pour accéder à service-project-2 depuis 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 n'ont pas d'erreurs de simulation, et les requêtes de VM2 à service-project-1 présentent l'erreur de dry run 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 une seule fois dans une 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 la sortie suivante, dans laquelle 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