ZTP: Add 4.20 hardening YAMLs

[sebrandon1]

Proof-of-concept for Telco-RAN hardening and 4.20. Open for all reviews and suggestions. I'm not sure about the "structure" of the folders/YAMLs so if there is something obvious that needs to be changed, we can do so. I am doing everything in this PR via scripting so it can be reproducible and traceable as to what I'm doing to create these YAMLs and where they come from:

https://github.com/sebrandon1/compliance-scripts

I'm using the following scans to test against my 4.20 cluster:

$ oc get compliancesuite -n openshift-compliance
NAME          PHASE   RESULT
cis-scan      DONE    NON-COMPLIANT
periodic-e8   DONE    NON-COMPLIANT

These are from the tutorial of the compliance operator page here.

Questions going forward

1. What kind of "scan profiles" are we looking to run? I wasn't able to find documentation (maybe I missed it) of what profiles/scans we are supposed to run for this effort.

2. For the APIServer and Ingress remediations, they seem to be needed to apply on the first boot (or require an entire restart to apply). Don't quote me on this but this is how they are acting when I apply their remediations via the operator or manually.

Naming conventions and layout based on:
openshift-kni/cnf-features-deploy#2147

Changes in the PR

API Server Configuration Updates:

• Added a new API server encryption provider configuration using the aescbc encryption type for CIS compliance (75-ocp4-cis-api-server-encryption-provider-cipher.yaml) and E8 compliance (75-ocp4-e8-api-server-encryption-provider-cipher.yaml). [1] [2]
• Set the audit profile to WriteRequestBodies for enhanced logging in the API server (75-ocp4-cis-audit-profile-set.yaml).

Ingress Controller Configuration:

• Configured custom TLS cipher suites and set the minimum TLS version to TLS 1.2 for improved security (75-ocp4-cis-kubelet-configure-tls-cipher-suites-ingresscontroller.yaml).

Machine Configuration for Audit Rules:

• Added audit rules for DAC modification events (e.g., chmod, chown) to monitor changes to file permissions (75-rhcos4-e8-master-audit-rules-dac-modification-chmod.yaml, 75-rhcos4-e8-master-audit-rules-dac-modification-chown.yaml). [1] [2]
• Introduced audit rules for execution of privileged commands (e.g., chcon, restorecon, semanage, setfiles, setsebool, seunshare) to track sensitive operations (75-rhcos4-e8-master-audit-rules-execution-chcon.yaml, 75-rhcos4-e8-master-audit-rules-execution-restorecon.yaml, 75-rhcos4-e8-master-audit-rules-execution-semanage.yaml, 75-rhcos4-e8-master-audit-rules-execution-setfiles.yaml, 75-rhcos4-e8-master-audit-rules-execution-setsebool.yaml, 75-rhcos4-e8-master-audit-rules-execution-seunshare.yaml). [1] [2] [3] [4] [5] [6]
• Configured audit rules for kernel module loading and unloading events (75-rhcos4-e8-master-audit-rules-kernel-module-loading-delete.yaml, 75-rhcos4-e8-master-audit-rules-kernel-module-loading-finit.yaml, 75-rhcos4-e8-master-audit-rules-kernel-module-loading-init.yaml). [1] [2] [3]
• Added audit rules for login events (faillock, lastlog, tallylog) to monitor authentication-related activities (75-rhcos4-e8-master-audit-rules-login-events-faillock.yaml, 75-rhcos4-e8-master-audit-rules-login-events-lastlog.yaml, 75-rhcos4-e8-master-audit-rules-login-events-tallylog.yaml). [1] [2] [3]
• Introduced audit rules for network configuration modifications and sysadmin actions to track system changes (75-rhcos4-e8-master-audit-rules-networkconfig-modification.yaml, 75-rhcos4-e8-master-audit-rules-sysadmin-actions.yaml). [1] [2]

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: sebrandon1
Once this PR has been reviewed and has the lgtm label, please assign imiller0 for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[yuvalk]

it would be much helpful if you could split the commits,
so that each change have it's own commit and msg to explain what it is and where it is coming from

for a starter, I would move the PR msg into the commit

it would be nice to have links like
https://static.open-scap.org/ssg-guides/ssg-rhel7-guide-C2S.html#xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_chmod

[yuvalk]

can we please keep the human readable format for MCs?
see other MCs in this repo for examples on how to generate them..

[sebrandon1]

Other entries for this sort of source entry are using base64 encoding such as:
https://github.com/openshift-kni/telco-reference/blob/main/telco-ran/configuration/source-crs/extra-manifest/01-disk-encryption-pcr-rebind-worker.yaml#L19-L20

Should I be using that here as well? As a note, the source line is just straight up copied from the complianceremediation object in OCP so we can modify to whatever we need.

[sebrandon1]

I created a new commit using a script that looks through the objects and writes a plaintext comment.

What do you think @yuvalk? This would prevent us having to create a builder, base64 anything, etc.

[imiller0]

A couple comments on specific files.
More generally, how will these be maintained release-over-release. Is there a way to validate in CI if there are new/changed hardening recommendations?

[sebrandon1]

I added some README files in this commit that tries to summarize what's going on in the various machine configs. We can still delete/remove any that might be too much of a performance hit/risk.

I was also able to do all of the newly created "combo" YAML files with a script based on path.

[mwlinca]

are we still waiting for review before merge for this one? Just saying Dev Complete is EoW

[sebrandon1]

@mwlinca I'm in touch with our KPI pipeline team to add these MachineConfigs to a potential pipeline to gather quantifiable performance data.

[sebrandon1]

I put up a new PR: #339 with specifically the YAMLs that correspond to high level compliance remediations. Those changes are also found in this PR but I was hoping to make it easier to narrow down, review, and test.

The real test will be the medium severity items which there seems to be 74 of.

bpalm at bpalm-mac in ~/Repositories/go/src/github.com/sebrandon1/compliance-scripts on main [!]
$ oc get compliancecheckresult -A | grep high | grep FAIL | wc -l
       7

bpalm at bpalm-mac in ~/Repositories/go/src/github.com/sebrandon1/compliance-scripts on main [!?]
$ oc get compliancecheckresult -A | grep medium | grep FAIL | wc -l
      74

bpalm at bpalm-mac in ~/Repositories/go/src/github.com/sebrandon1/compliance-scripts on main [!?]
$ oc get compliancecheckresult -A | grep " low" | grep FAIL | wc -l
       4

[sebrandon1]

Closing in favor of: #466