Closed ghost closed 3 years ago
Thanks for the report. I think the tagging needs a thorough review/clean up at this point!
Hmm I trying to think the best way to handle the tagging. Looking back at this issue it seems that the original report included two distinct problems.
1) Things in this role are not tagged consistently. (scored/not scored)
2) Running the play with --tags=level1, scored
runs some not scored
items.
The second item above is an issue because that is not the way tags work in Ansible. Running --tags=level1, scored
will run all tasks with either tag. i.e. it would run level1 notscored
items because they are tagged level1
. The proper Ansible tags way to run just scored level1 items would be something like --tags=level1 --skip-tags=notscored
However this would require the tagging to be consistent, and it is not currently.
The other problem I see with the tagging is that, in addition to scored/not scored, the CIS benchmark has this notion of level1/level2 and further complicates it by having different values for server/workstation. I say all this because I think we need to pick something standard before applying tags across the board. @brydoncheyney has started applying tags in #101 so I think now is a good time to solidify the approach.
imo I think it makes sense to tag things with very specific tags. i.e. a rule with the following attributes: Scored Level 1 - Server Level 1 - Workstation
Would get tagged:
- scored_level1_server
- scored_level1_workstation
Another task: Not Scored Level 1 - Server Level 2 - Workstation
- scored_level1_server
- scored_level2_workstation
This means you can run the below command and be sure that only scored level1 server rules will be run and nothing else.
ansible-playbook playbook.yml --tags scored_level1_server
The other option as I see it:
- scored
- level1_server
Then people would need to run:
ansible-playbook playbook.yml --tags level1_server --skip-tags notscored
The second option is probably more flexible but people need to be aware of how tags work with Ansible and how to exclude tags.
@bbaassssiiee Would appreciate your opinion on how people use tags with this role as well.
Indeed, people would need to run:
ansible-playbook playbook.yml --tags level1_server --skip-tags notscored
And people need to be aware of how tags work with Ansible and how to exclude tags.
I think that being forced to use both --tags
and --skip-tags
in order to apply arbitrary mixes of level and score (and server/workstation!) is not intuitive.
The use of composite tags, scored_level1_workstation
, is explicit but could suffer from a potential combinatorial explosion if any dimension grows... which seems unlikely(?).
A possible solution is to break down the dimensions in some other way. For example, different playbooks or roles for server and workstation, reducing the tag space to scores and levels. Dimensions could also be defined by variables, e.g.
ansible-playbook server.yml --tags level1 --extra-vars="cis_scored=True"
In fact, the use of variables instead of tags may allows tasks to make use of the conditional logic we require?
- name: SCORED | 1.x.x | ... Level 1 ...
task:
args: ...
when:
- scored
- level1
- name: NOTSCORED | 1.x.y | ... Level 1 and Level 2 ... workstation ...
task:
args: ...
when:
- notscored
- workstation
(unsure why rules are presently toggled on both tags and variable conditionals?)
(unsure why rules are presently toggled on both tags and variable conditionals?)
Flexibility. An option to turn off specific rules via the var file and not having to use tags for day to day runs (translates to new OS builds at our site) has proven less error prone in practice.
We have a scanner appliance that takes in a audit file based on the entire CIS benchmark. As a result I run as many rules as possible, vars file tweaked as needed, and then any "localized" changes are in a playbook tacked on at the end of the run.
I really only use tags when code evolves in one particular area and I need to redeploy those specific changes.
I agree with your concerns here but I see the solution as simply adding the necessary amount of vars and tags needed to run the playbook according to your site requirements.
Yes the use of variables in generally the preferred/recommended way to enable/disable rules or groups of rules. Tags still have their uses as @erpadmin points out.
Ultimately I think to correct the tagging we should make sure the correct scored
or notscored
tags are on each rule. And then I'm also open to changing the level1
or level2
tags to be more explicitly one of:
level1_server
level2_server
level1_workstation
level2_workstation
Currently the plain level1
and level2
tags don't really mean anything since a lot of rules are tagged with both since in the Workstation profile those level 1 server rules are in fact level 2's.
It is advisable for people to create their own tailoring files using the rule_#.#.#
variables to switch things on and off though.
Hello, I wanted to reach out and let you know that this issue is being closed. We have re-worked the role and want to start with a fresh issues list with this latest version. There was a post in the Ansible-Lockdown google group (https://groups.google.com/g/ansible-lockdown) with the details of the changes that are coming. Please checkout the thread titled RHEL 7 CIS and STIG Changes for all of the details, I also have the message pasted at below. Please as you use the latest version and open issue tickets as you find them, it is the best way for us to improve the role for everyone. Thank you for being part of the community and providing awareness of problems or advice on improvement. Reporting is a huge part of improving this project.
Hello, Thank you to everyone in the Ansible-Lockdown community who has contributed to RHEL7 STIG/CIS. Our team at MindPoint Group has been working with the entirety of the Ansible-Lockdown project, and we have some significant updates for both RHEL 7 STIG and CIS. With these updates, some larger changes have been made. I have these changes/updates outlined below. Testing:
Example is 3.1.1 but there are more. Most are tagged as scored or not scored and without them all being tagged as such it seems some may run even if not intended. For instance running this playbook with
--tags=level-1,scored
ends up running some items which are not scored. Unsure if this is intended, but it still seems as though the tags should be consistent.