-
Notifications
You must be signed in to change notification settings - Fork 48
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
Support categories #469
Support categories #469
Conversation
Signed-off-by: Daniel Grunberger <[email protected]>
Signed-off-by: Daniel Grunberger <[email protected]>
Signed-off-by: Daniel Grunberger <[email protected]>
Signed-off-by: Daniel Grunberger <[email protected]>
Signed-off-by: Daniel Grunberger <[email protected]>
Summary:
|
@Daniel-GrunbergerCA - Hey!
This PR should be approved only after a meeting with regolibrary maintainers, so we can understand which effection we have over other developments now. |
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.
@Daniel-GrunbergerCA - Hey!
This PR is too large, needs to be splitted into the relevant topics of the PR.
With whom did we review that ? why we need to add those categories ?
How we are going to add those categories to new controls developed ? by which base ?
README file should be updated as well to guide the next developers.
This PR should be approved only after a meeting with regolibrary maintainers, so we can understand which effection we have over other developments now.
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.
@Daniel-GrunbergerCA - please supply clear documentation of how to add these categories for future controls. Like we disscussed - If it can be automated that would be best and would make our life easier to maintain. If not - it should be very clear to the control contributor what should be the taken into consideration, and we should validate that it was added.
There is no clear documentation on how to categorize a control since there is not a straightforward way of doing it. As for now, controls are not required to have a category. The controls which needed a category are being categorized on this PR, and adding new controls without categories won't cause any issues. For now, the one categorizing controls is @slashben The reason of adding such categories is that the new KS output will be displaying controls divided by their categories cc: @dwertent |
Summary:
|
@Daniel-GrunbergerCA - How will we handle controls that don't have a category specified? |
@slashben - Can we try to think of a definition for these categories and guidelines on how to specify this on a new control? (Preferably automaticly! for e.g based on what resources we are requesting for rules in this control) If not we won't be able to maintain this in future controls |
For a cluster and workload scan, ks will be using the new frameworks provided on this PR. These are the only scans where we are printing different tables for different frameworks. And all controls on this frameworks are categorized. On the worst case, that someone pushes a new uncategorized control to this framework, it just won't be seen on the tables outputs (which is the desired behavior for such case) |
Summary:
|
Signed-off-by: Daniel Grunberger <[email protected]>
Summary:
|
Summary:
|
Summary:
|
Overview
export.py
script. There is a file which maps the categories names to their respective ids. This way, we can easily change the name for a category, as long as we keep the same ID.ClusterScan
andWorkloadScan
. They will be transparent from the BE and users perspective, and will be used by KS for a cluster and workload scan, respectively.