Proposal - Variable for each rule or stig ID in roles

[Daniel Shepherd]

I wanted to get the groups input on the following proposal submitted on the RHEL7-CIS repo. https://github.com/MindPointGroup/RHEL7-CIS/issues/26

joaogbcravo is suggesting/requesting that we add a variable for each rule in the STIG or CIS role. This would make it easier to run specific rules or to enable disable specific rules in a users local copy of the repo so that the exact set of rules that are applied is captured in VCS. I see the merits of this since doing it with tags is not ideal. If we do it for this role I would suggest we add it to the spec for all verified roles going forward.

The problems with it are that it adds A LOT of variables to roles that are already variable heavy and adds some to maintenance when benchmark updates come out. Please let me know what you think. If no one has an opinion I'm inclined to move forward with it.

Thanks,

Dan

[Bas Meijer]

Hi,

Sounds like a good idea. Lots of (boring bulk) work though. Adding another thing I miss in the roles, and which would improve the auditability is  "--skip-tags unimplemented" for all the actions that have no patch. 

Bas

@bbaassiiee

--
You received this message because you are subscribed to the Google Groups "Ansible Lockdown" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-lockdo...@googlegroups.com.
To post to this group, send email to ansible-...@googlegroups.com.
Visit this group at https://groups.google.com/group/ansible-lockdown.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-lockdown/520ae9e6-b2b8-4245-bdfc-071f610430bd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jonathan Davila]

Let me play devil's advocate for a second. Given:

Premise: You cant spec rules you apply via source control because selecting rules is tags driven.

Argument: Adding a variable based condition to each task would allow for tracking implemented rules via a vars file

Would it not be easier (effort/maintenance) to simply version control a shell script wrapper with your playbook?

Example:

#!/bin/bash
ansible-playbook hardening.yml --tags rule1,rule2,rule3

Im not 100% against the proposal but I think the above is 'easier' to advise for from purely a maintainer perspective and shouldn't present too much difficulty even for the most junior of administrators. It is something that would be easy to check in to version control as well. Thoughts?

On a separate note, I do like Bas' idea of an unimplemented tag.

Just my 2c.

On Wednesday, May 3, 2017 at 6:03:05 PM UTC-4, bbaassssiiee wrote:

Hi,

Sounds like a good idea. Lots of (boring bulk) work though. Adding another thing I miss in the roles, and which would improve the auditability is  "--skip-tags unimplemented" for all the actions that have no patch. 

Bas

@bbaassiiee

On 3 May 2017, at 23:53, Daniel Shepherd <dan...@mindpointgroup.com> wrote:

I wanted to get the groups input on the following proposal submitted on the RHEL7-CIS repo. https://github.com/MindPointGroup/RHEL7-CIS/issues/26

joaogbcravo is suggesting/requesting that we add a variable for each rule in the STIG or CIS role. This would make it easier to run specific rules or to enable disable specific rules in a users local copy of the repo so that the exact set of rules that are applied is captured in VCS. I see the merits of this since doing it with tags is not ideal. If we do it for this role I would suggest we add it to the spec for all verified roles going forward.

The problems with it are that it adds A LOT of variables to roles that are already variable heavy and adds some to maintenance when benchmark updates come out. Please let me know what you think. If no one has an opinion I'm inclined to move forward with it.

Thanks,

Dan

--
You received this message because you are subscribed to the Google Groups "Ansible Lockdown" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ansible-lockdown+unsubscribe@googlegroups.com.
To post to this group, send email to ansible-lockdown@googlegroups.com.

[Daniel Shepherd]

With a huge number of rules in each benchmark (~500) though the list of tags would potentially be very very long. Also, I think looking at a YAML file seems much friendlier than a list of comma separated tags. The wrapper script wouldn't translate over to folks using Tower correct? I guess they would just need to configure their job template and put all the tags in though.

I guess I still fall on the side of adding the variables...even with the increase in maintenance work it might introduce. I think for STIG content it won't be that bad and it may have the added benefit of allowing us to track specific versions of the STIG just by enabling/disabling the new or removed STIG items. For CIS content it might not be as beneficial...especially if they decide to completely reorganize their benchmark numbering scheme again like they did a couple years ago.

I'm for the unimplemented tag as well.

Dan

On Wednesday, May 3, 2017 at 7:43:28 PM UTC-4, Jonathan Davila wrote:

Let me play devil's advocate for a second. Given:

Premise: You cant spec rules you apply via source control because selecting rules is tags driven.

Argument: Adding a variable based condition to each task would allow for tracking implemented rules via a vars file

Would it not be easier (effort/maintenance) to simply version control a shell script wrapper with your playbook?

Example:

#!/bin/bash
ansible-playbook hardening.yml --tags rule1,rule2,rule3

Im not 100% against the proposal but I think the above is 'easier' to advise for from purely a maintainer perspective and shouldn't present too much difficulty even for the most junior of administrators. It is something that would be easy to check in to version control as well. Thoughts?

On a separate note, I do like Bas' idea of an unimplemented tag.

Just my 2c.

On Wednesday, May 3, 2017 at 6:03:05 PM UTC-4, bbaassssiiee wrote:

Hi,

Sounds like a good idea. Lots of (boring bulk) work though. Adding another thing I miss in the roles, and which would improve the auditability is  "--skip-tags unimplemented" for all the actions that have no patch. 

Bas

@bbaassiiee

[sdo...@redhat.com]

I was out on vacation last week so sorry I didn't chime in earlier.

After mulling this over a bit, I think I'm also on the side of adding variables for multiple reasons:

• variables can be version controlled in a "cleaner" fashion than a wrapper script
• variables also have the added benefit of being able to be applied via group_vars, allowing the codification of different settings being applied to different groups of hosts — not something that can be easily accomplished with tags
  
• variables translate seamlessly to Ansible Tower whereas tags would require extra work, i.e., defining the tags in job templates
• variables would also give the ability to use template files with conditional sections rather than many individual lineinfile tasks

One thing to note on the CIS proposal: variables cannot contain dots. It's probably ok to just translate dots to underscores.

I like the idea of an unimplemented tag, but better than that would be removing the need for it at all. Removing the audit tasks is something I plan to do to reduce noise and execution time. Documenting the unimplemented findings external to the role in an auditor friendly file would be a better way to capture these items.

---

Sam

[Bas Meijer]

On removing the audit tasks: a good benchmark input to scap would create an independent audit, nice for compliance reasons, and saving a lot of work in implementing the roles.

For example: https://github.com/dockpack/dockpack/blob/master/ansible/security_audit.yml

Bas

@bbaassiiee

--
You received this message because you are subscribed to the Google Groups "Ansible Lockdown" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ansible-lockdo...@googlegroups.com.
To post to this group, send email to ansible-...@googlegroups.com.

Visit this group at https://groups.google.com/group/ansible-lockdown.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-lockdown/66ebec4e-965e-4df2-b620-ceb5dc19dbd1%40googlegroups.com.