Hey everyone,

In my last post I went over how we make individual address objects in a Palo with Ansible. Following up on it, it would only make sense that we put them into a group. Why? Because object groups are amazing! They are a great organizational tool that has existed for many security appliances for a long long time.

On a slight side note, we could also put address objects that already exist into a group instead of making new ones and this can be done in large quantities through the power of a CSV. I will be making a separate post on how I do this.

So here is a link to the playbook in my Ansible PanOS Github repo.

https://github.com/danielbostock/ansible-panos/blob/master/objects/grouped_object_tasks/create_address_object_groups.yml

The vars file this utilises.

https://github.com/danielbostock/ansible-panos/blob/master/objects/vars/address_object_groups.yml

Let’s get started!

Since this playbook is essentially building off the last one we can keep this quite brief. We know that the last playbook added objects, but did you remember what I said in the last post about the “state” parameter? Well since I have already made the objects it would be silly to make them all over again, and in some cases in a production environment if they were attached to say NAT rules or routing rules their might some slight blips. If you have the parameter “state: present” chosen it won’t make the rule, indeed this the default option of pretty much all Ansible modules.

Building the Variables

Keeping true to my word from the last blog post, I am leveraging work I have already done and have copied the same vars from my last playbook with the exception of adding in the new vars and var files I will be using to create the groups.

  vars_files:
    - vars/address_objects.yml
    - vars/address_object_groups.yml

  vars:
    - panos_provider: 
        ip_address: '{{ fw_ip_address }}'
        username: '{{ fw_username }}'
        password: '{{ fw_password }}'
        api_key: '{{ api_key }}'
    - address_objects: ./address_objects.yml
    - address_object_groups: ./address_object_groups.yml

The vars file

address_object_groups:
  AddressObjectGroup1:
    address_group_name: Address_Group_Object1
    address_objects: ['Server1', 'Server2']
  AddressObjectGroup2:
    address_group_name: Address_Group_Object2
    address_objects: Server3

The dictionary layout mirrors that of the object, it is purposely done this to keep a familiar structure and allow me to continually re-use the same structure but just give the variables different names. I also find keeping a consistency in naming allows me to prevent easy typo issues which affect the playbook running correctly, but use whatever naming convention works for you, this is just how i like to operate and what I recommend as well.

Creating the groups

Here we get to the meat of the playbook and show what is actually different. This will be leveraging the PanOS Ansible Role created by Palo Alto. As I said in the previous blog post, using roles allow us greater flexibility and making playbooks more modular.

  - name: Create address object groups from vars file - address_groups.yml
    panos_address_group:
      provider: '{{ panos_provider }}'
      name: '{{ item.value.address_group_name }}'
      static_value: '{{ item.value.address_objects }}'
      commit: no
      #tag: ['Prod']
    with_dict: "{{ address_object_groups }}"

The “panos_address_group:” module is specifically what I am using in this iteration of the collection/role. So I quickly read through the panos_address_group read the docs page by Palo Alto, which reads more or less like every other Ansible documentation that I have read.

After reading through this, the parameters I needed were pretty much just like what I used previously with “panos_address_object“. I would say this is intentional with the Ansible Palo team. Which inline with how I have created my variables and what I did by copying and pasting what I did in the previous blog with “panos_address_object”. All I did was rename the module and the variables and then viola all ready to go!

FYI: I would daresay this set of parameters should cover most cases for people, though there are exceptions, so of course feel free to mould this playbook as necessary and add in parameters you see which will help achieve your goals.

The Results

I didn’t show the results in the last blog post and this was intentional as it wasn’t really that exciting to see, because well it was just making some objects, but this is a little bit more interesting as we are going to see the effects of the “state“ parameter in this result screenshot as mentioned earlier in this blog.

In my IDE the text shows up in that green color if it is already present, and you can see that confirmed in the play recap in the summary. However most other IDE’s and running from your terminal may even display it this way too.

Lets check it out on the Palo the results…

So as you can see here, I was able to put objects in two different groups, I could have mixed it up even more, and in actual fact I could have put one object in both groups if I so fancied…

The point here is, to extend my playbook to deploy it into a group as well, was not actually that hard, and was quite quick and leveraged pretty much most of what I already had done already. This is the ethos of all my playbooks and code, I want to apply the DRY principle as much as I can, and I strongly encourage you as well!

The next post, I will be discussing how we wrap up this section with adding tags to both the individual objects and the groups. I am saving this for last as it binds both these two playbooks together and will be something leveraged in most of my future object playbooks. I look forward to writing that one up and I hope you have all enjoyed reading this. Please feel free to leave me any comments about what you like, didn’t like and especially what I could do better!

Thanks for reading and God bless.