Managing Network ACL's With Ansible

Managing Network ACL's With Ansible

This is a quick glimpse at a production application of Ansible to automate your infrastructure Access-Control-Lists.

Access-Control-Lists

Aceess-Control-Lists (ACLs), along with route-maps and prefix-lists, are commonly used to secure a number of critical network functions such as:

  • Controlling remote access
  • Controlling SNMP polling
  • Filtering traffic
  • Controlling route redistribution
  • Restricting prefix advertisements
  • Enforcing security policies

ACLs used in the above functions can often be standardized across a subset of network nodes, if not the entire network, but keeping them up to date becomes an unwieldy task. Enter Ansible.


Ansible ACL Management

The below Ansible Playbook will configure standard access-lists for controlling our SNMP security, by matching all SNMP polling sources against an "SNMP_Access" ACL.

Because our network inventory feautures a mix of IOS and IOSXR devices, I am using the ios_config and iosxr_config Ansible modules conditionally to ensure that the ACL entries match the lines specified in the Playbook, and any discrepancies will then be configured by Ansible:

ACL_Management.yml

The OS detection does require some creativity within your Ansible inventory file or vars (be it host_vars or group_vars), but the benefit is that you can construct singular Playbooks for a range of inventory hosts or various platforms:

/etc/ansible/hosts

Here, I am tagging the OS parameters within my /etc/ansible/hosts file, and specifying encrypted connection methods within the respective group_vars:

/etc/ansible/group_vars/ios.yml

Running the Playbook against my two test nodes will produce the following recap report. From here we can see that both Ansible tasks were completed successfully (failed=0), and that changes were made to the configuration (changed=1):

Successfully Changed!

And verifying on the remote Hosts, we can indeed verify that the SNMP_Access ACLs were configured successfully:

Because Ansible is a "desired-state" automation framework, we can run this Playbook again and no changes would be made because we have already matched the configuration state as outlined in the Playbook.

If I wish to add additional host addresses into our configured Access-Lists, I can simply include these into my Playbook tasks:

ACL_Management.yml

Running again, I can see that Ansible is making changes accordingly:

COWSAY???

If cowsay is installed, Ansible takes it upon itself to make your day happier when running playbooks.  If you decide that you would like to work in a professional cow-free environment, you can either uninstall cowsay, set nocows=1 in ansible.cfg, or set the ANSIBLE_NOCOWS environment variable... - Official Ansible Docs, 2019

And logging on to our end devices, I can verify that my Access-Lists were updated successfully:

When you are confident to finally run your Playbook network-wide, you may be greeted to a view like this:

Recap

And if you are, well done.


Use Ansible everywhere

This is a quick look at automating the management of SNMP access to your infrastructure through Ansible, but this very same Playbook can be tweaked very easily to be repurposed for managing remote SSH-access ACLs, BGP prefix lists, route-redistribution route-maps, NTP filters, and so on...

Thanks for reading!

Related Article