Learn how to set up a service perimeter using VPC Service Controls. Thistutorial uses networking settings such as firewalls,Private Service Connect, and DNS configurations that are necessary touse a VPC Service Controls perimeter effectively. This tutorial thendemonstrates how services are allowed or denied, and how to make granularexceptions for an allowlist of specific services.

Objectives

• Configure a VPC Service Controls perimeter with additionalnetworking controls to mitigate exfiltration paths.
• Allow or deny access to services inside the perimeter from requests thatoriginate from inside the perimeter or outside the perimeter.
• Allow or denyaccess to services outside the perimeter from requests that originatewithin the perimeter.
• Use the Restrict Resource Service Usage organizationpolicy and VPC Service Controls together.

Costs

This tutorial uses the following billable components of Google Cloud:

• Compute Engine
• Cloud Storage
• Private Service Connect

To generate a cost estimate based on your projected usage, use thepricing calculator.

When you finish this tutorial, you can avoid continued billing by deleting theresources you created. For more information, seeClean up.

Before you begin

1. This tutorial requires a project under your organization. Ifyou don't already have a Google Cloud organization, seecreating and managing an organization.

2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   Roles required to select or create a project

   • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
   • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains theresourcemanager.projects.create permission.Learn how to grant roles.
   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   Go to project selector

3. Verify that billing is enabled for your Google Cloud project.

4. Enable the Compute Engine, Access Context Manager, and Cloud DNS APIs.

   Roles required to enable APIs

   To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains theserviceusage.services.enable permission.Learn how to grant roles.

   Enable the APIs

5. In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

6. Make sure that you have the following role or roles on the organization: Access Context Manager Admin, Organization Policy Administrator

   Check for the roles

   1. In the Google Cloud console, go to theIAM page.

      Go to IAM
   2. Select the organization.

   3. In thePrincipal column, find all rows that identify you or a group that you're included in. To learn which groups you're included in, contact your administrator.

   4. For all rows that specify or include you, check theRole column to see whether the list of roles includes the required roles.

   Grant the roles

   1. In the Google Cloud console, go to theIAM page.

      Go to IAM
   2. Select the organization.
   3. Clickperson_addGrant access.

   4. In theNew principals field, enter your user identifier. This is typically the email address for a Google Account.

   5. ClickSelect a role, then search for the role.
   6. To grant additional roles, clickaddAdd another role and add each additional role.
   7. ClickSave.

7. Make sure that you have the following role or roles on the project: Compute Admin, DNS Administrator, IAP-Secured Tunnel User, Service Account User, Service Directory Editor

   Check for the roles

   1. In the Google Cloud console, go to theIAM page.

      Go to IAM
   2. Select the project.

   3. In thePrincipal column, find all rows that identify you or a group that you're included in. To learn which groups you're included in, contact your administrator.

   4. For all rows that specify or include you, check theRole column to see whether the list of roles includes the required roles.

   Grant the roles

   1. In the Google Cloud console, go to theIAM page.

      Go to IAM
   2. Select the project.
   3. Clickperson_addGrant access.

   4. In theNew principals field, enter your user identifier. This is typically the email address for a Google Account.

   5. ClickSelect a role, then search for the role.
   6. To grant additional roles, clickaddAdd another role and add each additional role.
   7. ClickSave.

Set up your VPC Service Controls perimeter

To implement a VPC Service Controls perimeter for a VPC network, you mustimplement networking controls that deny traffic to external services. Thefollowing sections detail the networking configurations you must implement inVPC networks inside your perimeter and an example perimeter configuration.

Prepare your VPC network

In this section, youset up private connectivity to Google APIs and services for your VPC network to mitigate arange of network egress paths to the internet.

