Skip to content
May 3 / Greg

Detecting/Alerting On Network Compliance Via The Ansible Automation Platform

This demo uses the Ansible Automation Platform to perform compliance checks on network infrastructure. It uses vendor agnostic settings files to allow configuration/compliance checking against different vendors/models of equipment. These playbooks aren’t just about compliance, they will do: standard configuration of the equipment, compliance testing and alerting, and also remediation.

The method I employ here isn’t the end-all be-all, but it is how a lot of folks do it. Keep in mind that every organization is different, so expect to adjust this to fit your needs.

Video Demo

Files

The Github repo with all of the files are here.

The best way to see how all of the pieces fit together is via the above video(there’s a lot explanation in there). I’m going to cover in depth a couple of specific playbooks.
First I’ll say, this is what my workflow template looks like in my ansible controller:

This corresponds to my main job templates. The order is:
– Run the pre process. This creates a blank file I refer to as the compliance file. As I run though the other playbooks they will fill this file out with anything non compliant.
– NTP configuration playbook. In this one it will determine if it is a Cisco or Arista device, then configure NTP servers based on a regionalized configuration files. If it’s in “compliance mode” it will fill out the compliance file.
– SNMP configuration playbook. This is much the same as the NTP playbook only it’s configuring SNMP community strings.
– The post processing playbook checks if the compliance file is empty. If it is, it does nothing. If there are entries, then that means there were non compliant entries, so it connects to servicenow and generates an incidence based on the contents of the file.

For NTP I first hit this playbook:

In here I’m really looking at the inventory object for each host and determining what network_os they are running. If it is Cisco I call the Cisco specific task file, and if it is Arista, I pull the Arista specific task file.

This is the Cisco specific task file:

In here I build several variables: one variable consists of the currently configured NTP servers on the device, another is the imported server(my source of truth), I then build a variable that is the command format for the new servers(ntp server x.x.x.x), and last I do a diff on the existing and the SoT to find out what servers exist and need to be removed.
I then remove the non compliant servers, and add any servers that should be in place.
If the playbook is run in check mode(a condition where I verify what changes WOULD be made) and I have the “compliance_check” variable defined, then I’ll start the compliance code block. Here I find anything that should be removed and add an entry to the compliance file. Last I find anything that should be added and add it to the compliance file.

Here’s an example of the NTP server file. Again, this is stored as just the raw servers, so it’s easy to take the servers and apply them to each vendors configuration format.

I then do the same for SNMP and last I hit this file for post processing:

In here I load the contents of the compliance file into a variable. If the variable has entries I then use the new ServiceNow collection to create an incident in SNOW with the contents of the file.

Conclusion

While I could create a playbook just for compliance, it is a waste of time/resources for me to do so. If I make one playbook that can provision, detect/alert on compliance, and then perform remediation all with just a little bit of additional effort, then I’m going to do so.

If you would change this for your environment, let me know, I’d like to see how your environment differs.
As always, thanks and happy compliance 😉

Leave a Comment

 

*