Bug 1919660

Also, rules contain "master":

"Rule ID	xccdf_org.ssgproject.content_rule_file_permissions_master_admin_kubeconfigs"

Given that this node report is run for both masters and workers, it would make sense to drop "master" and replace it with "" or "node"

Created attachment 1750237 [details]
worker - master -confusion

@Andreas, Thanks for using the operator and taking the time to report these bugs! Some of the rule names might be confusing, so let me try to clarify. The rule itself is only meant to run on nodes with the relevant files; typically these are the "master" nodes, hence the name. However, we add it to the profile as we cover all of the nodes, just in case we're dealing with a funky setup where services that use these files are running on non-master nodes. From the result you sent me, that specific rule is marked "notapplicable" on the worker node. If you inspect the master nodes you'll see that the rule ran and probably passed (at least it does on a fresh cluster). So, I do think that the "master" name was applicable as most likely (99% of the cases for now?) this will be applicable only on the master nodes. On the other hand, the name was taken from the CIS benchmark: it alludes to the "master" section in the benchmark. Does this clear up the rule names?

Hi,

Thanks for the clarification and sorry for the follow-up. 

Here's what I understand and my follow-up questions:
=================================================================

Looking at both reports, I can see:

Worker node: 52 tests passed
Master node: 89 tests passed

i) The worker node has many "Not applicable tests". The difference in number of tests passed can be explained by the number of "not applicable" rules, too.

ii) Going through the individual rules on the worker, indeed all rules that contain "master" are not applicable on the worker nodes. The rules' scope is specific master configuration, thus their name. But as there might be scenarios where worker nodes take over specific master functionality, we include them inside the worker report, by default. Also, if a worker node took over master functionality, it would still make sense to run a rule names "*master*" on the worker node. Either way, isn't the profile exactly the same for all nodes and roles, and thus we cannot push different rules? I suppose that a solution here would be either to release 2 different node profiles, one for the master role, and one for the worker role. Or, the customer could create 2 different TailoredProfiles, one for masters and one for workers, and just push only the rules that they want? I already tore down my lab, so my apologies if this is obvious. But if a customer created 2 different TailoredProfiles, ocp4-cis-tailored-worker and ocp4-cis-tailored-master, is there a NodeSelector that allows them to run the TailoredProfile only against a specific role?

iii) So this specifically here: "OpenShift - Master Node Settings"
Relates to the "Master" section in the Benchmark. It does not refer to Master nodes, correct? So even if we had no master nodes / master node rules, the section would still be named the same?

Thanks so much for helping out!!!

- Andreas

(In reply to Andreas Karis from comment #8)
> Hi,
> 
> Thanks for the clarification and sorry for the follow-up. 
> 
> Here's what I understand and my follow-up questions:
> =================================================================
> 
> Looking at both reports, I can see:
> 
> Worker node: 52 tests passed
> Master node: 89 tests passed
> 
> i) The worker node has many "Not applicable tests". The difference in number
> of tests passed can be explained by the number of "not applicable" rules,
> too.

yep!

> 
> ii) Going through the individual rules on the worker, indeed all rules that
> contain "master" are not applicable on the worker nodes. The rules' scope is
> specific master configuration, thus their name. But as there might be
> scenarios where worker nodes take over specific master functionality, we
> include them inside the worker report, by default. Also, if a worker node
> took over master functionality, it would still make sense to run a rule
> names "*master*" on the worker node. Either way, isn't the profile exactly
> the same for all nodes and roles, and thus we cannot push different rules?

We could push different rules if we wanted to, but then we'd need to have different profiles per role type, and it would be a usability burden on folks running the compliance scan. We found that it's just easier that folks deploy one profile and the rules that don't apply will just be marked as `not-applicable`. We'd consolidate the profiles even more if we could. But this seems to be a good balance. 
 
> I suppose that a solution here would be either to release 2 different node
> profiles, one for the master role, and one for the worker role. Or, the
> customer could create 2 different TailoredProfiles, one for masters and one
> for workers, and just push only the rules that they want?

