Merge pull request #47659 from sheriff-rh/CMP-1421

CMP-1426 CO 0.1.53 release notes

Author: jeana-redhat

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

@@ -13,6 +13,53 @@ These release notes track the development of the Compliance Operator in the {pro
 
 For an overview of the Compliance Operator, see xref:../../security/compliance_operator/compliance-operator-understanding.adoc#understanding-compliance-operator[Understanding the Compliance Operator].
 
+[id="compliance-operator-release-notes-0-1-53"]
+== OpenShift Compliance Operator 0.1.53
+
+The following advisory is available for the OpenShift Compliance Operator 0.1.53:
+
+* link:https://access.redhat.com/errata/RHBA-2022:5537[RHBA-2022:5537 - OpenShift Compliance Operator bug fix update]
+
+[id="compliance-operator-0-1-53-bug-fixes"]
+=== Bug fixes
+
+* Previously, the `ocp4-kubelet-enable-streaming-connections` rule contained an incorrect variable comparison, resulting in false positive scan results. Now, the Compliance Operator provides accurate scan results when setting `streamingConnectionIdleTimeout`.  (link:https://bugzilla.redhat.com/show_bug.cgi?id=2069891[*BZ#2069891*])
+
+* Previously, group ownership for `/etc/openvswitch/conf.db` was incorrect on IBM Z architectures, resulting in `ocp4-cis-node-worker-file-groupowner-ovs-conf-db` check failures. Now, the check is marked `NOT-APPLICABLE` on IBM Z architecture systems. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2072597[*BZ#2072597*])
+
+* Previously, the `ocp4-cis-scc-limit-container-allowed-capabilities` rule reported in a `FAIL` state due to incomplete data regarding the security context constraints (SCC) rules in the deployment. Now, the result is `MANUAL`, which is consistent with other checks that require human intervention. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2077916[*BZ#2077916*])
+
+* Previously, the following rules failed to account for additional configuration paths for API servers and TLS certificates and keys, resulting in reported failures even if the certificates and keys were set properly:
++
+--
+** `ocp4-cis-api-server-kubelet-client-cert`
+** `ocp4-cis-api-server-kubelet-client-key`
+** `ocp4-cis-kubelet-configure-tls-cert`
+** `ocp4-cis-kubelet-configure-tls-key`
+--
++
+Now, the rules report accurately and observe legacy file paths specified in the kubelet configuration file. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2079813[*BZ#2079813*])
+
+* Previously, the `content_rule_oauth_or_oauthclient_inactivity_timeout` rule did not account for a configurable timeout set by the deployment when assessing compliance for timeouts. This resulted in the rule failing even if the timeout was valid. Now, the Compliance Operator uses the `var_oauth_inactivity_timeout` variable to set valid timeout length. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2081952[*BZ#2081952*])
+
+* Previously, the Compliance Operator used administrative permissions on namespaces not labeled appropriately for privileged use, resulting in warning messages regarding pod security-level violations. Now, the Compliance Operator has appropriate namespace labels and permission adjustments to access results without violating permissions. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2088202[*BZ#2088202*])
+
+* Previously, applying auto remediations for `rhcos4-high-master-sysctl-kernel-yama-ptrace-scope` and `rhcos4-sysctl-kernel-core-pattern` resulted in subsequent failures of those rules in scan results, even though they were remediated. Now, the rules report `PASS` accurately, even after remediations are applied.(link:https://bugzilla.redhat.com/show_bug.cgi?id=2094382[*BZ#2094382*])
+
+* Previously, the Compliance Operator would fail in a `CrashLoopBackoff` state because of out-of-memory exceptions. Now, the Compliance Operator is improved to handle large machine configuration data sets in memory and function correctly. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2094854[*BZ#2094854*])
+
+[id="compliance-operator-0-1-53-known-issue"]
+=== Known issue
+
+* When `"debug":true` is set within the `ScanSettingBinding` object, the pods generated by the `ScanSettingBinding` object are not removed when that binding is deleted. As a workaround, run the following command to delete the remaining pods:
++
+[source,terminal]
+----
+$ oc delete pods -l compliance.openshift.io/scan-name=ocp4-cis
+----
++
+(link:https://bugzilla.redhat.com/show_bug.cgi?id=2092913[*BZ#2092913*])
+
 [id="compliance-operator-release-notes-0-1-52"]
 == OpenShift Compliance Operator 0.1.52
 
@@ -43,6 +90,7 @@ The following advisory is available for the OpenShift Compliance Operator 0.1.52
 
 * When `"debug":true` is set within the `ScanSettingBinding` object, the pods generated by the `ScanSettingBinding` object are not removed when that binding is deleted. As a workaround, run the following command to delete the remaining pods:
 +
+[source,terminal]
 ----
 $ oc delete pods -l compliance.openshift.io/scan-name=ocp4-cis
 ----