This example shows how you can migrate VPC networks of an existinghost project, which is already in a service perimeter, into separate perimeters.

In this example, the host project consists of two VPC networks.Two service projects host their Cloud Storage resources.

The following diagram shows the perimeter configuration of an example host projectbefore the migration:

The architecture diagram shows the following components:

• Host project. The host project contains two VPC networksVPC1 andVPC2.
• Service projects. The service projectsservice-project-1 andservice-project-2contain Cloud Storage buckets and are protected by the service perimeter.
• Perimeter. The service perimeterperimeter-1 protects the entire hostproject and service projects. The VMVM1 in VPC networkVPC1and the VMVM2 in VPC networkVPC2 can access resources inbothservice-project-1 andservice-project-2.

The following diagram shows the perimeter configuration of the host project afterthe migration.

The architecture diagram shows the following components:

• Perimeter-1. This perimeter protects the VPC networkVPC1and the service projectservice-project-1. The VMVM1 can access the Cloud Storagebucket inservice-project-1 but cannot access the Cloud Storage bucketinservice-project-2.
• Perimeter-2. This perimeter protects the VPC networkVPC2and the service projectservice-project-2. The VMVM2 can access the Cloud Storagebucket inservice-project-2 but cannot access the Cloud Storage bucketinservice-project-1.

In this migration example, the configuration changes are made in dry-run mode andthen verified before enforcing the dry-run configuration. This process ensures thatthe VPC networks and resources are protected and the production trafficfromVPC1 toservice-project-1 and fromVPC2 toservice-project-2 is notdisrupted during the migration.

The migration process consists of the following steps:

• Get the VPC networks and perimeter details
• Set up a dry-run perimeter configuration
• Verify the dry-run setup
• Enforce the dry-run configuration

Get the VPC networks and perimeter details

In this example, before you start the migration, you must get the list of VPCnetworks and perimeter details.

List the VPC networks in the host project

The following command lists the VPC networks in the network-host-project:

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

This example produces the following output:

    NAME  SUBNET_MODE  BGP_ROUTING_MODE  IPV4_RANGE  GATEWAY_IPV4    vpc1  AUTO         REGIONAL    vpc2  AUTO         REGIONAL

Get the perimeter details

The following command gets the details of the perimeter:

    gcloud access-context-manager perimeters describe perimeter-1

This example produces the following output:

name: accessPolicies/<access policy number>/servicePerimeters/perimeter-1status:…  resources:  - projects/<network-host-project number>  - projects/<service-project-1 number>  - projects/<service-project-2 number>

The <access policy number> is used in the example dry-run mode commands.You can also set up a default access policy with the following command:

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

Set up a dry-run configuration

In this example, you use the dry-run command to update the perimeterperimeter-1to removenetwork-host-project,service-project-2, and addVPC1. Then, yourun the dry-run command to create a new perimeterperimeter-2 and addservice-project-2andVPC2.

If you add a project to a perimeter in a different access policy, you must first removethe project from the perimeters in the existing access policy. For information abouthow to remove a project from a perimeter, seeUpdate a service perimeter.

Update the dry-run configuration

The following command updates the perimeterperimeter-1 to removenetwork-host-project,service-project-2, and addsVPC1:

    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>

Create a new perimeter in dry-run mode

The following command creates the perimeterperimeter-2 and addsservice-project-2,and addsVPC2:

    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>

Verify the dry-run configuration

In this example, run the following commands to ensure that there are no dry-run errorsfromVPC1 toservice-project-1, and fromVPC2 toservice-project-2:

To list the Cloud Storage buckets inservice-project-1, log in toVM1, which is inVPC1and run the following command:

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

To list the Cloud Storage buckets inservice-project-2, run the following command:

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

The commands run successfully because the dry-run configuration doesn't affect productiontraffic. However, the following dry-run error appears in the audit logs fornetwork-host-projectfor accessingservice-project-2 fromVM1:

    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>"    }    ]

Similarly, Cloud Storage requests fromVM2 toservice-project-2 don't have dry-run errors,and requests fromVM2 toservice-project-1 have the following dry-run error inthe audit logs for thenetwork-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>"    }    ]

Enforce the dry-run configuration

You must enforce all dry-run configurations at once in one atomic transaction.

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

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

    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

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

    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