CNF-21212: RAN Hardening (4.22) - HIGH Severity Compliance Remediations

[sebrandon1]

Summary

Add 2 MachineConfigs for HIGH severity compliance remediations from the OpenShift Compliance Operator (E8/CIS benchmarks).

Remediation Groups

• H1: Crypto Policy - Configure system-wide crypto policy
• H2: PAM Empty Passwords - Disable empty password authentication

HIGH Severity Settings

Group	Category	MachineConfig	Setting	Value
H1	Crypto Policy	75-crypto-policy-high.yaml	crypto-policy	DEFAULT:NO-SHA1
H2	PAM Auth	75-pam-auth-high.yaml	nullok	removed from PAM

Implementation Notes

• Crypto policy: Uses a systemd oneshot unit with idempotency check
• PAM hardening: Uses sed to remove nullok option (prevents empty password auth)

Compliance Checks Remediated

• rhcos4-e8-worker-configure-crypto-policy
• rhcos4-e8-master-configure-crypto-policy
• rhcos4-e8-worker-no-empty-passwords
• rhcos4-e8-master-no-empty-passwords

Related

• Jira: CNF-21212 - RAN Hardening - Crypto/PAM (H1, H2)
• Epic: CNF-19031 - RAN Hardening (High Severity Compliance)
• Full Remediation Tracking

Test plan

• Apply MachineConfigs to a test cluster
• Verify crypto policy: update-crypto-policies --show (expect DEFAULT:NO-SHA1)
• Verify PAM: grep nullok /etc/pam.d/{system,password}-auth (expect no output)
• Run Compliance Operator scan to verify checks pass

🤖 Generated with Claude Code

[openshift-ci-robot]

@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.

Details

In response to this:

Summary

• Add 3 MachineConfigs for HIGH severity compliance remediations from the OpenShift Compliance Operator (E8/CIS benchmarks)
• These are the most critical security hardening settings per CO severity classification
• Related Jira: CNF-21212

HIGH Severity Settings

Group	Category	MachineConfig	Description
H1	Crypto Policy	75-crypto-policy-high.yaml	Configure system-wide crypto policy (DEFAULT:NO-SHA1)
H2	PAM Auth	75-pam-auth-high.yaml	Remove nullok from PAM to disable empty passwords
H3	SSHD	75-sshd-high.yaml	Set PermitEmptyPasswords no via sshd_config.d drop-in

Implementation Notes

• Crypto policy uses a systemd oneshot unit with idempotency check
• PAM hardening uses sed to remove nullok option (prevents empty password auth)
• SSHD uses a drop-in file approach for minimal impact

Test plan

• Apply MachineConfigs to a test cluster
• Verify crypto policy is set: update-crypto-policies --show
• Verify PAM files don't contain nullok: grep nullok /etc/pam.d/{system,password}-auth
• Verify sshd config: sshd -T | grep permitemptypasswords
• Run Compliance Operator scan to verify remediations

🤖 Generated with Claude Code

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.

