Like “orchestration”, compliance is a frequently overloaded phrase in IT -- it means very different things to different people. Ansible is frequently used in all sorts of compliance use cases, which we’ll expand on below.
Compliance can mean checking to see if a system has “drifted” from a known state, pushing a system back into line from a different state, or making it conform with a very specific set of (often security related) standards.
Too Fast, Too Furious
In emergencies, problems sometimes get fixed manually, or haphazardly, and that's dangerous - it leads to unpredictability when one system in a crowd behaves differently than others - and this problem gets increasingly more problematic as infrastructure sizes grow.
“Configuration drift” is usually a euphemism for folks making out of band changes that are not driven through the automation system. Using an automation system as the exclusive way to manage your infrastructure is the ideal mechanism for suppressing configuration drift from occuring in the first place.
Management by humans is the most common cause of “unique snowflake” systems - and while technology can help this problem, a culture of embracing automation is also required. Still, a system that can periodically come along and bump things back into alignment is a neccessity.
Advantages of Push Based Compliance
Ansible is a (in its most natural form) a push-based control system. There’s a common and unfortunate misconception that push-based systems are inferior for asserting compliance, compared to a pull-based system that periodically runs, checks in, and gets orders from a central server. This is actually quite the opposite - a push based system not only gives definitive answers about whether a system is still even reachable, it cannot be disabled by someone who has logged into the system. In fact, with Ansible, since there’s no “compliance daemon” on each managed system, there’s nothing that can fall over to stop asserting compliance - making the whole architecture increasingly more robust. The only question is how to set up Ansible to periodically remediate systems, and this is easy to do.The misconceptions are based on the fact that most people only choose to run Ansible by a conscious decision. However this doesn’t need to be the case - pushes don’t need to be human triggered, they can be invoked by tools such as Ansible Tower’s flexible scheduler, to re-apply configuration at any selected interval - for example every 30 minutes, or daily at 3AM.
Integrating Testing With Playbooks
Another advantage of Ansible in compliance cases is it’s designed as an order-based, fail-fast system that natively embraces software testing. It can be used to not only enforce policy but also to validate infrastructure integrity, as described in our testing guide - by integrating tests into playbook deployments. Once Ansible is done making sure, for example, a system is secure, it can run other tests to make sure an application is running correctly. If you need Ansible to check that a port is open, or not open, it's easy for Ansible to do that. If you need Ansible to fail if a given script doesn't return the proper return code, you can do that to. It's also trivial to engage tests from one system to remotely check the status of another.Security And Standards
Compliance can also mean ensuring systems map to specific security standards, for examples see Major Hayden’s CIS roles, or these two examples of STIG content for Ansible. PCI compliance is also a common concern. There’s no better way to know your firewall configuration is correct than periodically enforcing that it is correct, and being aware when the system tells you it had to fix that configuration back.
Another important part of any compliance initiative is that your security and compliance rules be auditable. Ansible's simple playbook language was designed for day one around that - the rules and assertions you make about your systems should be mostly readable even by people who don't use Ansible regularly - and diffs and changes in the compliance policy should be very clear and easy to read. It's hard to hide behavior in Ansible playbooks, so you can always tell what the automation is saying your systems should look like and be.
People Are Still A Factor
In a periodic remediation case, the ideal report from an Ansible run is one where it reported no changes were required. If something changed, it is important to ask questions and figure out why it had to fix something. Was it some other software adjusting the box, or was it a human logging into a machine manually? These are things that then need to be sought out and rectified, such that the machine is compliant 100% of the time, and not just only at the checkpoints when something bumps it back into place. This underscores the message - IT culture should converge on using the automation exclusively to make changes. The software can't be a silver bullet - but can be a cornerstone around which excellent practices evolve.
Check Mode / Dry Run
Finally, compliance may not always mean pushing a machine back into a desired state. It may also mean just checking. Using ansible’s “check mode” (which may be thought of as a “dry-run”), ansible can report whether specific features of a configuration are out of compliance, without making configuration changes.
Putting It All Together
In all, there are many ways which Ansible can help with compliance requirements, and in many ways, ansible’s push-based agentless architecture is ideal for the task. Not only can agents not be disabled, but affirmative reports of connectivity are automatic, and Ansible’s fail-fast linear-execution embraces including tests in playbook executions. Features like check mode are able to enable testing for compliance without requiring changes, and tools like Ansible Tower are available to store the results of all previous job runs and quickly pin down what systems may have problems needing human attention.
For more questions about using Ansible to solve compliance requirements in your IT environment, contact us at info@ansible.com.
