Hello Cloud Architects. Today we will cover various new features added in GCP Network Security portfolio which will help us build a more robust and compliant VPC firewall rules.
Lets start with a basic requirement to control communication between workloads in the cloud. Below are the few control parameters
Below is sample “starting” Network topology of our organisation.
In above topology, we have a workload VPC [VPC-bu1] and a common VPC [VPC-commonservice]. We have few workloads deployed. We can also see in the diagram how the requirements captured initially result in what flows we want to allow. So VM’s which need internet are “bu1-prod-vm-app” and “bu1-nonprod-app”. Within “VPC-bu1” we need “bu1-prod-vm-app” to only talk to “bu1-prod-vm-db” and similarly we need “bu1-nonprod-vm-app” to only talk to “bu1-nonprod-vm-db”. Lastly for “inter-vpc” or commons service, we need prod VM’s to talk to “cs-prod-vm-1” and non prod VM’s to talk to “cs-nonprod-vm”.
Now lets see how “traditionally” this was done using VPC firewall rules and Network “tag”.
Below table covers various network tags and VM’s they are attached with
Below are sample VPC firewall rules
Few things to note here
a. These are VPC scope firewall rules, so this apply only to vpc-bu1. We need to write seperate firewall rules for vpc-commonservice
b. As Network “Tags” are scoped at VPC level we cannot use tags attached to common service VPC and use in this firewall rules. Thus to allow communication to common service we use CIDR range.
c. Note the rules written for “internet” ingress/egress for “DMZ” tag VM’s. Its writen for all 0.0.0.0/0. Thus opening communication not only for internet but also for VM’s with no tags
Now take this topology and requirement and assume we scale to few more “bu” vpc’s.
We can already see problem with this approach but I am highlighting them below
Now the problem statement is set, lets move into various features we will be using to achieve the desired compliant requirements with ease.
Below are the features we will be leveraging to solve the above problem statements
Lets cover them one by one
a. Hierarchical Firewall Policy — They allow us to create and enforce a consistent firewall policy across our organization by assigning them to the organization as a whole or to individual folders. They contain similar allow/deny rules as in VPC firewall rules but can also delegate certain rules to low level policy or VPC Network firewall.
b. Org-scoped Secure Tags — Secure TAGs are Identity and Access Management (IAM)-governed tags that are created and managed in Resource Manager as tag keys and tag values. They can be used to specify sources for ingress rules and targets for ingress or egress rules in a hierarchical firewall policy. Earlier they were scoped at Project level but recently GCP announced supporting Org-scope Secure Tags, meaning these Tag’s can now be assign to workload in any project across an organisation.
c. Network Type — Network types helps us meet our security requirements by using fewer firewall policy rules. Cloud NGFW supports four network types that can be used to create a source combination or destination combination in a rule of a hierarchical firewall policy.
As we understood the basic construct of above 3 features now lets see how our firewall Policy rules will look like, using all of the 3 above
These rules are created at Organisational Level, hence will be imported by all Projects, VPC’s and workloads. Lets understand these rules
a. Rule-1 — This rule is to allow IAP access to all VM’s. Its allow specific IAP ranges [35.235.240.0/20] and applied to all VM’s
b. Rule-2,3 — These 2 rules are applied to VM’s with Secure TAG “DMZ”. Although the rule is open to/from 0.0.0.0/0 [just like VPC firewall rules] but it has a Network type of “Internet”. Hence any internal flows [e.g. VPC] will not be allowed
c. Rule-4,5 — These 2 rules are applied to VM’s with Secure TAG “PROD”. As tag’s are applied to Production VM [across all VPC’s] thus it facilitate communication between “App” and “DB” and also between “common Service” to Other Production VM’s [across VPC]. Thus no need to write CIDR base rules any more. Although we are using CIDR block of 0.0.0.0/0 but as Network type is “non-internet” it will not allow internet traffic on this.
In a nutshell we saw how by leveraging GCP’s Next-Gen Firewall with hierarchical policies, organization-scoped secure tags and Network type we can finally achieve a security posture that is both powerful and simple to manage and overcome the limitations of VPC firewall rules. By embracing these features we are not just patching a problem but we can fundamentally transform how an organization can manage its security and compliance.
Ready to take control of your cloud security? Start exploring these features in your own GCP organization today and experience the power of a truly secure and compliant architecture.
This is to inform readers that the views, thoughts, and opinions expressed in the text belong solely to the author, and not necessarily to the author’s employer, organization, committee or other group or individual.
Source Credit: https://medium.com/google-cloud/the-secret-to-unbreakable-security-and-effortless-compliance-on-gcp-0d6c86924a5b?source=rss—-e52cf94d98af—4
