Compliance and Automation Using Ansible

December 16, 2014 by Jonathan Davila

Compliance is a big deal in many industries, from e-commerce and PCI, to healthcare and HIPAA, to federal government and FedRAMP. At the core, compliance is all about making sure that IT systems are secure. The controls for the various industries will inevitably have some overlap; there are fundamental security controls that (should) apply to all IT systems. However, as technology advances, even the fundamental controls need to be refreshed in order to address the ever increasing advancements in security threats. 

When the need comes for your IT environment to be both compliant and automated, Ansible makes the most sense.

Why? For simple but very powerful reasons; readability, encryption, architecture and transport.

For starters, Ansible requires the smallest architecture. In it’s simplest form, none whatsoever, just its installation on your laptop (presuming linux or OSX). Even in our enterprise offering it is a single server. With Ansible there is no notion of Masters, Slaves, Masters of Masters, etc.

Secondly, you don’t/shouldn’t need to change anything. If you run a linux shop, SSH over port 22 is probably already in place for all servers and if you’ve been doing any sort of Windows automation, you likely already have remote PowerShell access. There is no need of going through the process of changing your security posture just so you can automate IT.

“Strong encryption (e.g., AES-256) in open/validated formats and standard algorithms shall be required. Keys shall not be stored in the cloud (i.e. at the cloud provider in question), but maintained by the cloud consumer or trusted key management provider,” CSA CCM v3, Encryption & Key Management

Ansible just so happens to use AES-256 for encrypting your credentials within Tower and for encrypting your sensitive information through Ansible Vault.

We use SSH, why? It is arguably one of the most vetted and thoroughly tested mechanisms out there. The numbers also don’t lie:
SSL: 23 vulnerabilities in 2014
SSH: 0 vulnerabilities in 2014 and 2013 

A couple of competitors use SSL for encryption or use their own encryption algorithm. SSL makes sense when dealing with web server traffic; I like to think that the traffic having to do with your IT infrastructure should use a better standard. Lastly, using your own crypto…well that’s a red flag for any audit. 

Often times auditors are not hands-on technical engineers nor do they have the background. Much of the competition requires you to know how to read a programming language in order to somewhat understand what is happening, whether that is the ruby or a ruby-esque language; have fun with that audit. You’ll find that you get through compliance much easier if all auditors have to read are plain english, human-readable YAML files, as is the case for Ansible. 

If you are in compliance heavy environment, as you develop, automate and mature your IT ecosystem, Ansible makes the most sense. Granted, there is bias here, but by all means, conduct your own research. Answer these questions:

What is the most secure solution for orchestration?
What makes a process audit-friendly? What automation tools are the friendliest?
What tool will make ops and devs happy while not causing additional headaches to the security/compliance team?

We think Ansible.


Jonathan Davila

Jonathan is the Principal Architect of Automation Practice, Ansible, where he also assists in Red Hat Consulting. Before Ansible, Jonathan managed Ops for NASA HQ and was a member of two successful startups. In his free time he enjoys snowboarding, hiking and tweeting over at @defionscode.

rss-icon  RSS Feed