1. In Cloud Shell, set variables:

   gcloudconfigsetprojectPROJECT_IDgcloudconfigsetcompute/regionREGIONgcloudconfigsetcompute/zoneZONE

   Replace the following:

   • PROJECT_ID: the project ID for the project where you willcreate resources
   • REGION: a region that's close to your location—for example,us-central1
   • ZONE: a zone that's close to your location—for example,us-central1-a

2. Create a VPC network and a subnet with Private Google Access enabled:

   gcloudcomputenetworkscreaterestricted-vpc--subnet-mode=customgcloudcomputenetworkssubnetscreaterestricted-subnet\--range=10.0.0.0/24\--network=restricted-vpc\--enable-private-ip-google-access

3. Create a Private Service Connect endpoint and aforwarding rule configured to use thevpc-sc bundle:

   gcloudcomputeaddressescreaterestricted-psc-endpoint\--global\--purpose=PRIVATE_SERVICE_CONNECT\--addresses=10.0.1.1\--network=restricted-vpcgcloudcomputeforwarding-rulescreaterestrictedpsc\--global\--network=restricted-vpc\--address=restricted-psc-endpoint\--target-google-apis-bundle=vpc-sc

4. Configure the Cloud DNS server policy to redirect queries for GoogleCloud APIs to your Private Service Connect endpoint:

   gclouddnsmanaged-zonescreaterestricted-dns-zone\--description="Private DNS Zone to map Google API queries to the Private Service Connect endpoint for Google APIs"\--dns-name="googleapis.com."\--networks=restricted-vpc\--visibility=privategclouddnsrecord-setscreategoogleapis.com\--rrdatas=10.0.1.1\--type=A\--ttl=300\--zone=restricted-dns-zonegclouddnsrecord-setscreate*.googleapis.com\--rrdatas="googleapis.com."\--type=CNAME\--ttl=300\--zone=restricted-dns-zone

5. Configure a firewall rule at a low priority to deny all egress traffic:

   gcloudcomputefirewall-rulescreatedeny-all-egress\--priority=65534\--direction=egress\--network=restricted-vpc\--action=DENY\--rules=all\--destination-ranges=0.0.0.0/0

6. Configure a firewall rule at a higher priority to allow traffic toreach the IP address used by your Private Service Connectendpoint:

   gcloudcomputefirewall-rulescreateallow-psc-for-google-apis\--priority=1000\--direction=egress\--network=restricted-vpc\--action=ALLOW\--rules=tcp:443\--destination-ranges=10.0.1.1

   These firewall rules deny egress broadly, before selectively allowing egress tothe Private Service Connect endpoint. This configuration deniesegress traffic tothe default domains that are normally reachable by default with Private Google Access andtheimplied firewall rules.

Create a VPC Service Controls perimeter

In this section, you create a VPC Service Controls perimeter.

Note: Thistutorial implements an enforced perimeter because there are no productionresources inside the perimeter. If you're adding a perimeter to existingproduction projects, we recommend testing withdry run mode before enforcing.

1. In Cloud Shell, create an access policy as a prerequisite tocreate a VPC Service Controls perimeter:

   gcloudaccess-context-managerpoliciescreate\--organization=ORGANIZATION_ID--title"Access policy at organization node"

   The output is similar to the following:

   "Create request issuedWaiting for operation [operations/accessPolicies/123456789/create/123456789] to complete...done."

   There can only be one access policy container at the organization node. If apolicy has already been created in your organization, the output is similar to the following:

   "ALREADY_EXISTS: Policy already exists with parent ContainerKey{containerId=organizations/123456789012, numericId=123456789012}"

   If you see this message, continue to the next step.

2. Create a VPC Service Controls perimeter that restricts theCloud Storage and Compute Engine services.

   exportPOLICY_ID=$(gcloudaccess-context-managerpolicieslist\--organization=ORGANIZATION_ID\--format="value(name)")gcloudaccess-context-managerperimeterscreatedemo_perimeter\--title="demo_perimeter"\--resources=projects/$(gcloudprojectsdescribePROJECT_ID--format="value(projectNumber)")\--restricted-services="storage.googleapis.com,compute.googleapis.com"\--enable-vpc-accessible-services\--policy=$POLICY_ID\--vpc-allowed-services="RESTRICTED-SERVICES"

   Caution: In this tutorial, you restrict only the Compute Engine andCloud Storage services. In a production perimeter, we recommend thatyourestrict all supported services to mitigate a range of exfiltration paths.
   The sample perimeter configures--vpc-allowed-services flag with thealias value RESTRICTED-SERVICES to allow traffic from this VPC to the same set of services you define with the--restricted-services flag.

Verify the services allowed from traffic outside your perimeter

The following sections demonstrate how the VPC Service Controls perimeterallows or denies access to requests made from outside of the perimeter and howyou can selectively allow ingress to services by configuring access levels andingress policies.

To simulate traffic from outside your perimeter, you can run commands inCloud Shell. Cloud Shell is a resource outside your ownproject and perimeter. The perimeter allows or denies requests even though the requests have sufficient Identity and Access Management privileges to succeed.

This tutorial uses the Compute Engine API, Cloud Storage API, andCloud Resource Manager API, but the same concepts apply to other services as well.

Verify that the perimeter denies external traffic to restricted services

In this section, you verify that the perimeter denies external traffic torestricted services.

The previous diagram illustrates how an authorized client is denied access toservices inside the perimeter that you configured as restricted, but the clientis allowed access to services that you did not configure as restricted.

In the following steps, you verify this concept by using Cloud Shell toattempt to create a VM inside your VPC network, which fails dueto the configuration of the VPC Service Controls perimeter.

1. In Cloud Shell, run the following command to create a VMinside your VPC network.

   gcloudcomputeinstancescreatedemo-vm\--machine-type=e2-micro\--subnet=restricted-subnet\--scopes=https://www.googleapis.com/auth/cloud-platform\--no-address

   The output is similar to the following:

   "ERROR: (gcloud.compute.instances.create) Could not fetch resource:- Request is prohibited by organization's policy."

   The request fails because Cloud Shell is outside of your perimeter,and Compute Engine is configured with the--restricted-servicesflag.

2. In Cloud Shell, run the following command to access theResource Manager service, which is not configured in the--restricted-services flag.

   gcloudprojectsdescribePROJECT_ID

   A successful response returns the details of your project. This responsedemonstrates that your perimeter allows external traffic to theCloud Resource Manager API.

   You have demonstrated that the perimeter denies external trafficto services configured in--restricted-services and allows externaltraffic to services not explicitly configured in--restricted-services.

The following sections introduce exception patterns to reach restrictedservices inside the perimeter.

Verify that an access level allows an exception to the perimeter

In this section, you verify that anaccess level allows an exception to the perimeter. An access level is useful when you wantto create an exception for external traffic to access all restricted servicesinside the perimeter and you don't require granular exceptions for each serviceor other attributes.

The previous diagram illustrates how an access level allows an authorized clientto access all the restricted services inside the perimeter.

In the following steps, you verify this concept by creating an access level andthen making a successful request to the Compute Engine service. Thisrequest is allowed even you configured Compute Engine as restricted.

1. From Cloud Shell, create a YAML file that describes theconfiguration of an access level and apply it to your perimeter. Thissample creates an access level for the user identity that you're currentlyusing to run the tutorial.

   exportUSERNAME=$(gcloudconfiglistaccount--format"value(core.account)")cat<<EOF >user_spec.yaml-members:-user:$USERNAMEEOF

   gcloudaccess-context-managerlevelscreatesingle_user_level\--title="single-user access level"\--basic-level-spec=user_spec.yaml\--policy=$POLICY_IDgcloudaccess-context-managerperimetersupdatedemo_perimeter\--add-access-levels=single_user_level\--policy=$POLICY_ID

2. From Cloud Shell, run the following command again to attemptto create a VM:

   gcloudcomputeinstancescreatedemo-vm\--machine-type=e2-micro\--subnet=restricted-subnet\--scopes=https://www.googleapis.com/auth/cloud-platform\--no-address

   This time, the request works. Your perimeter prevents external traffic fromusing the restricted services, but the access level that you configured allowsan exception.

   Note: After you update a service perimeter, it can take some time for thechanges to propagate and take effect. If you receive an unexpected result, waita minute and try again after the perimeter has fully updated.

Verify that an ingress policy allows a granular exception to the perimeter

In this section, you verify that an ingress policy allows a granular exceptionto the perimeter. Compared to the coarse-grained access level, a fine-grainedingress policy can configure additional attributes about the traffic source and allow access to individual services or methods.

The previous diagram illustrates how an ingress policy allows an authorizedclient to access only a specified service inside the perimeter, without allowingaccess to other restricted services.

In the following steps, you verify this concept by replacing the access levelwith an ingress policy that allows an authorized client to access only theCompute Engine service, but does not allow access to other restrictedservices.

1. From the Cloud Shell tab, run the following command to removethe access level.

   gcloudaccess-context-managerperimetersupdatedemo_perimeter\--policy=$POLICY_ID\--clear-access-levels

2. From the Cloud Shell tab, create an ingress policy that allowsyour user identity to ingress to theCompute Engine service only, and apply the policy to your perimeter.

   cat<<EOF >ingress_spec.yaml-ingressFrom:identities:-user:$USERNAMEsources:-accessLevel:'*'ingressTo:operations:-methodSelectors:-method:'*'serviceName:compute.googleapis.comresources:-'*'EOF

   gcloudaccess-context-managerperimetersupdatedemo_perimeter\--set-ingress-policies=ingress_spec.yaml\--policy=$POLICY_ID

3. From the Cloud Shell tab, run the following command to create a Cloud Storage bucket inside the perimeter.

   gcloudstoragebucketscreategs://PROJECT_ID-01

   The output is similar to the following:

   "ERROR: (gcloud.storage.buckets.create) HTTPError 403: Request is prohibited by organization's policy."

   Cloud Shell is a client outside the perimeter, so theVPC Service Controls perimeter blocks Cloud Shell fromcommunicating with restricted services inside the perimeter.

4. From the Cloud Shell tab, run the following command to make arequest to the Compute Engine service inside the perimeter.

   gcloudcomputeinstancesdescribedemo-vm--zone=ZONE

   A successful response returns the details ofdemo-vm. This responsedemonstrates that your perimeter allows external traffic that meets theconditions of your ingress policy to the Compute Engine service.

Verify the services allowed from traffic inside your perimeter

The following sections demonstrate how the VPC Service Controls perimeterallows or denies requests to services from inside the perimeter, and how you canselectively allow egress to external services by egress policies.

To demonstrate the difference between traffic inside and outside the perimeter,the following sections use both Cloud Shell outside the perimeter and aCompute Engine instance you create inside the perimeter. Commands thatyou run from the SSH session on the Compute Engine instance inside theperimeter use the identity of the attached service account, whereas commands runfrom Cloud Shell outside the perimeter use your own identity. Whenfollowing the recommended setup for the tutorial, the perimeter allows or deniesrequests even though the requests have sufficient IAM privileges tosucceed.

This tutorial uses the Compute Engine API, Cloud Storage API, andCloud Resource Manager API, but the same concepts apply to other services as well.

Verify that the perimeter allows internal traffic to restricted services inside the perimeter

In this section, you verify that the perimeter allows traffic from networkendpoints inside your perimeter if the service is also configured inVPC accessible services.

The previous diagram illustrates how a perimeter allows traffic from networkendpoints inside the perimeter to reach restricted services that you alsoconfigured as VPC accessible services. Services that you did not configure asVPC accessible services cannot be reached from network endpoints inside theperimeter.

