Add a MRAC preview post#58
Conversation
|
|
||
| ## Approach | ||
|
|
||
| If we think in a very simple way, we clearly need to design smart procedures or workflows that recact to changes, so no major brain power is needed to make right decisions. |
jan-cerny
left a comment
jan-cerny
left a comment
There was a problem hiding this comment.
In general, the blog post is difficult to read and understand.
It isn't clear whether it describes existing features or proposes some future features.
Please focus on clarity. You can help yourself by adding specific examples to the text.
| author_url: https://github.com/matejak | ||
| --- | ||
|
|
||
| Our Red Hat group is contemplating the idea of making the content project better equipped to handle changes in component behavior better. |
There was a problem hiding this comment.
Software is a too generic term, and I find component fitting.
I have added a description of what a component is, did it help?
| In practice, if we don't know at build-time what component will be scanned, we may solve this by having multiple rules ready. | ||
| When it comes to the actual scanning, this collection of rules makes sure that the evaluation will be carried out correctly, regardless of what component version is in question. | ||
| This could be achieved by set of rules with disjoint applicability, and the recently-introduced CPE Applicability Language helps this. |
There was a problem hiding this comment.
demonstrate this on an example
|
|
||
| - Be able to cover a security requirement by multiple rules. | ||
|
|
||
| In practice, if we don't know at build-time what component will be scanned, we may solve this by having multiple rules ready. |
There was a problem hiding this comment.
not ready but having multiple rules where each rule is for a different version of the examined software
There was a problem hiding this comment.
reworded (differently), hopefully good enough.
| One could split rules by copy-pasting, but it is desirable to minimize the amount of manual operations to the minimum. | ||
| At the time of writing this post, creating a new rule involves noticeable boilerplate, and creating an alternative version of a rule requires more effort that necessary. | ||
| This has to be reversed - what can be automated should be automated, and the duplication of data has to decrease by applying a more aggressive normal form. | ||
| Specifically, references are defined in rule files, while they can also be deduced from controls. | ||
| And perhaps there are other examples of redundant data? |
There was a problem hiding this comment.
Confusing. What are you trying to describe? I would recommend using templates and Jinja macros.
Demonstrate this on an example so that the readers can imagine it.
| However, this declarative concept can be extended beyond profile compositions. | ||
| We often use constructs s.a. `{{% if product in ("rhel7", "rhel8") %}}` instead of a more generic `{{% if product.prefers_single_file_sshd_configuration %}}` or something analogous. | ||
| Designing product properties in a way that is smart, doesn't get in the way and that can be reused in prose, checks and remediations is not trivial. |
There was a problem hiding this comment.
Please reword it that you recommend using product properties. Please add a working example.
| Wouldn't it be nice to have a capability that would allow us to query a component, and we would get change information from the project using an automation? | ||
| This can be very difficult to achieve exhaustively, but partial/good enough achievement may be actually doable. |
There was a problem hiding this comment.
Is this a proposal for a future feature? If yes, introduce it as such and be more specific.
There was a problem hiding this comment.
A proposal will be introduced properly in the PR that implements it. This post just aims to shift attention to some gaps in the project, and to potential solutions that nobody knows right now.
|
|
||
| Rules that try to do two things don't sound like a good idea, but if those two things are almost the same, then perhaps it could make sense. | ||
| Although CCE identifiers restrict the rule polymorphism significantly, change of component configuration preference could be handled without splitting a rule into two. | ||
|
|
| Or perhaps you would like to object some of those points? | ||
| Then reach out to us on Gitter! | ||
|
|
||
| If things go ahead as planned, you may expect pull requests showing up in upcoming months, and we are very much interested in your point of view. |
There was a problem hiding this comment.
What will these PRs introduce?
There was a problem hiding this comment.
Nobody knows now, so we have to wait for them with great anticipation.
matejak
force-pushed
the
mrac
branch
2 times, most recently
from
048166f to
301a095
Compare
jan-cerny
left a comment
jan-cerny
left a comment
There was a problem hiding this comment.
I like the improvements from the previous version.
I only have minor style and grammar suggestions.
| --- | ||
|
|
||
| Systems that our content aims to harden are very often large collections of separate components whose life cycle is independent from the life cycle of the product that ships them. | ||
| For example, the Red Hat Enterprise Linux consists of more than six thousand of such distinct components, although only a fraction of them s.a. OpenSSH, Grub2 and so on is supported by the ComplianceAsCode project. |
There was a problem hiding this comment.
either such as or and so on but never both
| Can you think of other ways of bringing declarative principles to the project? | ||
|
|
||
|
|
||
| ### Be able to track component changes and our reactions to them. |
There was a problem hiding this comment.
remove the dot
Change "Be able" to "Ability"
|
|
||
| ### Multiple rules to address one requirement | ||
|
|
||
| In practice, we may not know at build-time what exact version of a component will be scanned, and we may address this uncertainty by having multiple rules prepared to handle this uncertainty. |
| Rules that try to do two things don't sound like a good idea, but if those two things are almost the same, then perhaps it could make sense. | ||
| Although `CCE` identifiers restrict the scope of rule polymorphism significantly, change of component configuration preference could be handled without splitting a rule into two, polymorphically. | ||
|
|
||
| We have some polymorphic rules in our content, but they became polymorphic on their own, the project hasn't helped them with their polymorphism. |
|
|
||
| Provided examples nicely illustrate the richness of the rule-level polymorphism in the project. | ||
| Rules don't advertise that they are polymorphic, and the project doesn't provide them with any specific help with their polymorphism. | ||
| Project support for polymorphism of rules could reduce maintenance costs, as polymorphism would become more declarative. |
There was a problem hiding this comment.
| Project support for polymorphism of rules could reduce maintenance costs, as polymorphism would become more declarative. | |
| Adding support for polymorphism of rules could reduce maintenance costs, as polymorphism would become more declarative. |
Co-authored-by: Jan Černý <jcerny@redhat.com>
2 participants
Add a post that can serve as a teaser, and discussion starter for enhancements that part of the community would like to deliver in order to make the build system more capable/flexible.
The point of the post is to encourage discussion early, and to help to see upcoming PRs (at least we hope that they will come :-) in a greater context.