Creating secure access architecture on Google Cloud Platform (and building it with Terraform)

by Alastair Shapley on Oct 17, 2019 12:00:00 AM

Often we get involved in projects where there are all sorts of stringent security requirements. In this post, I will share a few of the methods used to meet these security requirements within Google Cloud Platform (GCP), while still allowing developers and admins to access the environment without hindrance. We regularly have a requirement for global connectivity for administrators or developers, and GCP provides us with some useful tools to accomplish that. Having the ability to connect and administer the cloud platform via the console is one thing, but gaining access to instances on the VPC itself is also very valuable. These methods are primarily:

Using Google Cloud Identity-Aware Proxy to access Compute Engine instances
- this allows us to access GCP Instances via SSH or RDP using Google authentication, and the gcloud compute SSH command
- Instances do not need to have a public IP address
- nor does this require a VPN into the VPC
Using Google Private Access for our VPC
- this allows instances with an internal-only private network to still be able to reach Google Cloud API endpoints and services
- there is no need to have a Cloud NAT router or a public IP address
Restricting all traffic inbound and outbound via firewall rules
- exceptions for
  - outbound access to Google Cloud IP ranges (used by private access)
  - Identity-Aware Proxy inbound connectivity.
  - inter-machine connectivity restricted by service account
Using the capability to run an instance as a dedicated service account
- as well as restricting permissions for the account to a minimum required
- we need to be careful here with permissions

Of course, building this all with an infrastructure-as-code tool like Terraform makes all of this simple to use!

The Lab build

To actually build this, you could do it manually, but if you want a repeatable, modifiable process you could use Terraform. An example method is to follow the instructions in the Github repo here. In my example, it looks like the below diagram:

Summary:

Whilst a production deployment may look different than this, we can use the same concepts and apply them according to business requirements in order to achieve a good security posture that is more easily managed by a global team, all behind Google authentication (as opposed to interactive logins or SSH keys).

Additional Considerations:

If you use a default VPC network, it comes pre-configured to allow SSH access to all VMs, even if they only have a private IP address.
- your google credentials are very important to protect as you can SSH to any instance
- giving permissions to your project in a careless manner may allow admin access to instances even if they are not reachable from the outside world
Once someone gains access to a compute instance running as a service account, all of those service account permissions apply without needing to log in.
- so it is imperative that service account permissions are kept to a minimum!

References:

Github repository https://cloud.google.com/iap/docs/using-tcp-forwarding https://cloud.google.com/sdk/gcloud/reference/beta/compute/ssh https://cloud.google.com/vpc/docs/configure-private-google-access https://www.terraform.io/docs/providers/google/d/datasource_google_netblock_ip_ranges.html

Topics: MySQL AWS Technical Track Cloud Open Source Replication RDS Aurora Slave

No Comments Yet

Let us know what you think

See all

Share this