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:
Le schéma d'architecture présente les composants suivants:
- Projet hôte Le projet hôte contient deux réseaux VPC
VPC1etVPC2. - Projets de service Les projets de service
service-project-1etservice-project-2contiennent 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-1protège l'ensemble du projet hôte et des projets de service. La VMVM1du réseau VPCVPC1et la VMVM2du réseau VPCVPC2peuvent accéder aux ressources deservice-project-1et deservice-project-2.
Le schéma suivant illustre la configuration du périmètre du 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
VPC1et le projet de serviceservice-project-1. La VMVM1peut accéder au bucket Cloud Storage dansservice-project-1, mais pas au bucket Cloud Storage dansservice-project-2. - Perimeter-2. Ce périmètre protège le réseau VPC
VPC2et le projet de serviceservice-project-2. La VMVM2peut accéder au bucket Cloud Storage dansservice-project-2, mais pas au bucket Cloud Storage dansservice-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
- Configurer une configuration de simulation de périmètre
- Vérifier la configuration du test
- 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 les détails du périmètre.
Répertoriez 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 de simulation. 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 afin de supprimer network-host-project et service-project-2, et d'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.
Si vous ajoutez un projet à un périmètre dans une autre règle d'accès, vous devez d'abord le supprimer des périmètres de la règle d'accès existante. Pour savoir comment supprimer un projet d'un périmètre, consultez la section Mettre à jour un périmètre de service.
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 simulation
La commande suivante crée le périmètre perimeter-2, ajoute service-project-2 et ajoute 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 de l'exécution à blanc
Dans cet exemple, exécutez les commandes suivantes pour vous assurer qu'aucune erreur de simulation ne se produit entre VPC1 et service-project-1, et entre VPC2 et service-project-2:
Pour lister les buckets Cloud Storage dans service-project-1, connectez-vous à VM1, qui se trouve dans VPC1, puis 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 de simulation n'affecte pas le trafic de production. Toutefois, l'erreur de simulation suivante apparaît dans les journaux d'audit pour network-host-project pour accéder à 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 simulation, et les requêtes de VM2 à service-project-1 comportent l'erreur de simulation suivante dans les journaux d'audit pour le 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 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