Right! this would be a possible solution. You'd need to different profiles, or two different tailed profiles, and then you would need to specify that they only apply to workers or masters. This would give you a cleaner result.... but would result in slightly more difficult application of them (you'd need to create ComplianceScan objects yourself, or create two different ScanSettings objects with two different ScanSettingBindings)
> I already tore down my lab, so my apologies if this is obvious. But if a customer created 2
> different TailoredProfiles, ocp4-cis-tailored-worker and
> ocp4-cis-tailored-master, is there a NodeSelector that allows them to run
> the TailoredProfile only against a specific role?

Yes, that's available in the ScanSettings object. We ship a default that covers both workers and masters, so you'd need to create different settings for masters and workers.

> 
> iii) So this specifically here: "OpenShift - Master Node Settings"
> Relates to the "Master" section in the Benchmark. It does not refer to
> Master nodes, correct? So even if we had no master nodes / master node
> rules, the section would still be named the same?

Yep

> 
> Thanks so much for helping out!!!
> 
> - Andreas

(In reply to Juan Antonio Osorio from comment #9)
> (In reply to Andreas Karis from comment #8)
> > Hi,
> > 
> > Thanks for the clarification and sorry for the follow-up. 
> > 
> > Here's what I understand and my follow-up questions:
> > =================================================================
> > 
> > Looking at both reports, I can see:
> > 
> > Worker node: 52 tests passed
> > Master node: 89 tests passed
> > 
> > i) The worker node has many "Not applicable tests". The difference in number
> > of tests passed can be explained by the number of "not applicable" rules,
> > too.
> 
> yep!
> 
> > 
> > ii) Going through the individual rules on the worker, indeed all rules that
> > contain "master" are not applicable on the worker nodes. The rules' scope is
> > specific master configuration, thus their name. But as there might be
> > scenarios where worker nodes take over specific master functionality, we
> > include them inside the worker report, by default. Also, if a worker node
> > took over master functionality, it would still make sense to run a rule
> > names "*master*" on the worker node. Either way, isn't the profile exactly
> > the same for all nodes and roles, and thus we cannot push different rules?
> 
> We could push different rules if we wanted to, but then we'd need to have
> different profiles per role type, and it would be a usability burden on
> folks running the compliance scan. We found that it's just easier that folks
> deploy one profile and the rules that don't apply will just be marked as
> `not-applicable`. We'd consolidate the profiles even more if we could. But
> this seems to be a good balance. 
>  
> > I suppose that a solution here would be either to release 2 different node
> > profiles, one for the master role, and one for the worker role. Or, the
> > customer could create 2 different TailoredProfiles, one for masters and one
> > for workers, and just push only the rules that they want?
> 
> Right! this would be a possible solution. You'd need to different profiles,
> or two different tailed profiles, and then you would need to specify that
> they only apply to workers or masters. This would give you a cleaner
> result.... but would result in slightly more difficult application of them
> (you'd need to create ComplianceScan objects yourself, or create two
> different ScanSettings objects with two different ScanSettingBindings)
> > I already tore down my lab, so my apologies if this is obvious. But if a customer created 2
> > different TailoredProfiles, ocp4-cis-tailored-worker and
> > ocp4-cis-tailored-master, is there a NodeSelector that allows them to run
> > the TailoredProfile only against a specific role?
> 
> Yes, that's available in the ScanSettings object. We ship a default that
> covers both workers and masters, so you'd need to create different settings
> for masters and workers.
> 
> > 
> > iii) So this specifically here: "OpenShift - Master Node Settings"
> > Relates to the "Master" section in the Benchmark. It does not refer to
> > Master nodes, correct? So even if we had no master nodes / master node
> > rules, the section would still be named the same?
> 
> Yep

Spoke to the customer regarding iii) and they asked if something could be done to clarify the report title as this creates confusion especially for non-master nodes.

> 
> > 
> > Thanks so much for helping out!!!
> > 
> > - Andreas

Sounds like a good suggestion. We'll change the group from "master" to something more relevant (such as the actual service name that's being checked), so it should create less confusion. If a node isn't running a certain service, then it'll be marked as not-applied.

Fixing with https://github.com/ComplianceAsCode/content/pull/7128

We'll target 4.8 but it could go into z-stream earlier.

This has been fixed in the content