Using Ansible for compliance checking

Archives Ansible Project
1

Hello Folks,

I’m working on a configuration management proposal for a client at the moment - and I’m planning on using Ansible (I have ‘prior’). Part of their requirements is patching - and having done something similar in the past with Puppet, I was planning on looking at doing patch management with Ansible too. Again, I’m fine with working that out.

They’d also like to be able to review their estate for compliance - initially it’ll be package versions, I guess (they’re an RPM shop). I’m pondering if I could also do this bit with Ansible - but off hand I can’t imagine how I’d approach that.

Does anybody have any thoughts and/or experience? Is it a daft thing to even contemplate? Am I thinking of pushing a square peg into a round hole?

Any input will be greatly appreciated.

–Mark

2

You could create a fact module that gathers facts about what packages are installed (essentially an rpm -qa stuffed into a dictionary).

This information can be used in fail tasks to fail if the appropriate packages are not installed.

This would be different than the normal operation of Ansible, which would be to just state that you wish certain packages be installed, and Ansible would tell you if they already are, or install them if they aren't.

-jlk

3

Thanks Jesse, nice idea. I’d have to test the performance of it - my first
thought is it will cane every run unless most roles have gather_facts set
to false.

But, that is a nice start. Thank you for the suggestion.

4

gather_facts is a play level directive, not role.

In any case the standard facts module does not support this, you can create your own facts module you run as a task or a script in /etc/facts.d/ that would be run by the standard facts module.

5

I would recommend that you use Ansible to do the patching and updating but use serverspec (serverspec.org) to do the compliance checking. They work well together and this uses each for its intended purpose.

–Aaron

6

I disagree, as it’s not a compliance testing framework, it’s intended to do a particular variety of basic tests.

Compliance is more about checking for drift between unlike systems, and being able to do very good reports on them and then select systems based on certain criteria.

We’ll be doing some things here in the near future, part of the steps to get here are to either have a fact caching system or use a callback to record facts, another step is to supplement our existing setup module with some modules that calculate a bit more inventory.

7

And that’s precisely what the client, in this particular case, wants Michael. So yes, please do hurry along and get it in the product :wink:

Reporting is the key thing, especially for management types. Just being able to see the state of their systems is a good start, because then it can easily be confirmed if a process is being adhered to (or not).

8

What is the proper way to express f(g(const)) where f and g are variables in task files?

Example:
vars:
git_merge_tool: meld
merge_tools: { ‘meld’: { ‘path’: ‘/usr/local/opt/meld/bin/meld’ }, }
tasks:

I tried this

  • name: Create symlinks to the git tools
    file: state=link src=“{{item.src}}” dest=“{{item.dest}}”
  • { src: “/usr/local/bin/{{git_merge_tool}}”,
    dest: “{{merge_tools[git_merge_tool[‘path’]]}}” } ← this is the problem

fatal: [ansible-os1] => One or more undefined variables: dict object has no element Undefined

And this

  • { src: “/usr/local/bin/{{git_merge_tool}}”,
    dest: “{{merge_tools[{{git_merge_tool}}[‘path’]]}}” }

NO ERROR: but creates a link to the string {{merge_tools[git_merge_tool[‘path’]]}}

And even this

  • { src: “/usr/local/bin/{{git_merge_tool}}”,
    dest: “{{merge_tools | attr(git_merge_tool) | attr(‘path’) }}” }

TASK: [git | Create symlinks to the git tools] ********************************
fatal: [ansible-os1] => One or more undefined variables: ‘dict object’ has no attribute ‘meld’

Are nested vars supported in ansible task files?

kesten

9

The following works for me. I changed a few things to be more yaml like, but I think the heart of your issue was the way you were referencing the nested data:

vars:
git_merge_tool: meld
merge_tools:
meld:
path: ‘/usr/local/opt/meld/bin/meld’
tasks:

  • debug:
    msg: “{{ merge_tools[git_merge_tool][‘path’] }}”

You were using:

merge_tools[git_merge_tool[‘path’]]

I believe you had one of you ] chars in the wrong place. It should have come immediately after ‘git_merge_tool’ rather than at the very end.

It should have been:

merge_tools[git_merge_tool][‘path’]