In the following steps, you verify this concept by establishing an SSHconnection to the Compute Engine instance inside the perimeter, thenmaking requests to services.

1. From Cloud Shell, create a firewall rule that allows SSHtraffic to your VPC network by allowing ingress from the 35.235.240.0/20 IPaddress range that's used by theIAP for TCP forwarding service:

   gcloudcomputefirewall-rulescreatedemo-allow-ssh\--direction=INGRESS\--priority=1000\--network=restricted-vpc\--action=ALLOW\--rules=tcp:22\--source-ranges=35.235.240.0/20

2. Start an SSH session to this instance:

   gcloudcomputesshdemo-vm--zone=ZONE

   Verify that you have successfully connected to thedemo-vm instance byconfirming that the command-line prompt has changed to show the hostname of yourinstance:

   username@demo-vm:~$

   If the previous command fails, you might see an error message similar to thefollowing:

   "[/usr/bin/ssh] exited with return code [255]"

   In this case, the Compute Engine instance might not have completedbooting up. Wait a minute and then try again.

3. From the SSH session inside your perimeter, verify the services thatyour perimeter allows internally by using a Google Cloud service thatis configured in the VPC accessible services allowlist. For example, tryany command using the Compute Engine service.

   gcloudcomputeinstancesdescribedemo-vm--zone=ZONE

   A successful response returns the details ofdemo-vm. This responsedemonstrates that your perimeter allows internal traffic to theCompute Engine API.

4. From the SSH session inside your perimeter, verify that the servicesnot included in the VPC accessible services allowlist are not allowed fromyour VM. For example, the following command uses theResource Manager service, which is not configured in the VPC accessibleservices allowlist.

   gcloudprojectsdescribePROJECT_ID

   The output is similar to the following:

   "ERROR: (gcloud.projects.list) PERMISSION_DENIED: Request is prohibited by organization's policy."

   Your Compute Engine instance and other network endpoints can onlyrequest services that are configured in the VPC accessible services allowlist.However, serverless resources or service traffic originating from outside yourperimeter might request that service. If you want to prevent a servicefrom being used in your project, see theRestricted Service Resource Usage policy.

Verify that the perimeter denies internal traffic to restricted services outside the perimeter

In this section, you verify that the perimeter blocks communication fromservices inside the perimeter to Google Cloud services outside theperimeter.

The previous diagram illustrates how internal traffic cannot communicate withrestricted services outside the perimeter.

In the following steps, you verify this concept by attempting to send internaltraffic to a restricted service inside the perimeter and to a restricted serviceoutside the perimeter.

1. From the SSH session inside your perimeter, run the following commandto create a storage bucket inside your perimeter. This command worksbecause the Cloud Storage service is configured in bothrestricted-servicesandaccessible-services.

   gcloudstoragebucketscreategs://PROJECT_ID-02

   A successful response creates the storage bucket. This responsedemonstrates that your perimeter allows internal traffic to the Cloud Storageservice.

2. From the SSH session inside your perimeter, run the following commandto read from a bucket that is outside of your perimeter. Thispublic bucket allows read-only permission toallUsers, but the perimeterdenies traffic from inside your perimeter to a restricted service outsidethe perimeter.

   gcloudstoragecatgs://solutions-public-assets/vpcsc-tutorial/helloworld.txt

   The output is similar to the following:

   "ERROR: (gcloud.storage.objects.describe) HTTPError 403: Request is prohibitedby organization's policy."

   This response demonstrates that you can use restricted services inside theperimeter, but a resource inside the perimeter cannot communicate withrestricted services outside the perimeter.

Verify that an egress policy allows an exception to the perimeter

In this section, you verify that an egress policy allows an exception to the perimeter.

The previous diagram illustrates how internal traffic can communicate with a specific external resource when you grant a narrow exception with the egress policy.

