Also read NACLS on AWS and GCP Equivalents

The Problem Statement

Configuring and managing IP-based firewall rules is a complex and manual process that can lead to unauthorized access if done incorrectly.

Enter Service Accounts 

Service Accounts provide an identity to applications running on Compute Instances.

Service Accounts provide a method to group virtual machine instances running the same / similar application, with a common identity. A cluster of database VMs can run under the same service account, for example.

Firewall Rules in GCP can be based on Service Accounts

Along with the convenience of app (VM) grouping, Service Accounts can be used to define the source and targets in Firewall Rules on GCP. This means that a FW can say - Web_to_Database_SA_Allow - and allow all web instances running under a common service account, to access VMs running the database.

There's no need to filter by IP Addresses. 

Service accounts assigned to new VMs

New VMs are should be automatically created from an instance template and assigned the correct service account identity. This way, when the VM starts up, it gets the right set of permissions and within the relevant subnet. Firewall rules are automatically configured and applied by using service accounts.

The combination of Cloud IAM ACLs with service accounts allows application owners to express their firewall rules in the form of intent. For example, allowing  “web-service-account” servers to access "database-service-account”.

This eliminates the need to manage Server IP Address lists.

Summary

It sounds like a minor convenience factor, but is actually a very powerful way to limit traffic between different types of workloads. IMHO, GCP wins hands down in the way it enforces firewall rules over both AWS and Azure.




Need an experienced Cloud Security Expert?
Anuj has successfully delivered over a dozen deployments on each of the public clouds (AWS/GCP/Azure) including several DevSecOps engagements. Set up a time with Anuj Varma.