Adding a Security Rule
In this tutorial we will add a Security Rule to a Device Group in Panorama using Ansible.
#
RequirementsTo 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.
#
Setup your environment#
Install virtualenv (optional)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:
#
Install AnsibleYou can easily add Ansible to any Python environment using pip
:
#
Install Ansible collection for PAN-OS APIPalo Alto Networks provides an Ansible collection to facilitate working with PAN-OS API. Use ansible-galaxy
to install it:
#
Add your environment variablesCreate a file called vars.yml
with the information of your environment:
The vars.yml
file contains sensitive information, we can use ansible-vault
to encrypt it:
#
Your first playbook#
Create a security ruleWe 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: yes
when loading the vars file, to avoid logging the confidential information loaded from the file - in the rule no
location
is specified, this deaults totop
- the security rule will be created at the top of the rulebase - with
state: present
, we tellpanos_security_rule
that the rule should be created if not existent
Note that we use
connection: local
andhosts: localhost
as 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-playbook
:
when
--ask-vault-pass
is used,ansible-playbook
will ask for the password to decrypt thevars.yml
file
-e "ansible_python_interpreter=$(which python)"
is useful when runningansible-playbook
from inside a virtual environment. It sets the environment variableansible_python_interpreter
to the path of the Python interpreter used to runansible-playbook
. Ny defaultansible-playbook
uses the system Python interpreter instead of the one in the virtual environment.
On Panorama:
#
CommitThe playbook we have just created also commits the configuration on Panorama when the rule is added. The permit dns to 1.1.1.1
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.
#
IdempotencyOur 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:
#
Second playbook#
One more ruleIn the second playbook we:
- add a spyware security profile in the
DNS Permit
rule - add a second security rule
after
theDNS Permit
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.
#
TestWhen we run the playbook, Ansible:
- adds a spyware security profile to the existing
DNS Permit
rule - adds a new rule after the
DNS Permit
- commits the config
On Panorama:
#
IdempotencyAgain, the playbook is idempotent. If we run the playbook a second time, Ansible won't change the config: