VPC Service Controls is a networking feature of Google Cloud. It helps to protect your cloud resources with perimeters and accompanying ingress and egress rules. Hence, the feature is often summarized as a firewall for your cloud resources.
VPC Service Controls Concepts
Essentially, VPC Service Controls provides three concepts:
- Service perimeters, groups of projects that are trusted to access each others cloud resources
- Context-aware access with ingress rules, IAP-like access rules to constrain external user access with attributes such as user identity and source network
- Secure data exchange with ingress and egress rules, access rules to restrict data exchange to specific projects
Together, these concepts allow you to create a trusted zone (service perimeter) of Google resources. Inside the trusted zone, resources are readily accessible. Outside of the trusted zone, only specified resources are accessible (egress rules). As a result you can prevent data exfiltration to third party storage buckets. Finally, you can enhance your resource access controls by requiring additional attributes (ingress rules) such as identity, geography and source network.
Understanding Service Perimeters
Conceptually, Service Perimeters are easy to grasp. However, the devil is in the details.
First, VPC Service Controls does not support all Google services. Therefore, not all services are able to securely access trusted resources. Gladly, however, the number of supported services increases.
There is no
restrict-allkeyword. Check out our supported service scraper to keep your restricted services up to date.
Second, your Service Perimeter only covers Google APIs, not application endpoints. For example, you can restrict the Cloud Functions
cloudfunctions.googleapis.com management API, but you can’t restrict the
cloudfunctions.net application endpoints.
As a consequence, you must use the Restricted Virtual IP (VIP) for Private Google Access. Using the Private VIP exposes all unprotected appliation endpoints such as
Third, finally, your Service Perimeter spans a group of projects, but egress controls are bound to VPC resources. If you use a Shared VPC owned by a project outside of your perimeter, the perimeter egress controls will not apply.
Implementing Service Perimeters
With thorough understanding of the service, you’re ready to implement a Service Perimeter. Instead of throwing examples at you, I’ll provide a truth table to summarize when a request is allowed or denied. Use it to configure the right control to secure your perimeter.
- Restricted service. A Google service protected by the Service Perimeter
- Accesssible services. A list of Google services that are accessible from within the Service Perimeter. Use this to restrict the available Google APIs
- Ingress & Egress rules. A set of access rule that specify who can do what under which conditions. Example, user x can invoke storage.get if request originates from Europe
Test your knowledge. What would you do to prevent data exfiltration? How can you limit the available Google APIs? Which attributes can you use to restrict service access? How would you combine multiple perimeters?
VPC Service Controls is a powerful, yet complex service. This blog only touched upon a single perimeter scenario, but you can – and most likely will – deploy multiple perimeters in your organization.
Since it is complex to implement, you might wonder if you need a Service Perimeter. Isn’t IAM sufficient to protect my cloud resources? No, it isn’t. Your data will be exfiltrated to a public bucket to bypass all IAM permissions. Similarly, Firewall rules don’t suffice. All Cloud Storage access flows through storage.googleapis.com. Hence, on the network level, you are unable to filter requests.
VPC Service Controls are easy to grasp, conceptually. However, the devil is in the details. By understanding that the controls are bound to VPCs and limited to supported services, you are set to configure your first Service Perimeters.
Photo by Tanya Nevidoma on Unsplash