[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

[openshift-ci-robot]

@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.

Details

In response to this:

Summary

• Add 2 MachineConfigs for HIGH severity compliance remediations from the OpenShift Compliance Operator (E8/CIS benchmarks)
• These are the most critical security hardening settings per CO severity classification
• Related Jira: CNF-21212

HIGH Severity Settings

Group	Category	MachineConfig	Description
H1	Crypto Policy	75-crypto-policy-high.yaml	Configure system-wide crypto policy (DEFAULT:NO-SHA1)
H2	PAM Auth	75-pam-auth-high.yaml	Remove nullok from PAM to disable empty passwords

Note: The HIGH severity SSHD setting (PermitEmptyPasswords) is consolidated with other SSHD settings in PR #466 to keep all SSH hardening together.

Implementation Notes

• Crypto policy uses a systemd oneshot unit with idempotency check
• PAM hardening uses sed to remove nullok option (prevents empty password auth)

Test plan

• Apply MachineConfigs to a test cluster
• Verify crypto policy is set: update-crypto-policies --show
• Verify PAM files don't contain nullok: grep nullok /etc/pam.d/{system,password}-auth
• Run Compliance Operator scan to verify remediations

🤖 Generated with Claude Code

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.

[openshift-ci-robot]

@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.

Details

In response to this:

Summary

Add 2 MachineConfigs for HIGH severity compliance remediations from the OpenShift Compliance Operator (E8/CIS benchmarks).

Remediation Groups

• H1: Crypto Policy - Configure system-wide crypto policy
• H2: PAM Empty Passwords - Disable empty password authentication

HIGH Severity Settings

Group	Category	MachineConfig	Setting	Value
H1	Crypto Policy	75-crypto-policy-high.yaml	crypto-policy	DEFAULT:NO-SHA1
H2	PAM Auth	75-pam-auth-high.yaml	nullok	removed from PAM

Implementation Notes

• Crypto policy: Uses a systemd oneshot unit with idempotency check
• PAM hardening: Uses sed to remove nullok option (prevents empty password auth)

Compliance Checks Remediated

• rhcos4-e8-worker-configure-crypto-policy
• rhcos4-e8-master-configure-crypto-policy
• rhcos4-e8-worker-no-empty-passwords
• rhcos4-e8-master-no-empty-passwords

Related

• Jira: CNF-21212
• Full Remediation Tracking

Test plan

• Apply MachineConfigs to a test cluster
• Verify crypto policy: update-crypto-policies --show (expect DEFAULT:NO-SHA1)
• Verify PAM: grep nullok /etc/pam.d/{system,password}-auth (expect no output)
• Run Compliance Operator scan to verify checks pass

🤖 Generated with Claude Code

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.

[openshift-ci-robot]

@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.

Details

In response to this:

Summary

Add 2 MachineConfigs for HIGH severity compliance remediations from the OpenShift Compliance Operator (E8/CIS benchmarks).

Remediation Groups

• H1: Crypto Policy - Configure system-wide crypto policy
• H2: PAM Empty Passwords - Disable empty password authentication

HIGH Severity Settings

Group	Category	MachineConfig	Setting	Value
H1	Crypto Policy	75-crypto-policy-high.yaml	crypto-policy	DEFAULT:NO-SHA1
H2	PAM Auth	75-pam-auth-high.yaml	nullok	removed from PAM

Implementation Notes

• Crypto policy: Uses a systemd oneshot unit with idempotency check
• PAM hardening: Uses sed to remove nullok option (prevents empty password auth)

Compliance Checks Remediated

• rhcos4-e8-worker-configure-crypto-policy
• rhcos4-e8-master-configure-crypto-policy
• rhcos4-e8-worker-no-empty-passwords
• rhcos4-e8-master-no-empty-passwords

Related

• Jira: CNF-21212 - RAN Hardening - Crypto/PAM (H1, H2)
• Epic: CNF-19031 - RAN Hardening (High Severity Compliance)
• Full Remediation Tracking

Test plan

• Apply MachineConfigs to a test cluster
• Verify crypto policy: update-crypto-policies --show (expect DEFAULT:NO-SHA1)
• Verify PAM: grep nullok /etc/pam.d/{system,password}-auth (expect no output)
• Run Compliance Operator scan to verify checks pass

🤖 Generated with Claude Code

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.

[coderabbitai]

📝 Walkthrough

Walkthrough

Four new OpenShift MachineConfig resources are added to apply security hardening policies. Two configure cryptographic policy settings to enforce DEFAULT:NO-SHA1 across master and worker nodes. Two configure PAM authentication by modifying system-auth and password-auth files to remove nullok from pam_unix.so directives on both node types.

Changes

Cohort / File(s)	Summary
Crypto Policy Configuration telco-ran/configuration/machineconfigs/crypto-policy/75-crypto-policy-high-master.yaml, telco-ran/configuration/machineconfigs/crypto-policy/75-crypto-policy-high-worker.yaml	Adds Ignition-based systemd oneshot units to apply crypto policy DEFAULT:NO-SHA1 via update-crypto-policies command, executed before sshd.service on master and worker nodes respectively.
PAM Authentication Configuration telco-ran/configuration/machineconfigs/pam/75-pam-auth-high-master.yaml, telco-ran/configuration/machineconfigs/pam/75-pam-auth-high-worker.yaml	Adds Ignition-based storage configuration to overwrite /etc/pam.d/system-auth and /etc/pam.d/password-auth files with embedded PAM stack definitions removing nullok from pam_unix.so auth and password lines on master and worker nodes respectively.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately reflects the main objective of adding MachineConfigs for HIGH-severity compliance remediations, specifically for crypto policy and PAM hardening.
Description check	✅ Passed	The description comprehensively documents the changes, including the two remediation groups (crypto policy and PAM), compliance checks addressed, and relevant test plan.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[sebrandon1]

Updated H1 and H2 Remediations

Rewrote 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).

