(Image credit Andreas Klodt.)
What are VPC Service Controls
A feature that allows you to configure security perimeters around data resources of your Google Managed services to help you control the movement of data across the perimeter boundary. The primary goal of VPC Service Controls (or VPC-SC) is to prevent data exfiltration which cannot be stopped by other means such as IAM and so on.
Why use VPC-SC?
- Prevent data exfiltration by malicious insiders or due to misconfiguration.
- Prevent access to non-compliant services from sensitive environments, which helps limit audit scope.
Key word here is defense in depth. VPC-SC adds one more layer of protection.
How do you build a secure VPC?
You start by adding a bunch of GCP projects into a Service Perimeter. You then configure the GCP services for which communication is controlled by the Service Perimeter. Remember though, the VPC Service Perimeter only applies to services that support it. Unsupported services can communicate out across the perimeter, even if you have one setup. Any VPNs or Interconnects that terminate within a project within the perimeter will be seen as traffic within the perimeter, and allowed.
The goal of VPC-SC is to prevent data exfiltration. This means you try and include only those projects in a VPC-SC where you have sensitive data that you really need to keep private.
Once you have setup your Service Perimeter, you’ve stopped all ingress and egress traffic across your perimeter. But what if you have public services that need to access data within the perimeter? To support this, you can classify requests based on a client context. Supported request attributes today are IP range (Public only) and/or User or Service Account. This classification is defined as an
Access Levels and you set this up within
Access Context Manager. As part of the Access Level creation, you assign access policies to these levels. Once setup, you can then associate one or more Access Levels to a Service Perimeter. Access is granted if request matches any Access Level definition. Access Levels are also used in IAP and with IAM Conditions in GCP.
Private Google Access
It is highly recommended to turn on Private Google Access. This provides a private route to Google APIs without needing the traffic to go out of the Google backbone. You can get the same benefits for API requests coming in from on-prem connections terminating within the VPC-SC by configuring your DNS and router to route requests to
restricted.googleapis.com. Similar to VPC-SC, something to keep in mind is that not all services support Private Google Access - so remember to verify that before setting this up. Also,
Restricted VIP (restricted.googleapis.com) is a special VIP that contains endpoints to only the Google APIs and Services that support Private Access from On-Prem and VPC-SC. This is advertised globally as
restricted.googleapis.com (18.104.22.168/30), but is not routable from the internet. The Restricted VIP does not support G Suite web applications or G Suite APIs. You can read more here
There exists another VIP (
private.googleapis.com) with a CIDR or 22.214.171.124/30. This is meant to provide API access to most Google APIs and services regardless of whether they are supported by VPC Service Controls. This also includes API access to Google Maps, Ads, etc. However, this does not support G Suite web applications. You can use
private.google.com either when you’re not using VPC-SC, or when you’re using VPC-SC, but also need to access services that are not supported by VPC-SC.
Service Perimeter Bridge
A design feature of Service Perimeters is that every GCP project can belong to exactly one Service Perimeter. But when you need a project that already exists within a VPC Service Perimeter to talk to another one within another Service Perimeter, you create a
Perimeter Bridge. A GCP project can be added to multiple Perimeter Bridges.
But remember, when you create perimeter bridges, you’re poking holes in your Service Perimeter which allow traffic both ways. So think very carefully before doing this as it can quickly add management complexity and blind spots that can defeat the purpose of using service perimeters in the first place.
Some Best Practices
Always a good idea to configure VMs in GCP with only Private IPs. Ideally, you want to do this using an organization policy so that it is consistently enforced.
Setup routing such that only the Restricted VIP CIDR is routed to the Internet Gateway.
If you really need to configure public IPs, then a few things you can do are - ** Deny egress traffic using firewall rules except where absolutely necessary. ** Create higher priority rules for specific destinations on the internet and the restricted VIP.
If you need to use unsupported services, put them in a project outside the perimeter! Examples of such services are Cloud Composer, App Engine etc. Make sure to look at this page to make sure.
VPC-SCs are a great feature when used right. However, PC-SCs are not a replacement for firewalls, they apply only to supported services. VPC-SCs should be used when you want an additional way to avoid data exfiltration. As with all security tools, be careful with configuration. A misconfigured security tool is worse than none, because it can give you a false sense of security and could cause you to let your guard down. Due to the way VPC-SC works, turning this on in an existing project has the potential to break things. Finally, test thoroughly before use. May your perimeter remain secure always!
- How would Terraform provisioning work when using VPC Service Controls?