Sle16 base control

[teacup-on-rockingchair]

Description:

• Add SUSE SLE 16 platform

Rationale:

• Add SUSE SLE 16 platform to build procedure
• Add initial base profile for SLE16 platform
• Add skeleton implementation for PCI-DSS and ANSSI minimal profiles for SLES16

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[svet-se]

Looks good to me! The base control file will bring a lot of benefits, because the code will be DRY, which will improve the maintenance. IMHO, it will be great if this approach is accepted by the community.

[openshift-ci]

@teacup-on-rockingchair: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/e2e-aws-openshift-node-compliance	852ddb9	link	true	/test e2e-aws-openshift-node-compliance

Full PR test history. Your PR dashboard.

Instructions 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-sigs/prow repository. I understand the commands that are listed here.

[Mab879]

Looks good to me! The base control file will bring a lot of benefits, because the code will be DRY, which will improve the maintenance. IMHO, it will be great if this approach is accepted by the community.

Can you please explain these benefits so I better understand this PR?

Why not use the existing ANSSI and PCI controls?

[svet-se]

Looks good to me! The base control file will bring a lot of benefits, because the code will be DRY, which will improve the maintenance. IMHO, it will be great if this approach is accepted by the community.

Can you please explain these benefits so I better understand this PR?

Why not use the existing ANSSI and PCI controls?

The idea of using one product-based control file at some point is that you will not repeat some of the rules in all control files. For example, if you would like to change or remove some of the rules that are repeated in all control files, you should delete them everywhere; the second approach is to delete them from one place. IMHO, there will be challenges with the specific control IDs and titles. The second approach may be to use the control files for reference, but each product has its own base control file; in this way, if a specific product's rules are added, they should not be excluded from all other profiles. The idea is to keep the profile files clean from exclusions (which are also repeated)

[teacup-on-rockingchair]

Looks good to me! The base control file will bring a lot of benefits, because the code will be DRY, which will improve the maintenance. IMHO, it will be great if this approach is accepted by the community.

Can you please explain these benefits so I better understand this PR?

Why not use the existing ANSSI and PCI controls?

One thing that is obvious and left out of previous explanation is, that we are using the levels as selectors for the different standards requirements like PCIDSS, ANSSI etc. Hopefully having all the rules relevant for a platform would make also more visible cases of rules duplication, like having two or more rules performing the same thing but developed for different standards, and will push us to droping more duplicated rules/code.

[Mab879]

Can you please split this PR into two PRs? One for the new product, one for the new control file. I don't want hold up the new product based on the control file.

While new control file is an interesting idea. I have few questions and reservations about it.

[teacup-on-rockingchair]

Just created PR #14010 to extract the platform out of this PR. As soon as we have closed all unclear points here, will rebase it so it will have no conflicts.