In the following steps, you verify this concept by creating an egress policythen accessing a public Cloud Storage bucket outside of the perimeterallowed by the egress policy.

1. Open a new Cloud Shell session by clickingaddopen a new tab in Cloud Shell.In subsequent steps you switch between the first tab with the SSH sessioninside your perimeter, and the second tab in Cloud Shell outsideyour perimeter where the command-line prompt begins withusername@cloudshell.

2. From the Cloud Shell tab, create an egress policy that allowsegress from the attached service account identity ofdemo-vm using thegoogle.storage.objects.get method to a public bucket in an externalproject. Update the perimeter with the egress policy.

   exportPOLICY_ID=$(gcloudaccess-context-managerpolicieslist\--organization=ORGANIZATION_ID\--format="value(name)")exportSERVICE_ACCOUNT_EMAIL=$(gcloudcomputeinstancesdescribedemo-vm\--zone=ZONE\--format="value(serviceAccounts.email)")

   cat<<EOF >egress_spec.yaml-egressFrom:identities:-serviceAccount:$SERVICE_ACCOUNT_EMAILegressTo:operations:-methodSelectors:-method:'google.storage.objects.get'serviceName:storage.googleapis.comresources:-projects/950403849117EOF

   gcloudaccess-context-managerperimetersupdatedemo_perimeter\--set-egress-policies=egress_spec.yaml\--policy=$POLICY_ID

3. Return to the tab with the SSH session to the VM inside your perimeter,where the command-line prompt begins withusername@demo-vm.

4. From the SSH session inside your perimeter, make another request to theCloud Storage bucket and verify it works.

   gcloudstoragecatgs://solutions-public-assets/vpcsc-tutorial/helloworld.txt

   The output is similar to the following:

   "Hello world!This is a sample file in Cloud Storage that is viewable to allUsers."

   This response demonstrates that your perimeter and egress policy allow internaltraffic from a specific identity to a specific Cloud Storage bucket.

   Note: After you update a service perimeter, it can take some time for thechanges to propagate and take effect. If you receive an unexpected result, waita minute and try again after the perimeter has fully updated.

5. From the SSH session inside your perimeter, you can also test othermethods that weren't explicitly allowed by the egress policy exception. Forexample, the following command requires thegoogle.storage.buckets.listpermission which is denied by your perimeter.

   gcloudstoragelsgs://solutions-public-assets/vpcsc-tutorial/*

   The output is similar to the following:

   "ERROR: (gcloud.storage.cp) Request is prohibited by organization's policy."

   This response demonstrates that your perimeter denies internal traffic fromlisting objects in the external bucket, indicating that the egress policynarrowly allows explicitly specified methods.

For more references on common patterns for sharing data outside of your serviceperimeter, seesecure data exchange with ingress and egress rules.

(Optional) Configure the Restricted Service Resource Usage policy

You might also have internal requirements or compliance requirements toallow only individually approved APIsto be used in your environment. In this case you might also configure theRestricted Service Resource Usage Organization Policy Service. By applying the Organization Policy in a project, yourestrict which services can be created in that project. However, theOrganization Policy does not prevent services in this project fromcommunicating with services in other projects. In comparison,VPC Service Controls allows you to define a perimeter to preventcommunication with services outside the perimeter.

For example, if you define an Organization Policy to allowCompute Engine and deny Cloud Storage in your project, a VM in thisproject could not create a Cloud Storage bucket in yourproject. However, the VM can make requests to a Cloud Storage bucket inanother project, so exfiltration with the Cloud Storage service is stillpossible. The following steps show how to implement and test this scenario:

1. Switch to the Cloud Shell tab, where the command-line promptbegins withusername@cloudshell.

