Merge pull request #68970 from GroceryBoyJr/compliance-operator-140

Author: sheriff-rh

modules/compliance-custom-node-pools.adoc

@@ -8,31 +8,8 @@
 
 The Compliance Operator does not maintain a copy of each node pool configuration. The Compliance Operator aggregates consistent configuration options for all nodes within a single node pool into one copy of the configuration file. The Compliance Operator then uses the configuration file for a particular node pool to evaluate rules against nodes within that pool.
 
-If your cluster uses custom node pools outside the default `worker` and `master` node pools, you must supply additional variables to ensure the Compliance Operator aggregates a configuration file for that node pool.
-
 .Procedure
 
-. To check the configuration against all pools in an example cluster containing `master`, `worker`, and custom `example` node pools, set the value of the `ocp-var-role-master` and `opc-var-role-worker` fields to `example` in the `TailoredProfile` object:
-+
-[source,yaml]
-----
-apiVersion: compliance.openshift.io/v1alpha1
-kind: TailoredProfile
-metadata:
-  name: cis-example-tp
-spec:
-  extends: ocp4-cis
-  title: My modified NIST profile to scan example nodes
-  setValues:
-  - name: ocp4-var-role-master
-    value: example
-    rationale: test for example nodes
-  - name: ocp4-var-role-worker
-    value: example
-    rationale: test for example nodes
-  description: cis-example-scan
-----
-
 . Add the `example` role to the `ScanSetting` object that will be stored in the `ScanSettingBinding` CR:
 +
 [source,yaml]
@@ -72,17 +49,12 @@ profiles:
 - apiGroup: compliance.openshift.io/v1alpha1
   kind: Profile
   name: ocp4-cis-node
-- apiGroup: compliance.openshift.io/v1alpha1
-  kind: TailoredProfile
-  name: cis-example-tp
 settingsRef:
   apiGroup: compliance.openshift.io/v1alpha1
   kind: ScanSetting
   name: default
 ----
 
-The Compliance Operator checks the runtime `KubeletConfig` through the `Node/Proxy` API object and then uses variables such as `ocp-var-role-master` and `ocp-var-role-worker` to determine the nodes it performs the check against. In the `ComplianceCheckResult`, the `KubeletConfig` rules are shown as `ocp4-cis-kubelet-*`. The scan passes only if all selected nodes pass this check.
-
 .Verification
 
 * The Platform KubeletConfig rules are checked through the `Node/Proxy` object. You can find those rules by running the following command:

security/compliance_operator/compliance-operator-release-notes.adoc

@@ -15,6 +15,37 @@ For an overview of the Compliance Operator, see xref:../../security/compliance_o
 
 To access the latest release, see xref:../../security/compliance_operator/co-management/compliance-operator-updating.adoc#olm-preparing-upgrade_compliance-operator-updating[Updating the Compliance Operator].
 