[coderabbitai]

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

📥 Commits

Reviewing files that changed from the base of the PR and between d65ce23 and 91856c2.

📒 Files selected for processing (4)

• telco-ran/configuration/machineconfigs/crypto-policy/75-crypto-policy-high-master.yaml
• telco-ran/configuration/machineconfigs/crypto-policy/75-crypto-policy-high-worker.yaml
• telco-ran/configuration/machineconfigs/pam/75-pam-auth-high-master.yaml
• telco-ran/configuration/machineconfigs/pam/75-pam-auth-high-worker.yaml

[coderabbitai]

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🌐 Web query:

update-crypto-policies systemd when takes effect immediately

💡 Result:

Running update-crypto-policies (e.g., update-crypto-policies --set FUTURE) updates configuration files in /etc/crypto-policies/back-ends/ for supported cryptographic backends like OpenSSL, GnuTLS, NSS, OpenSSH, BIND, etc. These changes take effect for newly started applications and services immediately. For long-running services managed by systemd (e.g., sshd, httpd, nginx), a restart is typically required to reload the configs, as policies are loaded at startup. By default, the tool attempts to reload some running applications that support dynamic reloading via the --no-reload option (which skips this). However, official documentation (Red Hat, man pages) recommends restarting affected systemd services or rebooting for full effect, especially since not all services support reload. No specific --systemd option exists; systemd integration is via service restarts/reloads post-update.

Citations:

• 1: https://man.linuxreviews.org/man8/update-crypto-policies.8.html
• 2: https://manpages.opensuse.org/Tumbleweed/crypto-policies-scripts/update-crypto-policies.8.en.html
• 3: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening
• 4: https://oneuptime.com/blog/post/2026-03-04-configure-system-wide-crypto-policy-tls-rhel-9/view

---

🌐 Web query:

systemd multi-user.target boot order Before After ordering

💡 Result:

The systemd multi-user.target is a special target that represents a non-graphical multi-user system state, equivalent to SysV runlevels 2, 3, and 4. It is reached during boot after basic system initialization. Boot order (Before/After ordering from official docs and unit file): - Before: sysinit.target (implicit for most services), various early boot targets like local-fs.target, swap.target, network.target, getty.target (via symlinks in multi-user.target.wants). - Requires and After: basic.target (directly from unit file). - Conflicts: rescue.service, rescue.target. - After graphical.target pulls it in (graphical.target Requires=multi-user.target). Unit file contents (/usr/lib/systemd/system/multi-user.target): [Unit] Description=Multi-User System Documentation=man:systemd.special(7) Requires=basic.target Conflicts=rescue.service rescue.target After=basic.target rescue.service rescue.target AllowIsolate=yes To view on a system: systemctl cat multi-user.target or systemctl show multi-user.target -p Requires,After,Conflicts,Before. Services wanting to start at multi-user use WantedBy=multi-user.target in [Install]. To run before multi-user.target, use Before=multi-user.target. To run after, use After=multi-user.target. Boot flow: sysinit.target -> basic.target -> multi-user.target (-> graphical.target if default).

Citations:

• 1: https://oneuptime.com/blog/post/2026-03-04-manage-boot-targets-multi-user-graphical-rhel-9/view
• 2: https://www.baeldung.com/linux/systemd-target-multi-user
• 3: https://www.pearsonitcertification.com/articles/article.aspx?p=3129465&seqNum=2
• 4: https://www.freedesktop.org/software/systemd/man/latest/bootup.html
• 5: https://www.freedesktop.org/software/systemd/man/latest/systemd.target.html
• 6: https://manpages.ubuntu.com/manpages/jammy/man7/systemd.special.7.html
• 7: https://man7.org/linux/man-pages/man7/systemd.special.7.html
• 8: https://man.archlinux.org/man/systemd.special.7
• 9: https://www.freedesktop.org/software/systemd/man/latest/systemd.special.html

---

🏁 Script executed:

# Search for any existing crypto-policy related files or configurations in the repo
find . -type f -name "*crypto*" | head -20

Repository: openshift-kni/telco-reference

Length of output: 250

---

🏁 Script executed:

cat -n telco-ran/configuration/machineconfigs/crypto-policy/75-crypto-policy-high-master.yaml

Repository: openshift-kni/telco-reference

Length of output: 1010

---

Ensure the crypto policy is applied before all multi-user services start.

update-crypto-policies affects services when they start. This unit is ordered only before sshd.service but installed to multi-user.target, so other daemons (kubelet, crio, networking services, etc.) can start with the previous policy and retain it until restarted. To guarantee DEFAULT:NO-SHA1 is in effect across all services on boot, use Before=multi-user.target instead of Before=sshd.service, or add explicit ordering for every service that must inherit this policy.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@telco-ran/configuration/machineconfigs/crypto-policy/75-crypto-policy-high-master.yaml`
around lines 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.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

# First, let's check if the file exists and understand the repository structure
find . -name "*75-crypto-policy*" -o -name "*crypto-policy*" | head -20

Repository: openshift-kni/telco-reference

Length of output: 305

---

🏁 Script executed:

# List the directory structure around the crypto-policy config
git ls-files | grep -i crypto-policy

Repository: openshift-kni/telco-reference

Length of output: 246

---

🏁 Script executed:

# Check if this is an OpenShift/MachineConfig context by looking for related files
git ls-files | grep -E "(machineconfig|MachineConfig)" | head -20

Repository: openshift-kni/telco-reference

Length of output: 847

---

🏁 Script executed:

cat -n telco-ran/configuration/machineconfigs/crypto-policy/75-crypto-policy-high-worker.yaml

Repository: openshift-kni/telco-reference

Length of output: 1010

---

🏁 Script executed:

cat -n telco-ran/configuration/machineconfigs/crypto-policy/75-crypto-policy-high-master.yaml

Repository: openshift-kni/telco-reference

Length of output: 1010

---

🏁 Script executed:

# Search for any other references to crypto-policy or update-crypto-policies in the repo
rg -i "update-crypto-policies|crypto-policies" --type yaml

Repository: openshift-kni/telco-reference

Length of output: 398

---

🏁 Script executed:

# Look for any documentation or comments about crypto-policy strategy
rg -i "crypto.policy|nist|sha1" --type yaml -B 2 -A 2

Repository: openshift-kni/telco-reference

Length of output: 11608

---

🌐 Web query:

update-crypto-policies RHEL behavior persistent system configuration

💡 Result:

The update-crypto-policies command in RHEL manages system-wide cryptographic policies, which configure core cryptographic subsystems (e.g., OpenSSL, GnuTLS, NSS, OpenSSH) across the system. It creates a persistent system configuration. Key behavior: - Running update-crypto-policies --set (e.g., sudo update-crypto-policies --set FUTURE) overwrites /etc/crypto-policies/config with the selected policy name (including subpolicies like DEFAULT:NO-SHA1). - It generates policy files in /etc/crypto-policies/back-ends/ for each supported back-end (e.g., openssl.config, openssh.config symlinks or includes). - It writes the expanded policy definition to /etc/crypto-policies/state/CURRENT.pol and the policy name to /etc/crypto-policies/state/current. - These changes in /etc/ are persistent across reboots and package updates (though update-crypto-policies --check can detect mismatches if back-ends are manually edited). - Policies apply on application startup; a system reboot is recommended for full effect on running services. - View current policy: update-crypto-policies --show. - Predefined policies: DEFAULT (balanced), LEGACY (compatibility), FUTURE (strict), FIPS. This ensures centralized, persistent control over allowed algorithms, protocols, ciphers, and key sizes system-wide.

Citations:

• 1: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening
• 2: https://man.linuxreviews.org/man8/update-crypto-policies.8.html
• 3: https://access.redhat.com/articles/3666211
• 4: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening
• 5: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening

---

Ensure critical services apply the crypto policy immediately.

update-crypto-policies --set DEFAULT:NO-SHA1 writes persistent configuration to /etc/crypto-policies/, but policies apply only when services start. With this unit ordered only Before=sshd.service and installed to multi-user.target, other system daemons (kubelet, container runtimes, etc.) may start during boot before this service completes and initialize without the strict crypto policy. Add explicit ordering dependencies for all services that must enforce DEFAULT:NO-SHA1 on startup, or move this unit earlier in boot sequencing to guarantee it completes before critical workload services initialize.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@telco-ran/configuration/machineconfigs/crypto-policy/75-crypto-policy-high-worker.yaml`
around lines 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.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

