Add 'bls_audit_option' rule#5793
Conversation
|
/ok-to-test |
|
@evgenyz could you change the directory to |
JAORMX
left a comment
JAORMX
left a comment
There was a problem hiding this comment.
Let's add this to a profile
I assume that you want to add this rule to |
Got it, let's wait until we have the RHCOS product then. which comes here #5775 . And then add it to a profile there. |
We plan to update RHEL rules to check BLS settings in the close future. It is not clear to me if we should write new rules or change the current ones. And zIPL is also coming into the scene, see #5784 With that in mind, I'm thinking that the basic building blocks for BLS should be done as Jinja macros and the templates made specific for platforms. |
|
Well, the RHCOS product merged. Can you add a check that uses it to a profile in that product? |
I seems to me that the most of recent bootloaders would be using BLS entries, including zIPL. And it would make sense to convert it to a Jinja template. But I have no idea how to handle that pesky |
|
Okay, now when we are done with Now, in ocp4 profiles (let's take moderate as an example) we have the rule The only way out of this I could imagine is to have separate profiles for nodes and for the cluster itself. Thoughts? |
that's exactly where we're heading and why I introduced the RHCOS product in the first place. OCP4 will change to be for API/platform checks only. and node checks will use rhcos4/rhel7/rhel8 profiles respectively. |
|
By the way, another question is how to remediate RHEL7 nodes in the cluster? |
This is a good question. We could apply MachineConfigs to RHEL7 nodes just like we do with RHCOS and RHEL8 nodes... but we'll need to have MachineConfig remediations that apply and are relevant to RHEL7. |
Gosh, I just remember my introductory PR for OCP4 and regret not standing my ground. All this madness (including extra rules argument) could have been dodged. I'm sorry. I don't know what is wrong with me. I edit comments instead if quoting them recently. :( |
|
/retest |
|
@evgenyz: The following test failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
|
Seems you might need to rebase. |
| # AU-3 | ||
| - package_audit_installed | ||
| - grub2_audit_argument | ||
| - bls_audit_option |
There was a problem hiding this comment.
The way how to check BLS entry options may be similar across OSes or arches, but description and OCIL can vary a lot. Take for example zipl_audit_argument, description and OCIL mention a few commands and config files specific for zipl.
So I wonder if the rule should be renamed to grub2_bls_audit_option.
And conversely, zipl_audit_argument renamed to zipl_bls_audit_option.
The template name can remain boot loader neutral, but I would put in singular: bls_entry_option.
@evgenyz Thoughts?
There was a problem hiding this comment.
Entries are plural because we are checking ALL entries: <ind:filepath operation="pattern match">^/boot/loader/entries/.*\.conf$</ind:filepath>.
There was a problem hiding this comment.
oh, wouldn't it be the case that this won't pass even after the remediation is applied? The deployment keeps the previous configuration around which wouldn't have the compliant option.
There was a problem hiding this comment.
Now, zipl_audit_argument (as it seems to me) holds 2 different unrelated checks: for option in BLS-compatible entry and for settings in /etc/zipl.conf. I think that they should be separated (bls_audit_option + zipl_config_blah_blah). The bls_audit_option is bootloader-agnostic and could be reused in that way for all BLS-compatible bootloaders.
There was a problem hiding this comment.
oh, wouldn't it be the case that this won't pass even after the remediation is applied? The deployment keeps the previous configuration around which wouldn't have the compliant option.
Yes, it would be the case.
There was a problem hiding this comment.
Later we could add something like current=True parameter to this template.
There was a problem hiding this comment.
Later, this template can also be enhanced to consider cases when $kernelopts is present in the entry.
There was a problem hiding this comment.
Later, this template can also be enhanced to consider cases when
$kerneloptsis present in the entry.
I would be careful with that, it will make the rule not compatible with BLS.
There was a problem hiding this comment.
But, on the other hand we can parametrize the template to create grub2_bls_audit_option.
There was a problem hiding this comment.
The template can have conditionals for how different products handle BLS.
RHEL for example may check for all entries, not just the current.
entries for presence of audit=1 parameter. The rule is based on the 'bls_entries_option' template.
|
Changes identified: Recommended tests to execute: |
7 participants
For checking BLS-compatible boot loader entries for presence of audit=1 parameter. The rule is based on the 'bls_entries_option' template.
The
prodtypeof the rule is set tofedora,rhel8but it should be changed tofcos, rhcos(when we will have them), this rule and template won't work on regular Fedora and RHEL. See #5775, #5285.This will fix #5285.