+[id="compliance-operator-release-notes-1-4-0"]
+== OpenShift Compliance Operator 1.4.0
+
+The following advisory is available for the OpenShift Compliance Operator 1.4.0:
+
+* link:https://access.redhat.com/errata/RHBA-2023:7658[RHBA-2023:7658 - OpenShift Compliance Operator bug fix and enhancement update]
+
+[id="compliance-operator-1-4-0-new-features-and-enhancements"]
+=== New features and enhancements
+
+* With this update, clusters which use custom node pools outside the default `worker` and `master` node pools no longer need to supply additional variables to ensure Compliance Operator aggregates the configuration file for that node pool.
+
+* Users can now pause scan schedules by setting the `ScanSetting.suspend` attribute to `True`. This allows users to suspend a scan schedule and reactivate it without the need to delete and re-create the `ScanSettingBinding`. This simplifies pausing scan schedules during maintenance periods. (link:https://issues.redhat.com/browse/CMP-2123[*CMP-2123*])
+
+* Compliance Operator now supports an optional `version` attribute on `Profile` custom resources. (link:https://issues.redhat.com/browse/CMP-2125[*CMP-2125*])
+
+* Compliance Operator now supports profile names in `ComplianceRules`. (link:https://issues.redhat.com/browse/CMP-2126[*CMP-2126*])
+
+* Compliance Operator compatibility with improved `cronjob` API improvements is available in this release. (link:https://issues.redhat.com/browse/CMP-2310[*CMP-2310*])
+
+[id="compliance-operator-1-4-0-bug-fixes"]
+=== Bug fixes
+
+* With this update, `rprivate` default mount propagation is now handled correctly for root volume mounts of pods that rely on multipathing. (link:https://issues.redhat.com/browse/OCPBUGS-17494[*OCPBUGS-17494*])
+
+* Previously, the Compliance Operator would generate a remediation for `coreos_vsyscall_kernel_argument` without reconciling the rule even while applying the remediation. With release 1.4.0, the `coreos_vsyscall_kernel_argument` rule properly evaluates kernel arguments and generates an appropriate remediation.(link:https://issues.redhat.com/browse/OCPBUGS-8041[*OCPBUGS-8041*])
+
+* Before this update, rule `rhcos4-audit-rules-login-events-faillock` would fail even after auto-remediation has been applied. With this update, `rhcos4-audit-rules-login-events-faillock` failure locks are now applied correctly after auto-remediation. (link:https://issues.redhat.com/browse/OCPBUGS-24594[*OCPBUGS-24594*])
+
+* Previously, upgrades from Compliance Operator 1.3.1 to Compliance Operator 1.4.0 would cause OVS rules scan results to go from `PASS` to `NOT-APPLICABLE`. With this update, OVS rules scan results now show `PASS` (link:https://issues.redhat.com/browse/OCPBUGS-25323[*OCPBUGS-25323*])
+
 [id="compliance-operator-release-notes-1-3-1"]
 == OpenShift Compliance Operator 1.3.1
 
@@ -165,8 +196,6 @@ The following advisory is available for the OpenShift Compliance Operator 0.1.61
 
 * Before this update, the instructions for `ocp4-kubelet-configure-tls-cipher-suites` were incomplete, requiring users to refine the query manually. With this update, the query provided in `ocp4-kubelet-configure-tls-cipher-suites` returns the actual results to perform the audit steps. (link:https://issues.redhat.com/browse/OCPBUGS-3017[*OCPBUGS-3017*])
 
-* Before this update,`ScanSettingBinding` objects created without a `settingRef` variable did not use an appropriate default value. With this update, the `ScanSettingBinding` objects without a `settingRef` variable use the `default` value. (link:https://issues.redhat.com/browse/OCPBUGS-3420[*OCPBUGS-3420*])
-
 * Before this update, system reserved parameters were not generated in kubelet configuration files, causing the Compliance Operator to fail to unpause the machine config pool. With this update, the Compliance Operator omits system reserved parameters during machine configuration pool evaluation. (link:https://issues.redhat.com/browse/OCPBUGS-4445[*OCPBUGS-4445*])
 
 * Before this update, `ComplianceCheckResult` objects did not have correct descriptions. With this update, the Compliance Operator sources the `ComplianceCheckResult` information from the rule description. (link:https://issues.redhat.com/browse/OCPBUGS-4615[*OCPBUGS-4615*])
@@ -175,8 +204,6 @@ The following advisory is available for the OpenShift Compliance Operator 0.1.61
 
 * Before this update, the Compliance Operator generated remediations for kubelet evictions based on machine config pool name and a grace period, resulting in multiple remediations for a single eviction rule. With this update, the Compliance Operator applies all remediations for a single rule. (link:https://issues.redhat.com/browse/OCPBUGS-4338[*OCPBUGS-4338*])
 
-* Before this update, re-running scans on remediations that previously `Applied` might have been marked as `Outdated` after rescans were performed, despite no changes in the remediation content. The comparison of scans did not account for remediation metadata correctly. With this update, remediations retain the previously generated `Applied` status. (link:https://issues.redhat.com/browse/OCPBUGS-6710[*OCPBUGS-6710*])
-
 * Before this update, a regression occurred when attempting to create a `ScanSettingBinding` that was using a `TailoredProfile` with a non-default `MachineConfigPool` marked the `ScanSettingBinding` as `Failed`. With this update, functionality is restored and custom `ScanSettingBinding` using a `TailoredProfile` performs correctly. (link:https://issues.redhat.com/browse/OCPBUGS-6827[*OCPBUGS-6827*])
 
 * Before this update, some kubelet configuration parameters did not have default values. With this update, the following parameters contain default values (link:https://issues.redhat.com/browse/OCPBUGS-6708[*OCPBUGS-6708*]):
@@ -207,8 +234,6 @@ The following advisory is available for the OpenShift Compliance Operator 0.1.59
 
 * Previously, after the recent update to version 0.1.57, the `rerunner` service account (SA) was no longer owned by the cluster service version (CSV), which caused the SA to be removed during the Operator upgrade. Now, the CSV owns the `rerunner` SA in 0.1.59, and upgrades from any previous version will not result in a missing SA. (link:https://issues.redhat.com/browse/OCPBUGS-3452[*OCPBUGS-3452*])
 
-* In 0.1.57, the Operator started the controller metrics endpoint listening on port `8080`. This resulted in `TargetDown` alerts since cluster monitoring expected port is `8383`. With 0.1.59, the Operator starts the endpoint listening on port `8383` as expected. (link:https://issues.redhat.com/browse/OCPBUGS-3097[*OCPBUGS-3097*])
-
 [id="compliance-operator-release-notes-0-1-57"]
 == OpenShift Compliance Operator 0.1.57
 
@@ -477,7 +502,7 @@ The following advisory is available for the OpenShift Compliance Operator 0.1.39
 [id="compliance-operator-0-1-39-new-features-and-enhancements"]
 === New features and enhancements
 
-* Previously, the Compliance Operator was unable to parse Payment Card Industry Data Security Standard (PCI DSS) references. Now, the Operator can parse compliance content that ships with PCI DSS profiles.
+* Previously, the Compliance Operator was unable to parse Payment Card Industry Data Security Standard (PCI DSS) references. Now, the Operator can parse compliance content that is provided with PCI DSS profiles.
 +
 * Previously, the Compliance Operator was unable to execute rules for AU-5 control in the moderate profile. Now, permission is added to the Operator so that it can read *Prometheusrules.monitoring.coreos.com* objects and run the rules that cover AU-5 control in the moderate profile.