(MODULES-11857) Scaffold OWASP CRS v4 support on EL10 via crs_source enum

[SugatD]

Summary

Scaffolds OWASP Core Rule Set (CRS) v4 support on EL10, where there is no mod_security_crs package, while preserving the existing package-based behaviour on EL7/8/9. Implements the design locked in the SPIKE MODULES-11852 (air-gapped customer with internal mirrors → mirror-first, no required internet call).

Introduces a crs_source enum on apache::mod::security:

crs_source	Behaviour	Default for
package	install mod_security_crs + per-rule symlinks (v2/v3 layout) — unchanged	EL7/8/9
archive	fetch CRS v4 tarball via puppet/archive from a configurable crs_archive_source (e.g. an internal mirror) + checksum, extract, wire v4 includes	opt-in
path	use a pre-staged CRS v4 directory (crs_path), no download	opt-in
none	engine only, no CRS	EL10

Changes

• manifests/params.pp — crs_source defaults (none on EL10, package elsewhere); archive source/checksum default to undef (user-pinned, no module-shipped version → avoids the CRS version/CVE treadmill).
• manifests/mod/security.pp — new params + case $crs_source for acquisition; rule activation branches between legacy per-rule symlinks (package) and the v4 include layout (archive/path); fail-fast validation when required inputs are missing. Extract dir is kept outside the purged modsec_dir.
• templates/mod/security_crs_v4.conf.epp — emits IncludeOptional <dir>/crs-setup.conf + rules/*.conf, auto-loaded via the existing IncludeOptional ${modsec_dir}/*.conf.
• metadata.json / .fixtures.yml — add puppetlabs/archive dependency.
• spec/classes/mod/security_spec.rb — cover none/archive/path modes + fail-fast cases.

Validation

• puppet parser validate, epp validate, puppet-lint, rubocop, metadata_lint: clean
• Unit specs: 282 examples, 0 failures (all crs_source values, with/without-checksum archive, fail-fast)
• Acceptance (CI): passes on all EL platforms incl. RedHat-10 / 10-arm (new spec/acceptance/mod_security_crs_v4_spec.rb exercises path + archive)
• Both modes also validated end-to-end on a RHEL 10.1 VM (apply, idempotency, configtest, SQLi/XSS/LFI → 403)

Known limitation / follow-up

• v4 tuning params — the CRS tuning parameters (paranoia_level, *_anomaly_threshold, allowed_methods, DOS knobs, …) currently feed only the legacy security_crs.conf (package mode). In archive/path (v4) modes the CRS-shipped crs-setup.conf is used as-is, so those params are not applied. Operators can edit crs-setup.conf directly (preserved by the creates guard). Tracked as follow-up MODULES-11895 — not a blocker for this PR.

CI note

The only red checks are Debian-13, SLES-12, SLES-15 acceptance — pre-existing platform failures (Debian-13 systemd start; SLES missing apache2ctl), unrelated to this change (same set is red on main nightly; this PR does not touch those code paths).

Relates to MODULES-11852 (design SPIKE), MODULES-11851 (engine restore), MODULES-11739 (parent), MODULES-11895 (follow-up).

🤖 Generated with Claude Code

[SugatD]

Acceptance tests now pass on all Enterprise Linux platforms (RedHat-7/8/9/10 + 10-arm, Rocky, CentOS), including the new spec/acceptance/mod_security_crs_v4_spec.rb which exercises both crs_source => path and archive on EL10. Both modes were also validated end-to-end on a RHEL 10.1 VM (apply, idempotency, apachectl configtest, and SQLi/XSS/LFI requests returning 403).

@kenyon — as requested, holding until acceptance passed; it now does, so this is ready for review.

The only red checks are Debian-13, SLES-12, and SLES-15 acceptance. These are pre-existing, unrelated platform failures (Debian-13 systemd start; SLES missing /usr/sbin/apache2ctl) — the same set is red on main's nightly and this PR does not touch those code paths.

Follow-up captured as MODULES-11895 (wiring the ModSecurity tuning params into the CRS v4 crs-setup.conf) — not a blocker here.