Firewalling your Managed Services on Google Cloud — Security deep dive
Traditional IT environments are protected by multiple levels of security. Amongst them are fine-grained access control and network security, like limiting workloads to LANs and adopting firewalls. When adopting Managed Services, the level of abstraction is higher. There, we need to adopt a different approach to maximise security and limit accessibility. Briefly said: how can we add a firewall to our Bigtable instances? I’ll explain in this blog post.
TL;DR: If you want a firewall around your BigQuery or Bigtable environment, VPC Service Controls can help.
Securing traditional workloads
When working with customers on designing their Google Cloud environment, for both them and us, security is always a main pillar. Many customers start with migrating their infrastructure as-is (“ lift and shift “) and leverage some quick benefits on the side (“move and improve”), like moving to Cloud SQL instead of hosting their own PostgreSQL on a VM.
Traditional security aspects & considerations
These traditional workload migrations bring, amongst others, the traditional security aspects with them. For example, staying within private network range (the infamous RFC 1918) and managing your VPC firewalls are one of the first things that come to mind.
When we are explicitly looking at Compute Engine instances running private workloads, there are many security considerations to be made. As an example, the following two are complementary: creating instances without a public IP address and blocking ingress traffic using VPC Firewall rules.
This way, if even one of the two mitigations gets breached (i.e. an engineer adds a public IP to a VM instance), the other security layer still protects your resource (the VPC firewall will block all public access attempts to the VMs public IP).
Managed Services with Public Endpoints
Once these customers are acquainted with Google Cloud, they quickly see the benefits of the many managed services Google Cloud offers. One of these services is BigQuery, Google’s fully managed petabyte-scale warehouse. A very simple use case is exporting all Stackdriver Logging into BigQuery for log analysis.
BigQuery Managed Service
BigQuery, being a managed service, does not require its users to care about the underlying infrastructure, and provides a nice web interface on top of REST APIs to interact with the service. Customers can easily adopt the least privileges principle to limit access to a certain set of users and share specific datasets (a grouping of tables in BigQuery) to a limited set of analysts.
One of the benefits of a managed service with a cloud provider like Google, is that everything is configurable using these APIs. From anywhere in the world, you can call upon BigQuery’s HTTP REST APIs to query and manage your data. After all, BigQuery does not run in your WAN and therefore is accessible over a public http endpoint: https://bigquery.googleapis.com.
Security risk Simply put: the only thing standing between this API and potentially massive data breaches, is credentials & IAM permissions.
If you are using a Service Account in your application to call upon BigQuery (i.e. by connecting an on-premises BI tool) and that key gets leaked, everyone in the whole wide world could have access to your BigQuery environment until that key is rotated.
Pretty sure we should do one better.
Adding the second Security Layer
As mentioned above, we would probably not want to rely only on the IAM policies to protect our Managed Services. A traditional reflex would be to add a firewall to the http endpoints, like we would want to do with a VM instance. Or prevent public routing at all. As there’s a single endpoint per service for all customers, we can’t do the last. But we can mimic the firewalling solution: enter VPC Service Controls.
Want to learn how to use VPC Service Controls to protect your managed services? Read the entire article on our blog: https://www.fourcast.io/blog/firewalling-your-managed-services-on-google-cloud-security-deepdive
