CNF-21212: RAN Hardening (4.22) - HIGH Severity Compliance Remediations#529
CNF-21212: RAN Hardening (4.22) - HIGH Severity Compliance Remediations#529sebrandon1 wants to merge 1 commit into
Conversation
|
@sebrandon1: This pull request references CNF-21212 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set. DetailsIn response to this:
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 openshift-eng/jira-lifecycle-plugin repository. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: sebrandon1 The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
@sebrandon1: This pull request references CNF-21212 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set. DetailsIn response to this:
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 openshift-eng/jira-lifecycle-plugin repository. |
|
@sebrandon1: This pull request references CNF-21212 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set. DetailsIn response to this:
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 openshift-eng/jira-lifecycle-plugin repository. |
|
@sebrandon1: This pull request references CNF-21212 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set. DetailsIn response to this:
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 openshift-eng/jira-lifecycle-plugin repository. |
e86aac8 to
adad827
Compare
adad827 to
91856c2
Compare
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 59 minutes and 16 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (9)
📝 WalkthroughWalkthroughAdds six new OpenShift MachineConfig resources for security hardening (crypto policy, PAM authentication, SSH configuration), registers them in metadata, updates ignore patterns, and provides documentation for the hardening reference configurations. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Updated H1 and H2 RemediationsRewrote both MachineConfigs after discovering the compliance operator's own remediations are broken: H1 (Crypto Policy): Now deploys systemd unit to both master and worker roles. Fixed service ordering. Removed single-run guard. H2 (PAM Empty Passwords): Compliance operator generates RHEL 8 era PAM templates that don't match RHCOS 9. Scanner still reports FAIL after applying the operator's own remediation. Fix: use actual RHCOS 9 system-auth/password-auth with nullok surgically removed. Verified on cnfdt16 (OCP 4.22, 3 masters + 2 workers): H1 PASS, H2 PASS, H3 PASS (via PR #466). |
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In
`@telco-ran/configuration/machineconfigs/crypto-policy/75-crypto-policy-high-master.yaml`:
- Around line 16-26: The unit currently only orders Before=sshd.service so many
services started by multi-user.target may inherit the old policy; modify the
unit that contains ExecStart=/usr/bin/update-crypto-policies --set
DEFAULT:NO-SHA1 (the oneshot service with RemainAfterExit=yes and
WantedBy=multi-user.target) to order it before multi-user.target (e.g., replace
or add Before=multi-user.target) so the crypto policy is applied before all
multi-user services start.
In
`@telco-ran/configuration/machineconfigs/crypto-policy/75-crypto-policy-high-worker.yaml`:
- Around line 16-26: The unit runs update-crypto-policies
(ExecStart=/usr/bin/update-crypto-policies --set DEFAULT:NO-SHA1) too late (only
Before=sshd.service, WantedBy=multi-user.target) so other critical daemons may
start without the new policy; modify the unit in
75-crypto-policy-high-worker.yaml to explicitly order it before workload
services (e.g., add Before=kubelet.service containerd.service docker.service
crio.service sshd.service) while keeping
After=systemd-machine-id-commit.service, and move the install target earlier
(e.g., change WantedBy=basic.target or sysinit.target) so the policy is applied
before those services initialize.
In `@telco-ran/configuration/machineconfigs/pam/75-pam-auth-high-master.yaml`:
- Around line 13-24: The MachineConfig "75-pam-auth-high-master.yaml" is pinning
full PAM files (system-auth and password-auth) via overwrite: true and encoded
source blobs, which will forever fork RHEL's authselect-managed files; instead
remove the overwrite/full-file contents for system-auth and password-auth and
implement the change as an authselect custom profile (deploy the custom profile
and enable it via authselect) so PAM is managed by authselect; update the
MachineConfig to deliver only the authselect profile assets or a bootstrap
script that runs authselect select/profile-apply rather than writing full
/etc/pam.d blobs (search for the keys overwrite: true, the source: "data:...,
and the target filenames system-auth and password-auth to locate the code to
change).
In `@telco-ran/configuration/machineconfigs/pam/75-pam-auth-high-worker.yaml`:
- Around line 13-24: The MachineConfig is overwriting the entire PAM stack by
setting overwrite: true and embedding full contents for /etc/pam.d/system-auth
and /etc/pam.d/password-auth (the long "source: data:..." blobs), which
conflicts with RHEL's authselect; instead, remove the full-file replacements and
implement the nullok removal via an authselect custom profile (authselect
create-profile myprofile --base-on sssd) or by changing the MachineConfig to
perform a targeted edit that patches only the specific pam_unix.so auth/password
lines; update the resources that reference /etc/pam.d/system-auth and
/etc/pam.d/password-auth accordingly, and ensure the MachineConfig no longer
uses overwrite: true for these paths so authselect-managed updates continue to
apply.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: ea701be7-359b-470e-a785-f4b095d37e47
📒 Files selected for processing (4)
telco-ran/configuration/machineconfigs/crypto-policy/75-crypto-policy-high-master.yamltelco-ran/configuration/machineconfigs/crypto-policy/75-crypto-policy-high-worker.yamltelco-ran/configuration/machineconfigs/pam/75-pam-auth-high-master.yamltelco-ran/configuration/machineconfigs/pam/75-pam-auth-high-worker.yaml
|
/lgtm |
imiller0
left a comment
There was a problem hiding this comment.
I agree with the code-rabbit assessment. The pam config ends up bringing the full implementation of that file into the reference meaning we need to regularly check for any updates in the distribution version and make sure this stays up to date. Is there an alternative (as code rabbit suggests) implementation?
91856c2 to
b500c1f
Compare
|
New changes are detected. LGTM label has been removed. |
2e824f9 to
e51ebcd
Compare
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In
`@telco-ran/configuration/kube-compare-reference/informational/hardening/75-crypto-policy-high-worker.yaml`:
- Around line 16-24: The systemd unit in 75-crypto-policy-high-worker.yaml
contains "ConditionFirstBoot=no" which prevents the unit from running on the
first boot; remove that ConditionFirstBoot line from the [Unit] section so the
oneshot service (ExecStart=/usr/bin/update-crypto-policies --set
DEFAULT:NO-SHA1, Type=oneshot, RemainAfterExit=yes) runs on every boot, and
apply the same removal to the matching entries in
75-crypto-policy-high-master.yaml and the crypto-policy files under
telco-ran/configuration/machineconfigs/crypto-policy/.
In
`@telco-ran/configuration/kube-compare-reference/informational/hardening/75-pam-auth-high-master.yaml`:
- Around line 13-24: The Ignition entries that fully overwrite
/etc/pam.d/system-auth and /etc/pam.d/password-auth embed a frozen PAM stack
which will drift from RHCOS changes; replace the full-file overwrite approach in
the manifest (the two entries with path: /etc/pam.d/system-auth and path:
/etc/pam.d/password-auth) with a non-destructive strategy: either remove the
hardcoded contents and let RHCOS supply its upstream templates, generate the PAM
contents at build-time from the target RHCOS release templates (and document the
pinned RHCOS version), or apply only minimal drop-in/patch changes (e.g., add
specific pam_faillock/pwhistory lines) instead of replacing the whole file so
future RHCOS updates (including added modules/reordering) are preserved.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 37c12c85-392c-4d0f-a1ad-434c0f542e7a
📒 Files selected for processing (13)
telco-ran/configuration/kube-compare-reference/informational/hardening/75-crypto-policy-high-master.yamltelco-ran/configuration/kube-compare-reference/informational/hardening/75-crypto-policy-high-worker.yamltelco-ran/configuration/kube-compare-reference/informational/hardening/75-pam-auth-high-master.yamltelco-ran/configuration/kube-compare-reference/informational/hardening/75-pam-auth-high-worker.yamltelco-ran/configuration/kube-compare-reference/informational/hardening/75-sshd-permit-empty-passwords-master.yamltelco-ran/configuration/kube-compare-reference/informational/hardening/75-sshd-permit-empty-passwords-worker.yamltelco-ran/configuration/kube-compare-reference/metadata.yamltelco-ran/configuration/machineconfigs/crypto-policy/75-crypto-policy-high-master.yamltelco-ran/configuration/machineconfigs/crypto-policy/75-crypto-policy-high-worker.yamltelco-ran/configuration/machineconfigs/pam/75-pam-auth-high-master.yamltelco-ran/configuration/machineconfigs/pam/75-pam-auth-high-worker.yamltelco-ran/configuration/machineconfigs/sshd/75-sshd-permit-empty-passwords-master.yamltelco-ran/configuration/machineconfigs/sshd/75-sshd-permit-empty-passwords-worker.yaml
✅ Files skipped from review due to trivial changes (8)
- telco-ran/configuration/kube-compare-reference/informational/hardening/75-sshd-permit-empty-passwords-worker.yaml
- telco-ran/configuration/machineconfigs/sshd/75-sshd-permit-empty-passwords-master.yaml
- telco-ran/configuration/kube-compare-reference/informational/hardening/75-sshd-permit-empty-passwords-master.yaml
- telco-ran/configuration/machineconfigs/crypto-policy/75-crypto-policy-high-worker.yaml
- telco-ran/configuration/machineconfigs/pam/75-pam-auth-high-worker.yaml
- telco-ran/configuration/machineconfigs/sshd/75-sshd-permit-empty-passwords-worker.yaml
- telco-ran/configuration/machineconfigs/crypto-policy/75-crypto-policy-high-master.yaml
- telco-ran/configuration/machineconfigs/pam/75-pam-auth-high-master.yaml
| [Unit] | ||
| Description=Configure System Crypto Policy | ||
| Before=sshd.service | ||
| After=systemd-machine-id-commit.service | ||
| ConditionFirstBoot=no | ||
| [Service] | ||
| Type=oneshot | ||
| ExecStart=/usr/bin/update-crypto-policies --set DEFAULT:NO-SHA1 | ||
| RemainAfterExit=yes |
There was a problem hiding this comment.
ConditionFirstBoot=no contradicts the stated intent and leaves a first-boot gap.
The PR description says the "single-run guard [was] removed so policy is enforced on boot", but ConditionFirstBoot=no is still a guard: systemd will skip this unit on the very first boot of the system. For nodes where this MachineConfig is delivered through Ignition at provisioning time (e.g., initial ZTP/install), the crypto policy will not be applied until the node reboots again — so freshly provisioned nodes briefly run with the default policy that still allows SHA-1.
If the goal is truly to enforce on every boot (idempotent oneshot + RemainAfterExit=yes makes that cheap and safe), drop the condition:
Proposed fix
[Unit]
Description=Configure System Crypto Policy
Before=sshd.service
After=systemd-machine-id-commit.service
- ConditionFirstBoot=no
[Service]
Type=oneshot
ExecStart=/usr/bin/update-crypto-policies --set DEFAULT:NO-SHA1
RemainAfterExit=yesSame fix applies to 75-crypto-policy-high-master.yaml and the corresponding files under telco-ran/configuration/machineconfigs/crypto-policy/.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@telco-ran/configuration/kube-compare-reference/informational/hardening/75-crypto-policy-high-worker.yaml`
around lines 16 - 24, The systemd unit in 75-crypto-policy-high-worker.yaml
contains "ConditionFirstBoot=no" which prevents the unit from running on the
first boot; remove that ConditionFirstBoot line from the [Unit] section so the
oneshot service (ExecStart=/usr/bin/update-crypto-policies --set
DEFAULT:NO-SHA1, Type=oneshot, RemainAfterExit=yes) runs on every boot, and
apply the same removal to the matching entries in
75-crypto-policy-high-master.yaml and the crypto-policy files under
telco-ran/configuration/machineconfigs/crypto-policy/.
3580903 to
0f629f6
Compare
|
Closing this PR. The SSHD hardening component (H3) no longer needs remediation — The H1 (crypto policy) and H2 (PAM no-empty-passwords) components of this PR do still FAIL and need remediation. These will be re-submitted as separate, focused PRs without the SSHD component. Verification images: quay.io/bapalm/k8scontent See CNF-19031 for updated scope. |
Summary
Add 2 MachineConfigs for HIGH severity compliance remediations from the OpenShift Compliance Operator (E8/CIS benchmarks).
Remediation Groups
HIGH Severity Settings
75-crypto-policy-high.yamlDEFAULT:NO-SHA175-pam-auth-high.yamlImplementation Notes
nullokoption (prevents empty password auth)Compliance Checks Remediated
rhcos4-e8-worker-configure-crypto-policyrhcos4-e8-master-configure-crypto-policyrhcos4-e8-worker-no-empty-passwordsrhcos4-e8-master-no-empty-passwordsRelated
Test plan
update-crypto-policies --show(expectDEFAULT:NO-SHA1)grep nullok /etc/pam.d/{system,password}-auth(expect no output)🤖 Generated with Claude Code