2. From the Cloud Shell tab, create a YAML file describing theOrganization Policy Service that will only allow usage of the Compute Engineservice and deny all other services, and then apply it to your project.

   cat<<EOF >allowed_services_policy.yamlconstraint:constraints/gcp.restrictServiceUsagelistPolicy:allowedValues:-compute.googleapis.cominheritFromParent:trueEOF

   gcloudresource-managerorg-policiesset-policyallowed_services_policy.yaml\--project=PROJECT_ID

3. Return to the tab with the SSH session to the VM inside your perimeter,where the command-line prompt begins withusername@demo-vm.

4. From the SSH session inside your perimeter, run the following command toview the same storage bucket you previously created inside this project.

   gcloudstoragebucketsdescribegs://PROJECT_ID

   The output is similar to the following:

   "ERROR: (gcloud.storage.buckets.create) HTTPError 403: Request is disallowed by organization's constraints/gcp.restrictServiceUsage constraint for 'projects/123456789' attempting to use service 'storage.googleapis.com'."

   This response demonstrates that Organization Policy Service denies the Cloud Storage serviceinside your project, regardless of the configuration of your perimeter.

   Note: After you update an Organization Policy Service, it can take some time for thechanges to propagate and take effect. If you receive an unexpected result, waita minute and try again after the perimeter has fully updated.

5. From the SSH session inside your perimeter, run the following commandto view a storage bucket outside the perimeter that is allowed by youregress policy.

   gcloudstoragecatgs://solutions-public-assets/vpcsc-tutorial/helloworld.txt

   The output is similar to the following:

   "Hello world!This is a sample file in Cloud Storage that is viewable to allUsers."

   A successful response returns the content ofhelloworld.txt in the externalstorage bucket. This response demonstrates that yourperimeter and egress policy allows internal traffic to reach an external storagebucket under certain limited conditions, but the Organization Policy Service denies theCloud Storage service in your project regardless of the configuration of yourperimeter. Services outside your project might still be used for exfiltration ifthey are allowed by your perimeter, regardless of the Restricted ServiceResource Usage Organization Policy Service.

   To deny communication with Cloud Storage or other Google servicesoutside the perimeter, theRestricted Service Resource Usage Organization Policy Service alone is not sufficient, you must configure aVPC Service Controls perimeter. VPC Service Controls mitigates dataexfiltration paths, andRestricted Service Resource Usage is a compliance control to prevent creating unapproved services inside yourenvironment. Use these controls together to block a range of exfiltration pathsto and selectively allow approved services for internal use in yourenvironment.

Clean up

Caution: Deleting a project has the following effects:

• Everything in the project is deleted. If you used an existing project for the tasks in this document, when you delete it, you also delete any other work you've done in the project.
• Custom project IDs are lost. When you created this project, you might have created a custom project ID that you want to use in the future. To preserve the URLs that use the project ID, such as anappspot.com URL, delete selected resources inside the project instead of deleting the whole project.

If you plan to explore multiple architectures, tutorials, or quickstarts, reusing projects can help you avoid exceeding project quota limits.

In the Google Cloud console, go to theManage resources page.

Go to Manage resources

In the project list, select the project that you want to delete, and then clickDelete.

In the dialog, type the project ID, and then clickShut down to delete the project.

Although the VPC Service Controls perimeter does not generate anyadditional cost, it should be cleaned up to avoid clutter and unused resourcesin your organization.

1. In the project selector at the top of the Google Cloud console, select the organizationyou used during this tutorial.

2. In the Google Cloud console, go to theVPC Service Controlspage.

   Go to VPC Service Controls

3. Under the list of perimeters, select the perimeter you want to deleteand clickDelete.

4. In the dialog, clickDelete again to confirm deletion.

What's next

• Learn aboutbest practices for enabling VPC Service Controls.
• Learn about which services aresupported on VPC Service Controls.
• Learn how to enableVPC accessible services.
• Read about the configuration ofPrivate Service Connect to access Google APIs.

• For more reference architectures, diagrams, tutorials, and bestpractices, explore theCloud Architecture Center.