Protecting resources with VPC Service Controls

To further protect your Compute Engine resources, you can protect them using VPC Service Controls.

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

When you create a service perimeter, you select one or more projects to be protected by the perimeter. Requests between projects within the same perimeter remain unaffected. All existing APIs continue to function as long as the resources involved are within the same service perimeter. Note the IAM roles and policies still apply within a service perimeter.

When a service is protected by a perimeter, requests cannot be made by the service inside the perimeter to any resource outside the perimeter. This includes exporting resources from inside to outside the perimeter. Requests for protected resources from outside a perimeter is possible if they meet certain criteria. For more information, see Overview in the VPC Service Controls documentation.

When a request is made that violates the service perimeter, the request fails with 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 firewall rules, can be restricted to private access from authorized networks or to allowlisted IP addresses.
  • Compute Engine persistent disk snapshots and custom images can be restricted to a perimeter.
  • Compute Engine instance metadata acts as a limited storage system. Access to 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 the restricted virtual IP (VIP). This simplifies the Cloud DNS and routing configuration for clients within the perimeter that need access to this API.

Limitations

  • Hierarchical firewalls are not affected by service perimeters.
  • VPC peering operations do not enforce VPC service perimeter restrictions.
  • The projects.ListXpnHosts API method for Shared VPC does not enforce service perimeter restrictions on returned projects.

Permissions

Make sure that you have the proper roles to administer VPC Service Controls Perimeter configurations for your organization.

Set up a service perimeter

Follow the instructions at Creating a service perimeter in the VPC Service Controls documentation to set up a service perimeter.

If setting up a service perimeter by using the Google Cloud CLI, specify compute.googleapis.com with the --restricted-services flag to restrict the Compute 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 Engine to the service perimeter, follow the instructions at Updating a service perimeter in the VPC Service Controls documentation.

Creating a VM with VPC Service Controls

After setting up a service perimeter, you do not need to make any changes to existing API calls or tooling, as long as the affected resources in your requests are included in the same service perimeter. For example, the following command creates a VM instance with an example image. In this case, the command fails if the IMAGE_PROJECT is outside of the service perimeter (and there is no service perimeter bridge between the projects).

gcloud compute instances create new-instance \
    --image-family IMAGE_FAMILY --image-project IMAGE_PROJECT \
    --zone us-central1-a --machine-type n1-standard-72

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

For an example scenario of a Compute Engine client outside the perimeter creating a Compute Engine disk outside the perimeter using a Cloud KMS key inside the perimeter, see Examples of API requests allowed by combination of ingress and egress rules.

Public image projects

Google provides and maintains a set of public images for your instances. These projects are implicitly included in all security perimeters. No additional action is required to use these images.

The following is a list of projects that are automatically included in all security perimeters:

  • centos-cloud
  • cos-cloud
  • debian-cloud
  • fedora-cloud
  • fedora-coreos-cloud
  • rhel-cloud
  • rhel-sap-cloud
  • rocky-linux-cloud
  • opensuse-cloud
  • suse-cloud
  • suse-byos-cloud
  • suse-sap-cloud
  • ubuntu-os-cloud
  • ubuntu-os-pro-cloud
  • windows-cloud
  • windows-sql-cloud

If you are using an image project that is not on this list and you choose not to include the image project directly into your security perimeter, we recommend you make a copy of all of the images to be used into a separate project first, then include the separate project into your security perimeter.

Copying images with VPC Service Controls

You can copy images from one project to another if both projects belong to the same service perimeter. In this example, both DST_PROJECT and SRC_PROJECT must belong to the same service perimeter for the request to work.

gcloud compute images create --project DST_PROJECT IMAGE_NAME \
   --source-image SOURCE_IMAGE --source-image-project SRC_PROJECT \
    --family IMAGE_FAMILY --storage-location LOCATION

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

Shared VPC with VPC Service Controls

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

VPC Network Peering

VPC Network Peering allows peering VPC networks between two separate organizations. Because a service perimeter is limited to projects within an organization, service perimeters do not 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 perimeter restrictions apply to a set of projects within a perimeter so do not apply to hierarchical firewalls.

Managed instance groups

Managed instance groups help you manage a group of VM instances as a single entity. Managed instance groups (MIGs) use instance templates to create VMs, and all restrictions around images or cross-project networks and subnetworks apply. That is, when using images from other projects, make sure the projects belong to the same perimeter, or copy the images you need into another project and include that project in the service perimeter. Google-maintained public image projects are automatically included in all service perimeters.

If you want to use instance groups with shared VPC, make sure that your projects are in the same security perimeter.

What's next