Dynamic Firewalling with Palo Alto Networks NGFWs and Consul-Terraform-Sync
I cannot reach www.isitthefirewall.com…!! Must be the firewall!!
Sounds familiar? We’ve all been there. If you were that lonely firewall administrator who tried to defend the good ol’ firewall, congratulations for making it this far. Life was tough back then when you only had a handful of firewall change requests a day, static data centres and monolithic applications.
Fast forward to the present day, we are moving away from traditional static datacentres to modern dynamic datacentres. Applications are no longer maintained as monoliths, they are arranged into several smaller functional components (aka Microservices) to gain development agility. As you gain development agility you introduce new operational challenges.
What are the Operational Challenges?
Now that you have split your monolithic application into a dozen of microservices, most likely you are going to have multiple instances of each microservice to fully realise the benefits of this app transformation exercise. Every time you want to bring up a new instance, you open a ticket and wait for the firewall administrator to allow traffic to that new node, this could take days if not weeks.
When you add autoscaling into the mix (so that the number of instances can dynamically scale in and out based on your traffic demands) having to wait days or weeks before traffic can reach those new instances defeats the whole point of having the autoscaling in the first place.
Long live agility!
Traditionally, firewall administrators used to retrieve the requests from their ticketing system and implement those changes via UI or CLI during a maintenance window. This results in creating an impedance mismatch with the application teams and overall slower delivery of the solutions and can also introduce an element of human error during the ticket creation process as well as the implementation of this request. If you are a network/security administrator who has recognised these problems, the likelihood is that you have already written some custom scripts and/or leveraged a configuration management platform to automate some of these tasks. Yes, this solves the problem to a certain extent, still, there is a manual handoff task between Continuous Delivery and Continuous Deployment.
Network and security teams can solve these challenges by enabling dynamic service-driven network automation with self-service capabilities using an automation tool that supports multiple networking technologies.
HashiCorp and Palo Alto Networks recently collaborated on a strategy for this using HashiCorp’s Network Infrastructure Automation (NIA). This works by triggering a Terraform workflow that automatically updates Palo Alto Networks NGFWs or Panorama based on changes it detects from the Consul catalog.
Under the hood, we are leveraging Dynamic Address Groups (DAGs). In PAN-OS it is possible to dynamically associate (and remove) tags from IP addresses, using several ways, including the XML API. A tag is simply a string that can be used as match criteria in Dynamic Address Groups, allowing the Firewall to dynamically allow/block traffic without requiring a configuration commit.
If you need a refresher on DAGs here is a great DAG Quickstart guide.
Scaling Up with Panorama
The challenge for large-scale networks is ensuring every firewall that enforces policies has the IP address-to-tag mappings for your entire user base.
If you are managing your Palo Alto Networks NGFWs with Panorama you can redistribute IP address-to-tag mappings to your entire firewall estate within a matter of seconds. This could be your VM-Series NGFWs deployed in the public cloud, private cloud, hybrid cloud or hardware NGFWs in your datacentre.
If you have read this far, why not give this step-by-step guide on how you can automate the configuration management process for Palo Alto Networks NGFWs with Consul-Terraform-Sync a try?.
For more resources, check out: