Map rules to components #10609

jan-cerny · 2023-05-23T08:03:50Z

Description:

This PR introduces a mapping from operating system components to rules. This mapping is stored in YAML files in components directory. The "component" is a package or a set of related packages.

All rules from the linux_os benchmark directory have been assigned to a component. Most of the rules are mapped to at least 1 component. The remaining rules are put into a generic "operating system" component. This mapping is currently very crude. It will have to be improved manually. Some rules will have to be add to more components or moved to a different component.

The PR also adds a new script utils/assign_components.py which can be used for semi-automated component assignment for rules. The components are assigned to rules in "obvious" cases, such as:

the name of the component is a part of the rule ID
the rule is in a Group that is dedicated to a specific component
the rule is package_installed, package_removed, etc.
the rule uses templates where we can easily infer the component based
on the template or a template parameter

The script uses data in CSV files that have been manually improved and they capture current state of the linux_os benchmark. The script generates a YAML otuput to a given directory where each YAML file will represent 1 component.

The utils/assign_components.py script and CSV data is immediately removed by a subsequent commit in this PR.

More items can be found in the follow up PR #10638.

For more details, please read the commit messages of every commit.

Rationale:

When a rule's behavior needs to be changed / updated, it is likely that other related rules need to be changed / updated as well.

One of the goals of this mapping is to enable content maintainers to see what other rules may require attention.
Another goal is better interface to communicate with component maintainers.

Also, this change is a prerequisite for the "minor release agnostic content".

Review Hints:

Review the contents of YAML files in the components directory.

Summary:

This PR will add:

component-rule mapping by YAML files
documentation describing format of these "component" files

The one-off script that was used to generate the YAML files is added and the removed by another commit, so it isn't visible in the "Files changed" tab.

There are no changes in the build system and no changes in tests.

openshift-ci · 2023-05-23T08:03:54Z

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

github-actions · 2023-05-23T08:19:49Z

Start a new ephemeral environment with changes proposed in this pull request:

Fedora Environment

Oracle Linux 8 Environment

matejak · 2023-05-25T13:30:17Z

tests/test_components.py

+    rule_to_components = ssg.components.rule_components_mapping(components)
+    linux_os_guide_dir = os.path.join(args.source_dir, "linux_os", "guide")
+    rules_with_component = set(rule_to_components.keys())
+    rules_in_benchmark = set(ssg.rules.find_all_rules(linux_os_guide_dir))


Iterating over built rules is probably better, because it opens doors to examining remediations and checks as well, without having to deal with macros. In-source rule contents are unreliable, as there can be important unexpanded macros.
Moreover, you already use the product context in the code, so it is just one step from using the compiled contents.

matejak · 2023-05-25T13:58:07Z

utils/assign_components.py

