!! Check out the new Discussion Forum . For general Q&A I prefer the forum to opening issues.
The Cloud Firewall Debate
Terraform Plan
Terraform Mechanics
Understanding the VNET topology
PAN Bootstrap notes
Etc
References
Q&A
(if you want to skip the debate --> here )
Cloud-native network access controls are maturing. Eventually, this debate will be long dead. In the near-term, we are likely to keep using virtual machine based firewalls in public cloud infrastructure. Let's start by reviewing some of the use cases where VM firewalls beat out their cloud-native cousins.
- Hybrid deployments in which both premise and public cloud workloads function together in a blended architecture. Typically these deployments will have central management capabilities utilizing shared objects and policies.
- Use of access control policies that require the use of dynamically resolved FQDNs, URLs, publicly or privately maintained dynamic IP or URL lists, and applications.
- VM firewall logging capabilities often includes additional detail not found in cloud-native logging. For instance, PAN VM firewalls logging can extract URLs from HTTP requests and provide application identification.
- And not to be forgotten, circumstances sometimes force the wholesale migration of brownfield workloads into the cloud with little to no modification. It's an imperfect world. ¯_(ツ)_/¯
There are pleny of other options including:
- Web proxies either hosted or cloud Secure Web Gateway's (e.g., Zscaler)
- Cloud native access policies
- Cloud native firewall services
- Identity centric architecutre ? (e.g. Gartner SASE)
Pro
- Highest Bandwidth
- Lowest Latency
- Varies by platform, but generally well integrated with cloud workloads (e.g. using dynamic tags to define workload policies)
- All layer 3 protocols supported
Con
- No hybrid capability
- Lack of standard central mgmt capabilities such as shared objects used in multiple rules across many devices
- Typically poor support for FQDN resolution, incorporation of dyanmic address/fqdn/URL lists, granular application specific policies
- While all traffic can be logged, the logging is typically limited to basic source - destination tuples.
Pro
- Hybrid deployment supported
- Centralized mgmt tools
- Granuluar policies
- Indepth logging
- Low latency overhead
- All layer 3 protocols supported
Con
- Limited cloud integration, PAN offers a Azure plugin that handles dynamic workload information in policies
- Bandwidth is limited vs. compared to native ACL
Pro
- Simplest to manage
- Hybrid support (by virtue of being offered as SaaS)
- Detailed logging
Con
- Limited to select protocols
- Bandwidth
- Latency
- Cloud integration
In Emoji form:
Attribute | Native ACL | VM Firewall | Secure Web Gateway |
---|---|---|---|
Latency | 🏅 | 👍 | 🤨🤨 |
Policy | 🤨 | 🏅 | 👍 |
Logging | 👍 | 🏅 | 👍 |
Throughput | 🏅 | 👍 | 👍 |
Integration | 👍 | 👍 | 🤨 |
At the most basic level, this plan deploys an Azure VNET with a fictional topology (public and private subnets, etc.), along with a single PAN VM series firewall. The firewall configuration is installed via the PAN bootstrap process. The bootstrap process can use either a pre-built firewall configuration stored in a file or using a PAN Panorama central mgmt server. If you would like to manually configure the firewall, remove the bootstrap parameters from custom_data related to the bootstrap process.
If you plan to deploy an application architecture that includes a PAN firewall using a CI/CD build process, certainly, you will automate the firewalls device configuration and policy creation. Kudos to Palo Alto for giving developers multiple ways to implement automation. Panorama is a good(ish) tool for automating policy deployment. If you are interested in configuring the PAN firewall via Terraform check out the PANOS resource module for Terraform here. Also, check out the Palo Alto Networks Github page for examples of other methods including Ansible and Python.
There are a wide variety of approaches to using Terraform with Azure. When developing a testbed environment, I prefer to use VSCODE w/the Terraform & Azure extensions. In this setup, Terraform execution occurs in the Azure Cloud Shell service. The Cloud Shell service stores the TF state file on the Azure Clouddrive service. Azure Recovery Service can be used to backup the Clouddrive containing the TF state file. VSCODE w/Azure+Terraform instructions are here: Configure the Azure Terraform Visual Studio Code extension
If you are interested in the big picture view as to how to use Terraform to drive to Infrastructure as Code operations read this.
As the diagram depicts, East-West traffic between the public and private subnets, does not use the VM firewall. The VM firewall is positioned to handle North-South traffic between the Internet and the private subnets. An Azure Network Security Group (NSG) is used to control network policy between the private and public subnet. This is not an endorsment of any single architecture. But intended to be a good example that blends together multiple concepts.
The plan creates a single route table containing only a default route that directs Internet bound traffic to the firewall. I wanted to keep this example easy to understand, but most live environments will be more complicated. It would be normal in a real-world use case to have connections to other private environments using an SD-WAN VM, VM firewall IPSEC tunnels, or the native Azure VPN Gateway.
The next diagram provides a bit more detail about the mapping between public IPs <-> VNICs <-> PAN interfaces.
This bit of TF code within the azurerm_virtual_machine code block controls mapping of VNICs to PAN OS.
primary_network_interface_id = azurerm_network_interface.FW_VNIC0.id
network_interface_ids = [azurerm_network_interface.FW_VNIC0.id,
azurerm_network_interface.FW_VNIC1.id,
azurerm_network_interface.FW_VNIC2.id ]
The ordering of the azurerm_network_interface resources in the network_interface_ids assingment controls how they are enumerated in PAN OS.
The bootstrap process allows a newly provisioned PAN VM firewall to either load a pre-built firewall configuration or register itself with a Panorama mgmt server and have its device config and policies pushed down to it. The config files needed to initiate the bootstrap process are stored in an Azure storage account.
I have provided a pre-built bootstrap.xml firewall config file tailored to this VNET topology, the config file permits all outbound traffic with appropriate logging, threat/URL category blocking, and other system settings configured.
- Create a Azure storage account.
- Create a file share in the new storage account named bootstrap.
- In the bootstrap file share create the following folder structure:
- In the bootstrap-file-based repository folder upload the init-cfg.txt and bootstrap.xml file to the config folder in the storage account.
- Update the pan.tf file with the correct parameters to allow the PAN VM to authenticate and download the init-cfg.txt and bootstrap.xml file. There are 3 parameters that must be passed to the new VM via the custom_data data block "storage-account", "access-key", "file-share". This is section of the pan.tf file from the repository:
os_profile {
computer_name = var.FirewallVmName
admin_username = "yourusername"
admin_password = "yourpassword"
custom_data = join(
",",
[
"storage-account=<storage account name>",
"access-key=<storge acct access key>",
"file-share=bootstrap",
"share-directory=None"
],
)
}
- storage-account and access-key can be both be retrieved via the Azure portal. Locate the storage account you created and click on the Access Keys menu.
- share-directory is "bootstrap" because that is what suggested it be named in step 2
- (Optional) The bootstrap content folder can be populated with threat data files. These can be downloaded from the PAN support portal here Dynamic Updates.
- (Optional) The example is configured with a pay-as-you-go license (sku=bundle2), a bring-your-own license can be deployed by switching the sku and plan paramter in the pan.tf to "byol". Also the bootstrap license folder must be populated with a authcodes file that contains the authcode for the firewall being deployed.
- The bootstrap.xml file has a default admin username and password configured which should be changed after initial login. See the Readme
If you have a Panorama server already configured and want the firewall to register with it to receive a centrally managed config a couple additional things must be done.
- Use the init-cfg.txt from the bootstrap-panorama folder.
- Before uploading init-cfg.txt edit these 2 parameters.
vm-auth-key=1234567890
panorama-server=1.1.1.1
- "vm-auth-key" is generated on the Panorama server from the command line using the following procedure.
- "panorama" is the public IP address of you Panorama server. (Note: TCP port 3978 and 28443 must be allowed inbound to the Panorama server)
- A note on two other parameters in the init-cfg.txt file. "tplname" and "dgname" these are the template name and device group name configured in Panorama. This is how you fully automate configuration via Panorama using bootstrap. If you have already created a device template stack and defined device policies you can populate these two fields.
- Update the init-cfg.txt sample file with your auth key and the panorama server IP address, then upload it to the config folder.
- The pan.tf file has several !!!Change Me!!! variables, make sure to replace with the required values.
- The main.tf has a code block at the end that is commented out. It builds a Windows 10 VM, use the bastion host service to remotely access the VM. I use it for testing the completed deployment.
Multi-Cloud Security Automation Lab Guide
PaloAltoNetworks Repository of Terraform Templates
Terraform Azure
Gartner SASE
News from the bleeding edge
Hashicorp Boundary
Announcing Consul Terraform Sync Tech Preview
New GKE Dataplane V2 increases security and visibility for containers