In this blog post, we will look at how to bootstrap Palo Alto firewalls in AWS. Bootstrapping is a method that simplifies the deployment of new VM-Series firewalls in your network or cloud environment. This blog post assumes you are somewhat familiar with AWS, Palo Alto and IaC tools like Terraform.
When launching a Linux instance in AWS for example, the process doesn't stop at just initiating the instance. After launch, there's still a need to log in and set up basic configurations and install necessary packages. In a cloud environment, this is often done using tools like Terraform for launching instances and Ansible for managing configurations.
The same principle applies when launching a firewall in AWS. You need to configure essential details like which Panorama the firewall should connect to, the authentication codes to use, and the licenses that need to be applied. While it's possible to log in to each firewall and set these up manually, this method becomes impractical when dealing with dozens of firewalls.
In the cloud, agility is key. There may be situations where you need to quickly destroy the current firewalls and set up a new batch. This demands an automated method to pass the minimum necessary configurations to the firewall right at boot-up. Such an approach ensures efficiency, consistency, and speed, especially in dynamic cloud environments where quick adaptation is often required.
Things to Include in the Bootstrap Files
Bootstraping is essentially about loading essential information into files and passing it to the firewalls at launch. This includes details like the Panorama IP, licenses, latest content updates and other important information. Let's dive into each of these in more detail to understand their roles and significance in the bootstrapping process.
Here, we're also operating under the assumption that you'll be using Panorama to manage your firewalls. Panorama acts as a centralized management tool, overseeing the configuration and administration of firewalls from a single point.
Imagine launching five firewalls in AWS. Consistency is crucial here; you want all these firewalls to have identical configurations. Manually managing each one would be time-consuming and prone to errors. This is where Panorama proves invaluable. It ensures that all firewalls are uniformly configured and managed.
For those familiar with Panorama, you're aware that adding firewalls to it involves assigning them to specific device-groups and templates. By using bootstrap files, you can automate this process even further. These files can contain the IP addresses of the Panorama, and the names of the device-group and template each firewall should associate with. When the firewalls are launched, they automatically connect to Panorama and add themselves to the correct device-group and template.
Software NGFW Credits
Please note that if you decide to to pay-as-you-go licenses, then you can skip this section.
Software NGFW credits can be used to fund the VM-Series firewalls. The way it works is that you pre-purchase the NGFW credits and then use them with your VM-Series firewalls. You can use the NGFW Credit Estimator to calculate the number of credits required for your deployment.
You then create a deployment profile to configure one or more firewalls based on the number of vCPUs per firewall, the total number of firewalls supported by the deployment profile, Panorama management or log collection, and security services. The Credit Estimator allows you to estimate the credits required to license the firewalls and enable the security services needed to secure your deployment.
As shown below, you need approx 70 credits to launch 5 firewalls with 2 vCPUs and enable some security features.
The created deployment profile contains an 'authcode'. You then pass this authcode in the bootstrap file so, the firewalls can connect back to Palo Alto Portal and associate them with the deployment profile.
Retrieve Licenses Automatically at Launch
The firewall requires a device certificate to retrieve the site license entitlements and securely access cloud services such as WildFire, AutoFocus, and Cortex Data Lake. There are three methods for applying a site license to your VM-Series firewalls, One-time password, autoregistration PIN, and through Panorama for managed firewalls. We will be using autoregistration PIN for this example.
To retrieve the site licenses when you launch the firewall, you must include the auto registration PIN ID and value in the bootstrap parameters. You can create them via the Customer Support Portal.
You also need the latest contents updates for the firewall. This is not really mandatory but I've had issues launhcing the firewalls without the latest content files. You can download the latest contents from the support portal and upload it to the S3 bucket
content bootstrap folder.
Back to Bootstrap Files
Now that we have an idea of what information need to be passed as bootstrap files, let's look at how to structure them and keep.
The bootstrap package must include the /config, /license, /software, and /content folders, even if they are empty. The /plugins folder is optional.
- /config folder—Contains the configuration files. The folder can hold two files,
bootstrap.xmlfile contains a complete configuration for the firewall. If you are not using Panorama to centrally manage your firewalls, the
bootstrap.xmlfile provides a way to automate the process of deploying firewalls that are configured at launch.
- /license folder—Contains the license keys or authcodes for the licenses and subscriptions that you intend to activate on the firewalls. (authcode basically)
- /software folder—Contains the software images required to upgrade a newly provisioned VM-Series firewall to the desired PAN-OS version for your network. Even though the document says this folder is mandatory, I was able to bootstrap the firewalls without having this folder.
- /content folder—Contains the application and threat updates.
If you want to learn how to upload these files and directories to S3 using Terraform, please check out my other blog post below.
As we are deploying the firewalls in AWS, it would make sense to put the files in the S3 bucket. You need to ensure that you add appropriate permissions for the firewalls to read the S3 bucket.
- The management interface of the VM-Series firewall must be able to access the S3 bucket to complete bootstrapping.
- Create an IAM role with an inline policy to enable read access to the S3 bucket [ListBucket, GetObject]
- When you create the firewalls, assign this IAM role to the firewalls.
- Finally, create the folders within the S3 bucket (
suresh@mac:~/Documents/create_s3|⇒ s3-tree palo-bootstrap-contents palo-bootstrap-contents ├── config │ └── init-cfg.txt ├── content │ ├── panupv2-all-contents-8686-7925 ├── license │ └── authcodes └── plugins
init-cfg.txt file is required to bootstrap the VM-Series firewall and placed under the
config directory. It provides the basic information the firewall needs to connect to your network. If you want to learn more about all the parameters supported in the file, please check the official guide here. Here is a sample file that contains the bare minimum of information that the firewall needs.
type=dhcp-client dhcp-send-client-id=yes dhcp-accept-server-hostname=yes dhcp-accept-server-domain=yes panorama-server=10.10.10.10 panorama-server-2=10.10.20.10 vm-auth-key=4567645678 tplname=my_test_template dgname=my_test_dg op-command-modes=mgmt-interface-swap plugin-op-commands=aws-gwlb-inspect:enable vm-series-auto-registration-pin-id=xxxx-xxxx vm-series-auto-registration-pin-value=xxxx-xxxx
Most of them are self-explanatory but here is the explanation for the rest (2nd and 3rd are necessary if you use the firewalls with GWLB)
- vm-auth-key - If you want to use Panorama to manage the VM-Series firewalls that you are bootstrapping, you must generate a VM auth key on Panorama. The VM auth key allows Panorama to authenticate the newly bootstrapped VM-Series firewall. You can generate one by running
request bootstrap vm-auth-key generate lifetime <1-8760>command on Panorama.
- op-command-modes=mgmt-interface-swap - Swaps eth0 and eth1. GWLB by default, sends traffic only to Eth0 of its target instances. By swapping, Eth0 becomes the data interface and eth1 becomes the management interface.
- plugin-op-commands=aws-gwlb-inspect:enable - Enables the VM-Series firewall to process traffic passing through a GWLB.
The license directory holds the authcodes file as we discussed before, The authcode is used to register the VM-Series firewall. The file
authcode just contains a single line that has the authecode we get from the deployment profile.
Before wrapping up, it's important to note that Palo Alto supports two types of bootstrapping, basic and complete configuration. The basic method is simpler, as it doesn't require maintaining multiple files or directories. You only need the
init-cfg.txt file. This file's content can even be passed as 'user data' or stored as key-value pairs in tools like AWS Secrets Manager.
However, there's a trade-off with the basic method, you can't pass any 'contents', such as the latest updates. From my experience, launching firewalls without these latest updates can lead to issues. That's why, despite the added complexity, I often opt for the complete method. It ensures that the firewalls are up-to-date and functioning optimally right from the start.