Add AlmaLinux 9 support #12757
Add AlmaLinux 9 support #12757
Conversation
The AlmaLinux 9 support has been implemented as a derivative of RHEL 9, since AlmaLinux 9 is a clone of RHEL 9 and the CIS Benchmarks are pretty much identical.
|
Hi @0intro. Thanks for your PR. I'm waiting for a ComplianceAsCode member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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. |
|
Start a new ephemeral environment with changes proposed in this pull request: rhel8 (from CTF) Environment (using Fedora as testing environment) Fedora Testing Environment Oracle Linux 8 Environment |
|
Code Climate has analyzed commit a9564e7 and detected 0 issues on this pull request. The test coverage on the diff in this pull request is 100.0% (50% is the threshold). This pull request will bring the total coverage in the repository to 61.6% (0.0% change). View more on Code Climate. |
|
/ok-to-test |
openshift-ci
bot
added
ok-to-test
|
The static test failures are due to Wavier needing to be added. I can propose a PR to Contest later today. |
RHSecurityCompliance/contest#296 should fix it. |
|
CIS is a great start, as we develop the F34-based benchmarks together it would be great to see AlmaLinux added to CaC. I've got some automation for the AlmaLinux OS 9 STIG that needs updating now the STIG is final, but maybe we should concentrate on adding it to CaC instead? |
| "<i>AlmaLinux</i> does not inherit " \ | ||
| "certifications or evaluations from <i>Red Hat Enterprise Linux</i>. As " \ | ||
| "such, some configuration rules (such as those requiring " \ | ||
| "<i>FIPS 140-2</i> encryption) will continue to fail on <i>AlmaLinux</i>.</li>\n" \ |
There was a problem hiding this comment.
I wonder if we should add a note about the FIPS 140-3 modules from https://docs.tuxcare.com/enterprise-support-for-almalinux/fips/ ?
If you looking to add different profiles then what is is in RHEL I would suggest creating a new product that isn't a derivative of RHEL. By merging this pull request all of the profiles will be what is in RHEL. See #12611 as a recent example of how. We also have some docs as well. As always if need any help please let us know. |
|
That's where I've always got stuck before. The CIS benchmarks are largely the same, but the STIG is more different - requires a license, different repos, specific FIPS packages, certain minor versions aren't supported etc. |
In that case a different product might be best. The control files can be leveraged to reduce the workload on maintaining Alma profiles. |
Yes, with the mix of commercial and community, I think products make sense looking at how Ubuntu does it e.g.
They have different OVAL/repo's and such too. I'm going to have a look at the example product in a bit. How does this affect this PR though - is it worth merging to get things started, and then once we have products setup, revert the changes? Update: made a start on a new product https://github.com/sej7278/cac-content/tree/add-alma9 I think we could use the control files for the commercial STIG, rather than another product, as the STIG itself contains minor version, repo, FIPS package checks etc. |
If you looking to add AlmaLinux as it own separate product it might be best to close this pull request and just add the product.
I don't believe we can just substitute in one profile (i.e. the STIG profile from RHEL control file to the Alma control file) when a product is a derivative. |
|
Hmm maybe, although I don't want to hold things up whilst we work on a product, that looks like it could take a long time? As for the STIG, i had hoped we could have an almalinux9 community product, and then just use a control file to add the commercial (TuxCare) STIG+FIPS content, not re-using RHEL or anything. |
|
Would it make sense to push this change as is, so the Alma Linux 9 support would be available for release 0.1.76. Then, the support could be moved to its own product, once the STIG profiles would be written out? |
We can start out simple with just one profile.
This is something that we can do. We should able to get this PR merged quickly. Once it ready we can convert AlmaLinux to a full product. Does that work for you both? |
|
What would be involved in making a product if this derivative exists? Would we have to revert these changes - I assume you can't have a derivative and product both called almalinux9 ? CIS shouldn't take too long as it's very similar to rhel being based on the same f34 source, but STIG will take longer. I'd like to understand what's involved just to get the CIS profile enabled for a new product, as that's the main one i assume @0intro is interested in. |
Correct, you would have to revert these changes. Then create a almalinux9 product.
You might be able to use RHEL 9 CIS control file as a starting point to create profiles like RHEL 9 CIS Level 2. The control file makes easy to create the 4 profiles needed for CIS. |
|
That seems to have worked, using https://github.com/sej7278/cac-content/tree/add-alma9 i now have:
|
|
Made a product-based PR as #12808 for comment/review |
Description:
This PR adds AlmaLinux 9 support.
The AlmaLinux 9 support has been implemented as a derivative of RHEL 9, since AlmaLinux 9 is a clone of RHEL 9 and the CIS Benchmarks are pretty much identical.
Rationale:
AlmaLinux is a community-supported clone of Red Hat Enterprise Linux. CIS Benchmark for AlmaLinux has been firstly published in November 2021.