-
Notifications
You must be signed in to change notification settings - Fork 685
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tool for identifying the most used components #11730
Conversation
Skipping CI for Draft Pull Request. |
🤖 A k8s content image for this PR is available at: Click here to see how to deploy itIf you alread have Compliance Operator deployed: Otherwise deploy the content and operator together by checking out ComplianceAsCode/compliance-operator and: |
if PYTHON_2: | ||
raise Exception("This feature is not supported for python2.") | ||
|
||
for product in get_available_products(): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At this moment, we use "components" only for Fedora, RHEL 7, RHEL 8, RHEL 9 and RHEL 10 products. It doesn't make sense to include into stats any other products or any controls used in the products that don't use components.
One of consequences of this behavior is that we have without_component: 12125
which involves all rules that aren't part of linux_os benchmark.
If a product is using the "components" feature it sets the components_root
key in its product.yml.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right. I have improved the product selection to those with components_root
.
def command_most_used_components(args): | ||
components = {} | ||
|
||
_process_all_products_from_controls(components) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it doesn't make sense to combine results from all products to a single number. Currently from the output we can see that the selinux component is used 1660 times. But this number is the count of rules multiplied by their occurence in profiles multiplied by their occurence in products.
I think that a product ID should be a parameter of this script and the results should be produced for the given product.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Limitation on product will be done by #11733 .
Code Climate has analyzed commit 585a0e7 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 59.3% (0.0% change). View more on Code Climate. |
Description:
This PR adds a subcommand
profile_tool.py
that generates a list of components with the number of occurrences of the component's rules in the profiles that are generated in different formats.Rationale:
The benefit of having this information quickly accessible is to have a more precise idea of components importance so we can work more proactively and avoid issues, for example, when releasing policies for a brand new product.
Historically we have discovered relevant component changes. SSH, Rsyslog, PAM and authselect are good examples. Getting awareness of these components changes too late may cause considerable efforts since we had to adapt rules to the changes in a very short period of time.
Review Hints:
To generate a list of the most used components in the whole project: