Hybrid Cloud Modernisation & Connectivity as code — Firewall automation

Co-author: Balakrishnan Sreenivasan

Hybrid cloud landing zone is the foundation towards Hybrid cloud modernisation. One of my previous blog talks about five steps to approach hybrid cloud design patterns with the assumption that the foundation layer is in place. Also, Balakrishnan Sreenivasan in his blog speaks about reference architectures & patterns and how it accelerates target operating model. Both of us reflected the need for code patterns where infrastructure as code or for that matter Everything as Code is the key tenet for large scale modernisation.

The principle of “Everything as Code”

Platform engineering practices to craft out a hybrid cloud landing zone typically follows the principle of “Everything as Code”. The “Everything” includes “Connectivity as code”(CAC). Lack of connectivity as code(CAC) could result in manual interventions for firewall rule creation & governance resulting in deceleration of any large scale cloud modernisation or migration program. CAC coupled with a lean governance process allows firewalls rules to be provisioned in minutes instead of days. Firewall rules are to be created and governed for the traffic flow through North-South(internet egress, ingress & egress to/from on-premise), and East-West(cloud to cloud, e.g aws vpc-vpc) firewalls.

Firewall rule automation — How do we do it ?

Following diagram depicts an end to end flow for an automated firewall provisioning process with description of each of the steps in the diagram below. A critical aspect of how acceleration in firewall process is achieved is when the firewall rules are segregated to golden rules versus unique rules.

• Golden rules are pre-approved rules and are typically commonly used across application scenarios: 443 (https), 1433 (MS SQL), 3306 (MySQL), 5432 (Postgres), 1521 (Oracle) and so on.
• Unique rules are the ones that are specific to applications and normally have security implications: Laptop / desktop connectivity to a database server on cloud (e.g. for thick clients, reporting client software, etc.)

Firewall / CAC pipeline

Identify firewall rules: Most enterprise systems have significant point-to-point interconnections/network routes which is very difficult to identify and untangle to extract real system level interactions that matter for firewall purposes. Typically, discovery & scanning tools should be able to get network traffic from current application infrastructure to other systems which could be used as base for establishing the firewall rules. One would discover source, destination IP addresses, ports, and additional attributes in these data points. However, significant noise reduction needs to be done to remove unwanted on-prem related rules (e.g., system management traffic etc.). Review and finalisation with the existing application support teams will help make this more accurate.

We all wish that what if the CMDBs were up to date and it captured the right ingress & egress rules to/from an application. Now, as we modernise on the cloud, a graph database that is auto-populated with the results of network automation will help in provenance of the future state network topology.

Develop Connectivity-as-Code (CAC)/ Build firewall rules: In almost all cases, teams would be building connectivity infrastructure for the migration as CAC (Connectivity as Code) — either as Terraform, Azure Resource Templates, CloudFormation etc. Based on the type of firewall(north, south, east-west), the specific IP blocks/CIDRs are used to prepare the CAC configuration files. When using terraform for CAC, the panos provider is leveraged and firewall rules can be defined in the tfvars file which is then pushed to git. As depicted below, when the related pull request is approved, the changes are reflected in Terraform workspace (per environment). TF plan is reviewed and applied for the change to be next reviewed in Panorama console(in the context of PaloAlto firewalls).

Terraform workspace

Review / Approve Firewall configurations: This step is invoked when the firewall rules are not in the pre-approved golden rule list. Security & network guilds review the unique rules and approve for application. Best effort is made to validate any rules that meets criteria to be inducted into the golden-rule list.

Implement Firewall configurations: Once the firewall configurations CAC is executed in the terraform workspace, one could go to panorama console to review and commit+push the changes to the firewall virtual appliance.

Panorama screen

As the applications evolve with associated/dependant applications move to cloud or transform into different integration models the CAC & associated firewall rules needs to be revised and then re-applied and they are part of regular change management activities. However, the applications that are re-architected with cloud-native approaches may not require extensive discovery from connectivity/firewall rule identification perspective.

While the above lays out the process based on terraform & palo firewalls based automation, we can extend the automation scope further in the following two ways:

1. Firewall vendors have features such as Palo Alto’s capability of reading AWS attributes (e.g. tags) and then auto-generate firewall rules as changes to infrastructure is made on the cloud. These rules can be reviewed based on the golden-rule/unique-rule sets. The list of monitored AWS attributes can be found here.
2. Use “tagging” models to ensure every VPC / subnets or specific resource (if needed) are tagged with specific tags that are correlated with the golden rules mentioned above. One could implement custom scanning (AWS Lambda functions triggered by events from infra provisioning, such as, via events in CloudTrail) of tags and auto generate firewall rules that could be applied into the target firewall system (e.g. AWS Lambda invokes Palo APIs for registering the rules). This helps to implement a truly event based scalable firewall process model leaving full stack squads to own and manage respective firewall configurations that are propagated in an automated manner.

Thanks to Andrew Baird for his insights and adding his experiences on the event driven model called out in the above section.

Further Reads:

Following are some good resources that can be referenced for further reading:

End to end Cloud Security Automation with Terraform — https://www.youtube.com/watch?v=WXhOW0gvlTU

Panorama Configuration — https://paloaltonetworks.github.io/terraform-iac-lab/02-configure/configure.html

Terraform IAC Lab Documentation — https://terraform-iac-lab.readthedocs.io/_/downloads/en/latest/pdf/