+    return components
+
+
+template_to_component = {


WDYT of moving this directly to templates (in the future)?

I plan to do that

This commit adds a new script `utils/assign_components.py` which can be used for semi-automated component assignment for rules. The components are assigned to rules in "obvious" cases, such as: - the name of the component is a part of the rule ID - the rules is in a Group that is dedicated to a specific component - the rule is package_installed, package_removed, etc. - the rule uses templates where we can easily infer the component based on the template or a template parameter The script uses data in CSV files that have been manually improved and they capture current state of the `linux_os` benchmark. The script generates a YAML otuput to a given directory where each YAML file will represent 1 component. We expect an immediate removal of this script and CSV data.

This mapping has been generated by script `utils/assign_components.py`. All rules from the `linux_os` benchmark directory have been assigned to a component. Most of the rules are mapped to at least 1 component. The remaining rules are put into "unknown" component, but there is only 234 rules that are in the "unknown" component. This mapping is wild. It will have to be improved manually. Some rules will have to be add to more components or moved to a different component.

jan-cerny · 2023-05-26T15:37:32Z

I have split the PR to #10638 and I have updated the description.

vojtapolasek · 2023-05-29T12:51:48Z

Hello @jan-cerny,
this looks impressive, nice job.
I found just a small problem; the "packages" key is not documented among the keys which can be in the component definition.

jan-cerny · 2023-05-29T12:57:40Z

@vojtapolasek Thank you!

I have added the packages key to the doc.

codeclimate · 2023-05-29T14:06:42Z

Code Climate has analyzed commit 0fb59ff and detected 0 issues on this pull request.

The test coverage on the diff in this pull request is 100.0% (50% is the threshold).

This pull request will bring the total coverage in the repository to 52.5% (0.0% change).

View more on Code Climate.

matejak · 2023-05-29T15:24:17Z

I like this concept, the idea basically is that the component mapping is bootstrapped (this is what this PR does), and then it is expanded incrementally as time goes by, based on changes to the project (rule additions). As stated in the description, this mapping connects rules that are likely to change for the same reason. Information about components is located in component files, not in rules, templates, and so on - content authors that want to assure conformance of the content with new product releases are a minority, so data that only they need shouldn't distract others by default.
The follow-up PR contains a test that can assist with keeping this mapping up-to-date, and that is functionally similar to the script that was used as a helper to bootstrap the mapping. I suppose that more work that makes that test smart and powerful can follow, and it should be designed with extensibility in mind.
I think that the schema of a Component can be treated as flexible at the moment, and I would even consider dropping the packages key, as package organization can vary across distributions, but it is the upstream that changes and that forces everybody equally to react to that change sooner or later, regardless how they package that project.

matejak

I approve the PR with the knowledge that the referenced follow-up PR provides some level of support for keeping the contents up-to-date.
I will not merge it for another day to see whether there will be more comments.

matejak · 2023-05-30T15:10:55Z

No additional comments, so here we go!

openshift-ci bot added the do-not-merge/work-in-progress Used by openshift-ci bot. label May 23, 2023

jan-cerny force-pushed the components branch 3 times, most recently from 2428fc5 to 97a5ccf Compare May 24, 2023 11:31

matejak self-assigned this May 25, 2023

matejak reviewed May 25, 2023

View reviewed changes

jan-cerny force-pushed the components branch from 8590c57 to 5ab3a63 Compare May 25, 2023 14:29

jan-cerny added Infrastructure Our content build system enhancement General enhancements to the project. Highlight This PR/Issue should make it to the featured changelog. labels May 25, 2023

jan-cerny force-pushed the components branch 2 times, most recently from 8ffdf76 to 2acf002 Compare May 26, 2023 12:49

jan-cerny added 3 commits May 26, 2023 17:26

Remove a one-off tool for semi-automated component assignment

35ebf69

jan-cerny mentioned this pull request May 26, 2023

Test and use rules to components mapping #10638

Closed

jan-cerny force-pushed the components branch from 2acf002 to 35ebf69 Compare May 26, 2023 15:34

Document components feature

f4453f2

jan-cerny marked this pull request as ready for review May 26, 2023 16:05

openshift-ci bot removed the do-not-merge/work-in-progress Used by openshift-ci bot. label May 26, 2023

Add changelog key to the components YAML

8ee83fd

Document packages key

0fb59ff

matejak approved these changes May 29, 2023

View reviewed changes

Mab879 added this to the 0.1.69 milestone May 30, 2023

matejak merged commit da49a81 into ComplianceAsCode:master May 30, 2023
32 checks passed

jan-cerny mentioned this pull request Jun 7, 2023

Test and use rules to components mapping #10693

Merged

marcusburghardt mentioned this pull request Dec 15, 2023

Replace rule/group prodtype alignment with explicit inclusion in a product profile/benchmark #11382

Closed

2 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Map rules to components #10609

Map rules to components #10609

jan-cerny commented May 23, 2023 •

edited

openshift-ci bot commented May 23, 2023

github-actions bot commented May 23, 2023

matejak May 25, 2023

matejak May 25, 2023

jan-cerny May 25, 2023

jan-cerny commented May 26, 2023

vojtapolasek commented May 29, 2023

jan-cerny commented May 29, 2023

codeclimate bot commented May 29, 2023

matejak commented May 29, 2023 •

edited

matejak left a comment

matejak commented May 30, 2023 •

edited

Map rules to components #10609

Map rules to components #10609

Conversation

jan-cerny commented May 23, 2023 • edited

Description:

Rationale:

Review Hints:

Summary:

openshift-ci bot commented May 23, 2023

github-actions bot commented May 23, 2023

matejak May 25, 2023

Choose a reason for hiding this comment

matejak May 25, 2023

Choose a reason for hiding this comment

jan-cerny May 25, 2023

Choose a reason for hiding this comment

jan-cerny commented May 26, 2023

vojtapolasek commented May 29, 2023

jan-cerny commented May 29, 2023

codeclimate bot commented May 29, 2023

matejak commented May 29, 2023 • edited

matejak left a comment

Choose a reason for hiding this comment

matejak commented May 30, 2023 • edited

jan-cerny commented May 23, 2023 •

edited

matejak commented May 29, 2023 •

edited

matejak commented May 30, 2023 •

edited