# First, let's examine the actual file to understand its structure
cat -n telco-ran/configuration/machineconfigs/pam/75-pam-auth-high-master.yaml | head -30

Repository: openshift-kni/telco-reference

Length of output: 8369

---

🌐 Web query:

Ignition overwrite true behavior replaces entire file

💡 Result:

In CoreOS/Fedora CoreOS Ignition (the first-boot configuration tool), the overwrite: true field in a storage.files entry controls whether Ignition replaces the entire existing file at the specified path with the new contents from the config's contents.source (inline data or remote URL). By default (overwrite: false, since Ignition spec v3.0.0), if a file exists at the path: - Ignition verifies the file exists but does not modify its contents, mode, owner, or group. - If no contents are specified, it creates an empty file if needed. With overwrite: true: - Ignition overwrites (replaces) the entire existing file with the specified contents, regardless of prior content. - It also applies the specified mode, user, and group (defaults: mode 0644, root:root). - This is required to update files that already exist on first boot (e.g., from base image). Example config snippet: { "ignition": {"version": "3.5.0"}, "storage": { "files": [{ "path": "/etc/example.conf", "overwrite": true, "contents": {"source": "data:text/plain;base64,ZXhhbXBsZQ%3D%3D"}, "mode": 644 }] } } This replaces /etc/example.conf entirely with "example". Note: Ignition runs only once on first boot; changes are immutable afterward without reprovisioning. For idempotency on retries/failures, use verified hashes. This behavior is consistent across directories/links too, but the query focuses on files.

Citations:

• 1: Ignition failed: A file exists there already and overwrite is false coreos/fedora-coreos-tracker#428
• 2: https://coreos.github.io/ignition/configuration-v3_0/
• 3: https://coreos.github.io/ignition/migrating-configs/
• 4: https://coreos.github.io/ignition/operator-notes/
• 5: https://docs.fedoraproject.org/ast/fedora-coreos/managing-files
• 6: https://coreos.github.io/ignition/examples/

---

🌐 Web query:

RHEL authselect /etc/pam.d/system-auth profile-generated content

💡 Result:

The /etc/pam.d/system-auth file in RHEL is automatically generated and managed by authselect when a profile is selected (e.g., via 'authselect select sssd'). It contains a header warning not to edit manually, followed by PAM stack configurations for auth, account, password, and session phases. The exact content varies by selected profile (sssd, minimal, winbind) and enabled features (with-faillock, with-smartcard, etc.). Example header from RHEL 10 sssd profile (sources 7,8,9): # Do not modify this file manually, use authselect instead. Any user changes will be overwritten. # You can stop authselect from managing your configuration by calling 'authselect opt-out'. # See authselect(8) for more details. Example auth stack snippet from RHEL 8/9 sssd profile (sources 2,4,11,15,44): auth required pam_env.so auth required pam_faildelay.so delay=2000000 auth [default=1 ignore=ignore success=ok] pam_succeed_if.so uid >= 1000 quiet auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 1000 quiet_success auth sufficient pam_sss.so forward_pass auth required pam_deny.so The full template for sssd profile is available in the authselect upstream source (source 51): https://github.com/authselect/authselect/blob/master/profiles/sssd/system-auth It uses conditional syntax like {include if "with-faillock"} for modules such as pam_faillock.so, pam_fprintd.so (fingerprint), pam_u2f.so (U2F), pam_unix.so, pam_sss.so, pam_gssapi, etc., across all PAM types (auth, account, password, session). Common includes: pam_access.so (with-pamaccess), pam_gnome_keyring.so, pam_ecryptfs.so, pam_oddjob_mkhomedir.so. To view exact generated content on a system: cat /etc/pam.d/system-auth after running authselect select [features]. Direct manual edits are overwritten on next authselect apply-changes or select (sources 1-10). Use custom profiles for modifications (source 3). Profiles are in /usr/share/authselect/default/ on RHEL systems.

