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.


On Tue, Mar 17, 2020 at 11:23 AM Jakub Hrozek <jhrozek@redhat.com> wrote:

at the moment, we have a single content for OCP4:
all the rules currently are targetting RHCOS as the YAML probe usage
is still being integrated into the compliance operator. But even at the
OS or cluster node level, the rules are only applicable to RHCOS or
RHEL-8 with the help of rules from this file:

However, our customers would also run UPI-provisioned (User Provided
Infrastructure provisioned) clusters with RHEL-7 or RHEL-8 as workers.
Master nodes, or the control plane nodes, can only run RHCOS as the OS.

So the question is how do we go about the content? On one hand, even
though RHCOS is sort-of-kind-of RHEL-8, the rules for RHCOS and RHEL-8
might differ. As an example, the way to install a required package would
be different, on RHCOS you would have used rpm-ostree, but on RHEL-8 you
would have used yum. Coming from a different angle, I don't think we can
reuse the RHEL content either, because some rules are not applicable in
the OCP content even though the OS is vanilla RHEL. As an example, you
wouldn't configure bind for DNS in OCP, but you would use CoreDNS.

Even though I don't know what the YAML checks would look like, I assume
that there might also be checks about e.g. kubelet configuration
(kubelet is the node agent that runs on each node in the cluster) that
need to be run and evaluated on all nodes in the cluster, regardless of
the node OS.

With that in mind, what options do we have to deliver content that would
both be applicable across RHCOS, RHEL-8 and RHEL-7 but also with the OCP
use-cases in mind? Should we fork the contents for each OS or try to reuse
all the rules in single content? How would reusing rules work in
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedorahosted.org