Configuration Management - How to Ensure Server Configuration is not changed and if changed revert back?

[endace.fra...@gmail.com]

Hi All,

This seems to be a dumb question to question to ask, but I can't seem to find what I'm looking for. Apologies in advance.

Basically, I want to ensure that changes to configuration on ansible-managed servers are tracked, and if there are unauthorized changes, revert to last known/agreed changes. 

So far, there's a lot of information about configuration management features (pushing config to the servers which works like a charm), but auditing for changes and reverting changes once changes are detected are hard to find.

Any information to lead me to the right resources will be greatly appreciated.

Kind regards,

Francis

[J Hawkesworth]

Not a dumb question, but I think the ansible way of thinking about this is probably something like the following.

You can write 'remediation' playbooks will will drag systems into a known state each time they are run, and schedule these to run.  This would have the effect of undoing any changes, and you could examine the logs to determine which tasks had had to make changes to the state described in your playbooks.

There are things around such as ARA and AWX which can present the results of ansible playbook runs into a web browser.

Personally, I reckon if your focus is on auditing such changes, and presenting such audits to auditors, you might want to look at a different tool - that's not a problem I've had to solve though, so I can't make any recommendations of other tools.

If you just need to keep systems in known states then writing playbooks that describe the state you need your systems in and running them often will get you a long way.

Hope this helps,

Jon

[Brian Coca]

Ansible itself does not have this 'built in' but it is easy enough to
do. You can run a scheduler (awx/tower/cron/etc) or 'ansible-pull'
periodically to show drift. Aside from what J Hawkesworth mentions
you can do some/all of the following:

- use the 'actionable' callback you only get output on changes or
failures, which works well with cron.
- run in dry/run + diff mode
- run as unprivileged user (will fail to 'start' a service, but then
you'll know it needs starting).
- use notification callback (mail) that notifies on failure (or with
some customization, on change)
- use callback/task to notify a monitoring application (nagios/zabbix/etc)

Even though a 'standard' system is built into Ansible, it is flexible
enough to work with existing systems.

-
----------
Brian Coca