Citations:

• 1: https://oneuptime.com/blog/post/2026-03-04-authselect-manage-pam-profiles-rhel-9/view
• 2: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/configuring_authentication_and_authorization_in_rhel/configuring-user-authentication-using-authselect_configuring-authentication-and-authorization-in-rhel
• 3: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_authentication_and_authorization_in_rhel/configuring-user-authentication-using-authselect_configuring-authentication-and-authorization-in-rhel
• 4: https://oneuptime.com/blog/post/2026-03-04-authselect-profiles-pam-nss-rhel-9/view
• 5: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/configuring_authentication_and_authorization_in_rhel/configuring-user-authentication-using-authselect
• 6: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html-single/configuring_authentication_and_authorization_in_rhel/index
• 7: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/pdf/configuring_authentication_and_authorization_in_rhel/configuring-user-authentication-using-authselect_configuring-authentication-and-authorization-in-rhel
• 8: https://docs.redhat.com/en-us/documentation/red_hat_enterprise_linux/9/pdf/configuring_authentication_and_authorization_in_rhel/Red_Hat_Enterprise_Linux-9-Configuring_authentication_and_authorization_in_RHEL-en-US.pdf
• 9: https://www.coreruleset.org
• 10: https://www.rhcsa.guru
• 11: https://github.com/authselect/authselect/blob/master/profiles/sssd/system-auth

---

🌐 Web query:

RHEL 8 9 authselect custom profile PAM files management best practices

💡 Result:

Best practices for managing custom authselect profiles and PAM files on RHEL 8 and 9: 1. Avoid direct editing of /etc/pam.d/ files or /etc/nsswitch.conf. Authselect regenerates these from profile templates. Manual changes are overwritten and cause errors on authselect check or apply-changes. 2. Create custom profiles only when built-in profiles (sssd, winbind, minimal) with features (e.g., with-faillock, with-mkhomedir, with-smartcard) are insufficient. 3. To create a custom profile: sudo authselect create-profile myprofile -b sssd [--symlink-pam --symlink-meta --symlink-nsswitch] - Use --symlink-pam if NOT modifying PAM templates (system-auth, password-auth) to inherit upstream updates. - Omit --symlink-pam if customizing PAM templates, as changes must persist across authselect-libs upgrades. - Custom profiles stored in /etc/authselect/custom/myprofile/. 4. Edit templates in the custom profile directory: - PAM: system-auth, password-auth, postlogin, etc. - NSS: nsswitch.conf - Use authselect feature syntax like {if "with-faillock": ...} for conditional modules. 5. Apply the profile: sudo authselect select custom/myprofile [with-feature1 with-feature2] [--force] 6. Always run authselect check after changes to verify integrity. Fix issues with --force or restore backup. 7. Backup before changes: sudo authselect backup my-backup Restore: sudo authselect backup-restore my-backup 8. Apply user overrides: Edit /etc/authselect/user-* files then sudo authselect apply-changes. 9. For IdM/AD joins (ipa-client-install, realm join), do not modify auto-configured profiles. 10. Test thoroughly: authselect test to preview changes. This ensures maintainable, upgradable configurations without breaking authentication.

Citations:

• 1: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/configuring_authentication_and_authorization_in_rhel/configuring-user-authentication-using-authselect_configuring-authentication-and-authorization-in-rhel
• 2: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_authentication_and_authorization_in_rhel/configuring-user-authentication-using-authselect_configuring-authentication-and-authorization-in-rhel
• 3: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/configuring_authentication_and_authorization_in_rhel/configuring-user-authentication-using-authselect
• 4: https://man.linuxreviews.org/man8/authselect.8.html
• 5: https://linuxcommandlibrary.com/man/authselect

---

Avoid pinning the whole PAM stack in this MachineConfig.

overwrite: true plus full file bodies turns a one-option remediation into a fork of /etc/pam.d/system-auth and /etc/pam.d/password-auth. Ignition replaces the entire files, and these paths are managed by RHEL authselect—direct modifications are overwritten when authselect regenerates the profile. This means future base-image PAM changes will not apply unless these encoded blobs are manually refreshed. Use a custom authselect profile instead, which is the supported method for persistent PAM modifications.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@telco-ran/configuration/machineconfigs/pam/75-pam-auth-high-master.yaml`
around lines 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).

[coderabbitai]

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

# First, let's check if the file exists and examine its full content
find . -name "75-pam-auth-high-worker.yaml" -type f

Repository: openshift-kni/telco-reference

Length of output: 146

---

🏁 Script executed:

# Search for other pam-related config files to understand the pattern
find . -path "*pam*" -name "*.yaml" -o -path "*pam*" -name "*.yml" | head -20

Repository: openshift-kni/telco-reference

Length of output: 220

---

🌐 Web query:

RHEL authselect PAM files overwrite guidance best practices

💡 Result:

Do not directly edit PAM files in /etc/pam.d/ (such as system-auth, password-auth). Authselect manages these files and will overwrite manual changes. Best practices: - Use 'authselect select [with-]' to configure (e.g., 'authselect select sssd with-faillock'). Use --force only if necessary to overwrite changes. - Enable/disable features with 'authselect enable-feature ' or 'authselect disable-feature '. - Check integrity: 'authselect check'. If modified, run 'authselect apply-changes' to restore. - For customizations beyond features, create custom profile: 'authselect create-profile myprofile --base-on sssd', edit templates in /etc/authselect/custom/myprofile/, then 'authselect select custom/myprofile'. - Always backup first: 'authselect backup my-backup'. - Avoid opt-out unless necessary, as it gives full manual control but loses authselect benefits. - PAM files contain warnings: "Do not modify this file manually, use authselect instead. Any user changes will be overwritten." This applies to RHEL 8,9,10 per official docs.

Citations:

• 1: https://oneuptime.com/blog/post/2026-03-04-authselect-manage-pam-profiles-rhel-9/view
• 2: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/configuring_authentication_and_authorization_in_rhel/configuring-user-authentication-using-authselect_configuring-authentication-and-authorization-in-rhel
• 3: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_authentication_and_authorization_in_rhel/configuring-user-authentication-using-authselect_configuring-authentication-and-authorization-in-rhel
• 4: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html-single/configuring_authentication_and_authorization_in_rhel/index
• 5: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/configuring_authentication_and_authorization_in_rhel/configuring-user-authentication-using-authselect
• 6: https://access.redhat.com/solutions/7011856
• 7: https://oneuptime.com/blog/post/2026-03-04-authselect-profiles-pam-nss-rhel-9/view
• 8: https://fedoramagazine.org/how-to-use-authselect-to-configure-pam-in-fedora-linux/

---

🌐 Web query:

Ignition machineconfig overwrite true PAM authentication files

💡 Result:

In OpenShift Container Platform (using RHCOS nodes) and Fedora CoreOS, Ignition configurations within MachineConfig objects allow overwriting PAM authentication files (e.g., in /etc/pam.d/) using the storage.files section with overwrite: true. ## Key Concepts - Ignition storage.files: Specifies files to write to the filesystem. The overwrite field (boolean, defaults to false) determines if an existing file at the path is replaced. - From Ignition spec: Files default to overwrite: false since v3.0.0; set to true to force replacement. - MachineConfig: OpenShift's CRD embeds Ignition configs. The Machine Config Operator (MCO) applies them to nodes, rebooting as needed. MCO detects drift if files change outside its control but respects overwrite: true for managed files. - PAM Files: /etc/pam.d/* (e.g., system-auth, password-auth) control authentication. Customizing them via Ignition overwrites defaults for features like password auth, SSSD, or U2F. ## Example: Overwrite PAM Config for SSH Password Auth (FCOS/RHCOS) Use Butane YAML (converted to Ignition via butane tool), then embed in MachineConfig. Butane config (pam-auth.bu): variant: openshift # or fcos version: 4.17.0 # Match OCP/RHCOS version storage: files: - path: /etc/ssh/sshd_config.d/20-enable-passwords.conf mode: 0644 overwrite: true contents: inline: | PasswordAuthentication yes - path: /etc/pam.d/system-auth mode: 0644 overwrite: true contents: inline: | #%PAM-1.0 # Custom PAM stack; adjust as needed (e.g., add pam_unix.so for passwords) auth required pam_faildelay.so delay=2000000 auth sufficient pam_unix.so nullok try_first_pass # ... full stack from standard RHEL/FCOS PAM Convert: butane --pretty --strict pam-auth.bu -o pam-auth.yaml MachineConfig YAML (99-worker-pam.yaml): apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: worker name: 99-worker-pam spec: config: # Paste rendered Ignition from above ignition: version: 3.4.0 storage: files: - path: /etc/ssh/sshd_config.d/20-enable-passwords.conf overwrite: true mode: 420 # Decimal 0644 contents: source: data:text/plain;charset=utf-8;base64,UGFzc3dvcmRBdXRoZW50aWNhdGlvbiB5ZXM= # base64 of content - path: /etc/pam.d/system-auth overwrite: true mode: 420 contents: source: data:,... # base64 of full PAM content Apply: oc apply -f 99-worker-pam.yaml Nodes reboot, MCO applies changes. Monitor: oc get mcp worker. ## Warnings - Drift Detection: Manual edits to managed files degrade nodes until corrected. - Security: Enabling password auth increases risk; prefer SSH keys. - SSSD/PAM: For SSSD, overwrite /etc/pam.d/* and /etc/nsswitch.conf (see issues #653, #1774154). - Version Match: Use Ignition v3.4+ for OCP 4.15+.

Citations:

• 1: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html-single/machine_configuration/index
• 2: https://docs.redhat.com/en/documentation/openshift_container_platform/4.19/html-single/machine_configuration/index
• 3: https://github.com/openshift/machine-config-operator/blob/main/docs/MachineConfig.md
• 4: https://docs.openshift.com/container-platform/4.15/post_installation_configuration/machine-configuration-tasks.html
• 5: https://docs.openshift.com/container-platform/4.16/machine_configuration/machine-configs-configure.html
• 6: https://examples.openshift.pub/cluster-configuration/machine-config/
• 7: https://bugzilla.redhat.com/show_bug.cgi?id=1965089
• 8: pam_sss.so configured by default coreos/fedora-coreos-tracker#653
• 9: https://bugzilla.redhat.com/show_bug.cgi?id=1774154
• 10: https://docs.openshift.com/container-platform/4.17/machine_configuration/machine-configs-configure.html
• 11: https://coreos.github.io/ignition/configuration-v3_0/
• 12: https://coreos.github.io/ignition/migrating-configs/

---

Avoid pinning the full PAM stack in this MachineConfig.

overwrite: true with full file contents replaces /etc/pam.d/system-auth and /etc/pam.d/password-auth entirely. RHEL's authselect tool manages these files and will warn against manual edits. By using Ignition to override them, you take on the maintenance burden for these files—future base-image PAM changes, security updates, and authselect profile improvements will not apply unless you manually refresh these encoded blobs. Instead, use an authselect custom profile (authselect create-profile myprofile --base-on sssd) to apply the nullok removal in a way that integrates with authselect's lifecycle, or use targeted Ignition edits to modify only the specific lines needed.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@telco-ran/configuration/machineconfigs/pam/75-pam-auth-high-worker.yaml`
around lines 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.

[Demostenes777]

/lgtm