In this tutorial we will add a Security Rule to a Device Group in Panorama using Ansible.
To follow this tutorial, it is recommended that that you are familiar with the concepts of Palo Alto Networks Next-Generation Firewalls, Security Policies and APIs.
Make sure you have a Palo Alto Networks Panorama deployed and that you have administrative access to its Management interface via HTTPS. To avoid potential disruptions, it's recommended to run all the tests on a non-production environment.
This is not required, but we suggest using virtualenv to keep your test and development environments clean. It's super easy:
Once installed, you can use the
virtualenv command to create a new virtual environment to store your packages without polluting the system library:
After the end of the tutorial you can remove Ansible and all the installed packages by removing the virtualenv directory:
You can easily add Ansible to any Python environment using
Palo Alto Networks provides an Ansible collection to facilitate working with PAN-OS API. Use
ansible-galaxy to install it:
Create a file called
vars.yml with the information of your environment:
vars.yml file contains sensitive information, we can use
ansible-vault to encrypt it:
We can use the following playbook to add a new rule to the Security Rulebase of the Device Group specified in the
vars.yml file. Note that:
- we specify
no_log: yeswhen loading the vars file, to avoid logging the confidential information loaded from the file
- in the rule no
locationis specified, this deaults to
top- the security rule will be created at the top of the rulebase
state: present, we tell
panos_security_rulethat the rule should be created if not existent
Note that we use
hosts: localhostas there is no Ansible agent running on Panorama/PAN-OS. All the commands will be executed directly on the development host and Ansible will connect to Panorama/PAN-OS using the XML API
We can now run the playbook using
ansible-playbookwill ask for the password to decrypt the
-e "ansible_python_interpreter=$(which python)"is useful when running
ansible-playbookfrom inside a virtual environment. It sets the environment variable
ansible_python_interpreterto the path of the Python interpreter used to run
ansible-playbook. Ny default
ansible-playbookuses the system Python interpreter instead of the one in the virtual environment.
The playbook we have just created also commits the configuration on Panorama when the rule is added. The
permit dns to 126.96.36.199 task triggers the
commit config handler when the state of the rule changes (the rule is added).
When we will add more config tasks to this playbook we can configure each task to notify the
commit config handler. As soon as at least one of the config task will change the config, the handler will be notified and commit will be triggered.
Our sample playbook does not define an action but a state: we are telling Ansible that the final configuration of the Security Rulebase should have the
DNS Permit as the topmost rule. If you run the playbook a second time, Ansible won't apply any change because the security rulebase will already be in the state described in the playbook. Let's try:
In the second playbook we:
- add a spyware security profile in the
- add a second security rule
The structure of the playbook is the same with an handler performing a commit only when at least one of the tasks has changed the config.
When we run the playbook, Ansible:
- adds a spyware security profile to the existing
- adds a new rule after the
- commits the config
Again, the playbook is idempotent. If we run the playbook a second time, Ansible won't change the config: