CNF-23448: RAN Hardening (5.0) - Audit Kernel Modules (M5)

[sebrandon1]

Summary

Adds MachineConfig to deploy audit rules for kernel module loading and unloading events on both master and worker nodes.

This addresses MEDIUM severity E8 compliance checks for auditing init_module, finit_module, and delete_module syscalls, ensuring all kernel module operations are recorded.

• Deploys audit rules via MachineConfig
• Separate master and worker MachineConfig files

Files

• 75-audit-kernel-modules-master.yaml
• 75-audit-kernel-modules-worker.yaml

Verification

After applying to a cluster, verify with:

oc debug node/<node> -- chroot /host auditctl -l | grep -E "init_module|delete_module"
# Expected: audit rules for module syscalls

Compliance scan verification:

oc get compliancecheckresult -n openshift-compliance | grep audit-rules-kernel-module
# Expected: PASS

Jira

• Story: CNF-23448
• Epic: CNF-22573 (RAN Hardening for 5.0)

[openshift-ci-robot]

@sebrandon1: This pull request references CNF-23448 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 "5.0.0" version, but no target version was set.

Details

In response to this:

Summary

Adds MachineConfig to deploy audit rules for kernel module loading and unloading events on both master and worker nodes.

This addresses MEDIUM severity E8 compliance checks for auditing init_module, finit_module, and delete_module syscalls, ensuring all kernel module operations are recorded.

• Deploys audit rules via MachineConfig
• Separate master and worker MachineConfig files

Files

• 75-audit-kernel-modules-master.yaml
• 75-audit-kernel-modules-worker.yaml

Verification

After applying to a cluster, verify with:

oc debug node/<node> -- chroot /host auditctl -l | grep -E "init_module|delete_module"
# Expected: audit rules for module syscalls

Compliance scan verification:

oc get compliancecheckresult -n openshift-compliance | grep audit-rules-kernel-module
# Expected: PASS

Jira

• Story: CNF-23448
• Epic: CNF-22573 (RAN Hardening for 5.0)

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 irinamihai 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

[coderabbitai]

Warning

Review limit reached

@sebrandon1, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 59 minutes and 57 seconds. Learn how PR review limits work.

Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file).

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits.

🚦 How do rate limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, the refill rate gradually slows as usage increases. The highest same-day bursts are limited more strictly.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Enterprise

Run ID: bcaebad6-9fee-46a9-b104-4218acbfdddb

📥 Commits

Reviewing files that changed from the base of the PR and between 8da6552 and ede6218.

📒 Files selected for processing (2)

• telco-ran/configuration/kube-compare-reference/informational/hardening/75-audit-kernel-modules-master.yaml
• telco-ran/configuration/kube-compare-reference/informational/hardening/75-audit-kernel-modules-worker.yaml

✨ 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]

Verification Test Results

Tested on cnfdt16 (OCP 4.22, RHCOS 9.8.20260403-0, 3 masters + 2 workers).

Apply: Applied 75-audit-kernel-modules-{master,worker}.yaml via oc apply.
Wait: MCP rolling update completed on all 5 nodes.
Verify:

$ oc debug node/cnfdt16-master-0 -- chroot /host cat /etc/audit/rules.d/75-kernel-modules.rules
# M5: Audit Kernel Module Loading (E8 Compliance)
-a always,exit -F arch=b64 -S init_module -S finit_module -k module_load
-a always,exit -F arch=b32 -S init_module -S finit_module -k module_load
-a always,exit -F arch=b64 -S delete_module -k module_unload
-a always,exit -F arch=b32 -S delete_module -k module_unload

$ oc debug node/cnfdt16-worker-0 -- chroot /host cat /etc/audit/audit.rules | grep -E 'init_module|delete_module'
-a always,exit -F arch=b64 -S init_module -S finit_module -k module_load
-a always,exit -F arch=b32 -S init_module -S finit_module -k module_load
-a always,exit -F arch=b64 -S delete_module -k module_unload
-a always,exit -F arch=b32 -S delete_module -k module_unload

Result: PASS — Audit rules for kernel module loading/unloading deployed and compiled into audit.rules on all master and worker nodes.

[sebrandon1]

Verification Test Results

Tested on cnfdt16 (OCP 5.0.0-0.nightly-2026-06-18-000016, RHCOS 10.2.20260617-0, Kubernetes v1.35.3, 3 masters + 2 workers).

Apply: Applied 75-audit-kernel-modules-{master,worker}.yaml via oc apply.
Wait: MCP rolling update completed on all 5 nodes.

Verify: The audit rules ARE correctly loaded on the nodes:

$ oc debug node/dhcp-97-140 -- chroot /host auditctl -l | grep module
-a always,exit -F arch=b64 -S init_module,finit_module -F key=module_load
-a always,exit -F arch=b32 -S init_module,finit_module -F key=module_load
-a always,exit -F arch=b64 -S delete_module -F key=module_unload
-a always,exit -F arch=b32 -S delete_module -F key=module_unload

Finding: Despite the rules being functionally loaded, the scanner still reports FAIL on all 12 audit-rules-kernel-module-loading-* checks. Root cause: RHCOS 10 uses audit-rules.service (via Wants=audit-rules.service in auditd.service) instead of the traditional ExecStartPost=augenrules mechanism. The scanner's OVAL check has a prerequisite that verifies augenrules or auditctl is configured - neither is present on RHCOS 10, so the prerequisite fails and the actual rule checks are never evaluated.

$ grep ExecStartPost /usr/lib/systemd/system/auditd.service
(empty - no augenrules or auditctl post-exec)

$ cat /etc/sysconfig/auditd
(file does not exist on RHCOS 10)

The audit daemon v4.x in RHEL 10 uses a different rule-loading mechanism that the ComplianceAsCode content doesn't yet support for the rhcos4 product.

Result: FAIL on OCP 5.0 / RHCOS 10 - upstream ComplianceAsCode scanner content bug. The audit rules are functionally correct and active on the nodes. The MachineConfig works correctly for OCP 4.x (RHCOS 9) and needs an upstream OVAL fix for OCP 5.0.

[sebrandon1]

Update: Scanner FAIL is a content image version gap (upstream fix exists)

After further investigation, this MachineConfig is correct and still needed for both OCP 4.x and 5.0. The scanner FAIL is a known content image version gap, not a problem with the MachineConfig.

Root cause: RHCOS 10 uses audit-rules.service with ExecStart=/sbin/augenrules --load (audit 4.0+) instead of ExecStartPost=augenrules in auditd.service. The OVAL prerequisite check in our content image (v0.1.80) looks for the old mechanism and fails.

Upstream fix already exists in ComplianceAsCode/content:

• Commit c6c48f0b74 (Apr 2026): "Fix augenrules OVAL check for Fedora and flatten conditionals" - updates checks to look in audit-rules.service for ExecStart=
• Commit e4c164cacc (Feb 2026): "enable oval checks for audit tools on fedora and fix failing tests"
• The updated OVAL check for RHEL10/OL10 looks in /usr/lib/systemd/system/audit-rules.service instead of auditd.service

Fix path: Rebuild our compliance content image from latest ComplianceAsCode master (post-v0.1.81) which includes these OVAL fixes. The content image at quay.io/bapalm/k8scontent:v0.1.81 is now available but the OVAL fix commits came after v0.1.81 — we need a build from current master.

Verification on cnfdt16: The audit rules ARE correctly loaded and active:

$ auditctl -l | grep module
-a always,exit -F arch=b64 -S init_module,finit_module -F key=module_load
-a always,exit -F arch=b32 -S init_module,finit_module -F key=module_load
-a always,exit -F arch=b64 -S delete_module -F key=module_unload
-a always,exit -F arch=b32 -S delete_module -F key=module_unload

This PR should remain open and be merged. The scanner will report PASS once the content image is updated.

[sebrandon1]

Superseded by #823 — migrated to compliance/5.0/m5-audit-modules branch.