Hello Jakub,
thank you for the question - if I understand correctly, here are the scenarios that you anticipate:
* RHCOS (standard checks - there is currently no other checking of RHCOS outside OCP, AFAIK)
* kubelet on RHCOS
* RHEL8 standard checks
* kubelet checks on RHEL8
* RHEL7 standard checks
* kubelet checks on RHEL7
Now what are the options:
1. have everything in OCP4
2. RHCOS in OCP4, and rest in respective products, with profiles containing both FedRAMP Moderate and OCP specific checks
3. standard checks in respective products, and kubelet checks in separate application "product"
1. is most self contained, only one data stream as a result and simpler way how to trigger scan - you just scan, and content knows what is applicable and what's not. At the same time, the content itself will be complex, and will live independently on the OS product development.
2. operator needs to know what is being scanned, to apply correct data stream (as there are three of those). Results are still complete per node. Complexity is not so high, but every product contains parts that are dependent on kubelet checks - at least three places to record every change in the profile.
3. operator scans each node twice - once for OS standard check, second time for the kubelet checks. This creates more complex result aggregation, but all (four) pieces are developed just once.
From my perspective, option 3 is the cleanest from the ComplianceAsCode project perspective. It moves some of the complexity to the operator, so the CaC does not have to bloat. And honestly - complexity is something we need to keep as low as possible if we want to move forward. Looking forward to hear different perspectives.
Regards,
Marek