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

Cet exemple montre comment migrer les 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 se compose de deux réseaux VPC. Deux projets de service hébergent leurs ressources Cloud Storage.

Le schéma suivant montre 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 d'architecture montre 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 du réseau VPC VPC1 et la VM VM2 du 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 d'architecture montre les composants suivants :

  • Périmètre-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 pas à celui dans service-project-2.
  • Périmètre-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 à celui dans service-project-1.

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

Ce processus de migration 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 dry run
  • Vérifier la configuration dry run
  • Appliquer la configuration dry run

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 les détails du périmètre.

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

La commande suivante liste les réseaux VPC dans le projet hôte de réseau :

    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 stratégie d'accès> est utilisé dans les exemples de commandes en mode dry run. Vous pouvez également définir 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>

Définir une configuration dry run

Dans cet exemple, vous utilisez la commande dry run 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 dry run pour créer un périmètre perimeter-2 et ajouter service-project-2 et VPC2.

Si vous ajoutez un projet à un périmètre dans une autre règle d'accès, vous devez d'abord supprimer le projet des périmètres de la règle d'accès existante. Pour savoir comment supprimer un projet d'un périmètre, consultez Mettre à jour un périmètre de service.

Mettre à jour la configuration dry run

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 dry run

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

Vérifier la configuration dry run

Dans cet exemple, exécutez les commandes suivantes pour vous assurer qu'aucune erreur dry run ne se produit depuis VPC1 vers service-project-1, et depuis VPC2 vers service-project-2 :

Pour lister les buckets Cloud Storage dans 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 lister 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 dry run n'affecte pas le trafic de production. Toutefois, l'erreur dry run suivante s'affiche dans les journaux d'audit pour network-host-project lors de l'accès à 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 depuis VM2 vers service-project-2 ne comportent pas d'erreurs dry run, et les requêtes depuis VM2 vers service-project-1 comportent l'erreur 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 dry run

Vous devez appliquer toutes les configurations dry run en une seule transaction atomique.

Pour appliquer les configurations dry run, exécutez la commande suivante :

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

Après avoir appliqué les configurations dry run, 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 la sortie suivante, dans laquelle 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