To further protect your Compute Engine resources, you can protect themusingVPC Service Controls.

VPC Service Controls let you define a service perimeter for yourCompute Engine resources. The service perimeter limits exporting andimporting of resources and their associated data to within the defined perimeter.

When you create a service perimeter, you select one or more projects to beprotected by the perimeter. Requests between projects within the same perimeterremain unaffected. All existing APIs continue to function as long as theresources involved are within the same service perimeter. Note the IAMroles and policies still apply within a service perimeter.

When a service is protected by a perimeter, requests cannot be made by theserviceinside the perimeter to any resourceoutside the perimeter. Thisincludes exporting resources from inside to outside the perimeter. Requestsfor protected resources fromoutside a perimeter is possible if they meetcertain criteria. For more information, seeOverviewin theVPC Service Controlsdocumentation.

When a request is made that violates the service perimeter, the request failswith the following error:

"code": 403, "message": "Request is prohibited by organization's policy."

Security benefits

VPC Service Controls provide the following security benefits:

• Access to sensitive Compute Engine API operations, such as changing firewallrules, can be restricted to private access from authorized networks or toIP addresses that are part of an allowlist.
• Compute Engine persistent disk snapshots and custom images can berestricted to a perimeter.
• Compute Engine instance metadata acts as a limited storage system. Accessto instance metadata through the Compute Engine API is limited by service perimeter policy,mitigating exfiltration risks using this channel.

Additionally, the Compute Engine API is now accessible on therestricted virtual IP (VIP).This simplifies the Cloud DNS and routing configuration for clients within theperimeter that need access to this API.

Limitations

• Hierarchical firewalls are not affected by service perimeters.
• VPC peering operations don't enforce VPC service perimeter restrictions.
• Theprojects.ListXpnHostsAPI method for Shared VPC does not enforce service perimeter restrictions onreturned projects.

Permissions

Make sure that you have theproper roles to administerVPC Service Controls Perimeter configurations for your organization.

Set up a service perimeter

Follow the instructions atCreating a service perimeterin the VPC Service Controls documentation to set up a service perimeter.

If setting up a service perimeter by using the Google Cloud CLI, specifycompute.googleapis.com with the--restricted-services flag to restrict theCompute Engine API.

Adding Compute Engine as a restricted service to an existing perimeter

If you have an existing service perimeter and would like to add Compute Engineto the service perimeter, follow the instructions atUpdating a service perimeterin the VPC Service Controls documentation.

Creating a VM with VPC Service Controls

After setting up a service perimeter, you don't need to make any changesto existing API calls or tooling, as long as the affected resources in yourrequests are included in the same service perimeter. For example, the followingcommand creates a VM instance with an example image. In this case, thecommand fails if theIMAGE_PROJECT is outside of the serviceperimeter (and there is noservice perimeter bridgebetween the projects).

gcloudcomputeinstancescreatenew-instance\--image-familyIMAGE_FAMILY--image-projectIMAGE_PROJECT\--zoneus-central1-a--machine-typen1-standard-72

If you are creating a VM from an instance template, any resources referencedin the instance template must belong within the same service perimeter whereyou are running the command or be connected using a service perimeter bridge.The request fails if the instance template refers to a resource outsideof the service perimeter, even if the instance template itself is within theperimeter.

For an example scenario of a Compute Engine client outside the perimetercreating a Compute Engine disk outside the perimeter using aCloud KMS key inside the perimeter, seeExamples of API requestsallowed by combination of ingress and egressrules.

Public image projects

All image projects listed on theOS detailspage are automatically included in all service perimeters. In addition, the imageprojects for theFedora Cloud,openSUSE, andHPC OS are also automatically included.

If you're using image projects that are not included in your service perimeterand don't want to add them directly, we recommend that you copy these imageprojects to a separate project. Then, you can add that project into your serviceperimeter.

Copying images with VPC Service Controls

You can copy images from one project to another if both projects belong to thesame service perimeter. In this example, bothDST_PROJECT andSRC_PROJECT must belong to the same service perimeterfor the request to work.

gcloud compute images create --projectDST_PROJECTIMAGE_NAME \   --source-imageSOURCE_IMAGE --source-image-projectSRC_PROJECT \    --familyIMAGE_FAMILY --storage-locationLOCATION

If you choose not to include the image project directly into your securityperimeter, we recommend you make a copy of all of the images to be used into aseparate project first, then include the separate project into your securityperimeter.

Shared VPC with VPC Service Controls

When using Shared VPC, service perimeter restrictions to apply to all projectsinvolved in a given operation. In other words, we recommend that you make sure that the hostproject and service projects are within the same service perimeter when anoperation involves resources distributed between the host and service projects.

VPC Network Peering

VPC Network Peering allows peering VPC networks betweentwo separate organizations. Because a service perimeter is limited to projectswithin an organization, service perimeters don't affect peering VPC networks.

Hierarchical firewalls

Hierarchical firewalls are firewalls that are configured outside a project(either at the folder or at the organization level). Service perimeterrestrictions don't apply to hierarchical firewalls.

Managed instance groups

Managed instance groups help you manage agroup of VM instances as a single entity. Managed instance groups (MIGs) use instancetemplates to create VMs, and all restrictions around images orcross-project networks and subnetworks apply. That is, when using images fromother projects, make sure the projects belong to the same perimeter, or copythe images you need into another project and include that project in theservice perimeter. Google-maintained public image projects are automaticallyincluded in all service perimeters.

If you want to use instance groups with Shared VPC, make sure that yourprojects are in the same service perimeter.

What's next

• Learn more aboutVPC Service Controls.
• Learn about services supported byrestricted virtual IPs.
• Read more aboutservice perimeter configuration steps.