Tag strategy and consistency within this role

[ghost]

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.

[shepdelacreme]

Thanks for the report. I think the tagging needs a thorough review/clean up at this point!

[shepdelacreme]

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.

[shepdelacreme]

@bbaassssiiee Would appreciate your opinion on how people use tags with this role as well.

[bbaassssiiee]

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.

[brydoncheyney]

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?)

[erpadmin]

(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.

[shepdelacreme]

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.

[georgenalen]

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:

1. CI/CD - We have implemented some automated testing pipelines to test pull requests into the devel and main branches. With the current workflow, the community will PR into the devel branch (never the main branch) for review by the administrators. When your PR is created, the first check will remain the DCO check. The second check is a functional testing pipeline that will automatically perform a functional test of the branch the PR is initiated from. Once both tests pass, someone from the Administrator Team will review the changes and merge them into the devel branch. From there, an additional review is completed before the devel branch is merged into the main branch. Only the Admin Team will perform PRs/merges into the main branch. There is also an automated pipeline for PRs from devel to main. Please do not edit the .github/workflows files since those are used as part of the pipeline.
2. Compliance Checking – MindPoint Group has been working to create our own compliance audit scan tool. The tool uses a goss framework executable to run custom checks that we have created. The goal is to provide a more thorough check for control compliance and decrease the number of false positives/negatives. For example, it will check the configuration file related to the control and as well as checking if that configuration is active. With a smarter scan, we can hopefully identify attempts to trick scanners as well (for example stacking a parameter in a config file where the first instance is enabled and second disabled. Most audit tools search for the first instance but the application might look for the last instance of the parameter, thus making the scanning tool think it's enabled). In testing, we have found that our audit scan runs significantly faster than other audit tools, reducing audit times. Our audit tool and profiles will have their own repositories in the Ansible-Lockdown org, but within the remediation role there will be an integrated way to incorporate the audit. Keep an eye out for the audit tools as they are released. We plan on developing a goss audit profile for each current remediation role. Going forward, we plan to release a remediation role and goss audit tool profile simultaneously.
   Role Updates:
3. RHEL 7 STIG/CIS – We have re-written much of the RHEL 7 STIG and CIS roles to increase clarity and readability and address some functionality items. We performed these updates while creating our goss testing framework for each of these roles. We plan on pushing our update to the devel and main branches. We will move the current devel and master branches to a devel_stable_ and master_stable_ branch in the respective repositories. Accordingly, community members who rely on the current version can still use that version going forward; this process will not remove what is currently there. The latest versions of the roles have also been updated to comply with the latest benchmarks.
4. Role Architecture – All roles will change with regard to the structure in the tasks folder. Taking CIS as an example, there will be a folder per section and yaml files for each sub-section. For example control 1.2.1 in CIS will be located in RHEL7-CIS/tasks/section_1/cis_1.2.x.yml. The cis_1.2.x.yml file will contain all controls related to section 1.2.x. This will hopefully make updates to roles a bit easier with less risk. This matches the architecture of our audit tool, creating consistency across remediation and audit platforms. The end goal is to repeat this architecture (the best we can) on STIG roles, but we are starting with CIS.
5. Existing PRs and Issues – With all of these changes comes the task of cleaning up existing PR’s and issues. Our plan is to close all of the existing PR’s and issues because of the re-work. Our team is growing and should be able to stay on top of the new issues and PRs as they come in.
   Again, I would like to thank the community for your involvement in this project. The input and work from the community has contributed significantly to the success of this project. Please keep an eye out for these changes, which will be rolling out in the coming weeks.