Merge pull request #55380 from sheriff-rh/co-0.1.60

stevsmit · web-flow · commit 5a40665caa98 · 2023-02-22T15:36:49.000-05:00
CMP-1779 Compliance Operator 0.1.61 release notes
diff --git a/modules/compliance-timeout.adoc b/modules/compliance-timeout.adoc
@@ -0,0 +1,37 @@
+// Module included in the following assemblies:
+//
+// * security/compliance_operator/compliance-operator-troubleshooting.adoc
+
+:_content-type: PROCEDURE
+[id="compliance-timeout_{context}"]
+= Configuring ScanSetting timeout
+
+The `ScanSetting` object has a timeout option that can be specified in the `ComplianceScanSetting` object as a duration string, such as `1h30m`. If the scan does not finish within the specified timeout, the scan reattempts until the `maxRetryOnTimeout` limit is reached.
+
+.Procedure
+
+* To set a `timeout` and `maxRetryOnTimeout` in ScanSetting, modify an existing `ScanSetting` object:
++
+[source,yaml]
+----
+apiVersion: compliance.openshift.io/v1alpha1
+kind: ScanSetting
+metadata:
+  name: default
+  namespace: openshift-compliance
+rawResultStorage:
+  rotation: 3
+  size: 1Gi
+roles:
+- worker
+- master
+scanTolerations:
+- effect: NoSchedule
+  key: node-role.kubernetes.io/master
+  operator: Exists
+schedule: '0 1 * * *'
+timeout: '10m0s' <1>
+maxRetryOnTimeout: 3 <2>
+----
+<1> The `timeout` variable is defined as a duration string, such as `1h30m`. The default value is `30m`.
+<2> The `maxRetryOnTimeout` variable defines how many times a retry is attempted. The default value is `3`.
diff --git a/security/compliance_operator/compliance-operator-release-notes.adoc b/security/compliance_operator/compliance-operator-release-notes.adoc
@@ -15,6 +15,48 @@ For an overview of the Compliance Operator, see xref:../../security/compliance_o
 
 To access the latest release, see xref:../../security/compliance_operator/compliance-operator-updating.adoc#olm-preparing-upgrade_compliance-operator-updating[Updating the Compliance Operator].
 
+[id="compliance-operator-release-notes-0-1-61"]
+== OpenShift Compliance Operator 0.1.61
+
+The following advisory is available for the OpenShift Compliance Operator 0.1.61:
+
+* link:https://access.redhat.com/errata/RHBA-2023:0557[RHBA-2023:0557 - OpenShift Compliance Operator bug fix update]
+
+[id="compliance-operator-0-1-61-new-features-and-enhancements"]
+=== New features and enhancements
+
+* The Compliance Operator now supports timeout configuration for Scanner Pods. The timeout is specified in the `ScanSetting` object. If the scan is not completed within the timeout, the scan retries until the maximum number of retries is reached. See xref:../../security/compliance_operator/compliance-operator-troubleshooting.html#compliance-timeout_compliance-troubleshooting[Configuring ScanSetting timeout] for more information.
+
+[id="compliance-operator-0-1-61-bug-fixes"]
+=== Bug fixes
+
+* Before this update, Compliance Operator remediations required variables as inputs. Remediations without variables set were applied cluster-wide and resulted in stuck nodes, even though it appeared the remediation applied correctly. With this update, the Compliance Operator validates if a variable needs to be supplied using a `TailoredProfile` for a remediation. (link:https://issues.redhat.com/browse/OCPBUGS-3864[*OCPBUGS-3864*])
+
+* 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*])
+
+* Before this update, the Compliance Operator did not check for empty kubelet configuration files when parsing machine configurations. As a result, the Compliance Operator would panic and crash. With this update, the Compliance Operator implements improved checking of the kubelet configuration data structure and only continues if it is fully rendered. (link:https://issues.redhat.com/browse/OCPBUGS-4621[*OCPBUGS-4621*])
+
+* 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*]):
+** `ocp4-cis-kubelet-enable-streaming-connections`
+** `ocp4-cis-kubelet-eviction-thresholds-set-hard-imagefs-available`
+** `ocp4-cis-kubelet-eviction-thresholds-set-hard-imagefs-inodesfree`
+** `ocp4-cis-kubelet-eviction-thresholds-set-hard-memory-available`
+** `ocp4-cis-kubelet-eviction-thresholds-set-hard-nodefs-available`
+
+* Before this update, the `selinux_confinement_of_daemons` rule failed running on the kubelet because of the permissions necessary for the kubelet to run. With this update, the `selinux_confinement_of_daemons` rule is disabled. (link:https://issues.redhat.com/browse/OCPBUGS-6968[*OCPBUGS-6968*])
+
 [id="compliance-operator-release-notes-0-1-59"]
 == OpenShift Compliance Operator 0.1.59
 
@@ -48,7 +90,7 @@ The following advisory is available for the OpenShift Compliance Operator 0.1.57
 
 * `KubeletConfig` checks changed from `Node` to `Platform` type. `KubeletConfig` checks the default configuration of the `KubeletConfig`. The configuration files are aggregated from all nodes into a single location per node pool. See xref:../../security/compliance_operator/compliance-operator-remediation.adoc#compliance-evaluate-kubeletconfig-rules_compliance-remediation[Evaluating `KubeletConfig` rules against default configuration values].
 
-* The `ScanSetting` Custom Resource now allows users to override the default CPU and memory limits of scanner pods through the `scanLimits` attribute.  For more information, see xref:../../security/compliance_operator/compliance-operator-troubleshooting.adoc#compliance-increasing-operator-limits_compliance-troubleshooting[Increasing Compliance Operator resource limits].
+* The `ScanSetting` Custom Resource now allows users to override the default CPU and memory limits of scanner pods through the `scanLimits` attribute. For more information, see xref:../../security/compliance_operator/compliance-operator-troubleshooting.adoc#compliance-increasing-operator-limits_compliance-troubleshooting[Increasing Compliance Operator resource limits].
 
 * A `PriorityClass` object can now be set through `ScanSetting`. This ensures the Compliance Operator is prioritized and minimizes the chance that the cluster falls out of compliance. For more information, see xref:../../security/compliance_operator/compliance-operator-advanced.adoc#compliance-priorityclass_compliance-advanced[Setting `PriorityClass` for `ScanSetting` scans].
 
@@ -187,7 +229,7 @@ The following advisory is available for the OpenShift Compliance Operator 0.1.49
 
 * Previously, the `openshift-compliance` content did not include platform-specific checks for network types. As a result, OVN- and SDN-specific checks would show as `failed` instead of `not-applicable` based on the network configuration. Now, new rules contain platform checks for networking rules, resulting in a more accurate assessment of network-specific checks. (link:https://bugzilla.redhat.com/show_bug.cgi?id=1994609[*BZ#1994609*])
 
-* Previously, the `ocp4-moderate-routes-protected-by-tls` rule incorrectly checked TLS settings that results in the rule failing the check, even if the connection secure SSL TLS protocol. Now, the check properly evaluates TLS settings that are consistent with the networking guidance and profile recommendations. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2002695[*BZ#2002695*])
+* Previously, the `ocp4-moderate-routes-protected-by-tls` rule incorrectly checked TLS settings that results in the rule failing the check, even if the connection secure SSL/TLS protocol. Now, the check properly evaluates TLS settings that are consistent with the networking guidance and profile recommendations. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2002695[*BZ#2002695*])
 
 * Previously, `ocp-cis-configure-network-policies-namespace` used pagination when requesting namespaces. This caused the rule to fail because the deployments truncated lists of more than 500 namespaces. Now, the entire namespace list is requested, and the rule for checking configured network policies works for deployments with more than 500 namespaces. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2038909[*BZ#2038909*])
 
@@ -211,7 +253,7 @@ The following advisory is available for the OpenShift Compliance Operator 0.1.48
 
 * Previously, some rules associated with extended Open Vulnerability and Assessment Language (OVAL) definitions had a `checkType` of `None`. This was because the Compliance Operator was not processing extended OVAL definitions when parsing rules. With this update, content from extended OVAL definitions is parsed so that these rules now have a `checkType` of either `Node` or `Platform`. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2040282[*BZ#2040282*])
 
-* Previously, a manually created `MachineConfig` object for `KubeletConfig` prevented a `KubeletConfig` object from being generated for remediation, leaving the remediation in the `Pending` state.  With this release, a `KubeletConfig`  object is created by the remediation, regardless if there is a manually created `MachineConfig` object for `KubeletConfig`. As a result, `KubeletConfig` remediations now work as expected. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2040401[*BZ#2040401*])
+* Previously, a manually created `MachineConfig` object for `KubeletConfig` prevented a `KubeletConfig` object from being generated for remediation, leaving the remediation in the `Pending` state. With this release, a `KubeletConfig`  object is created by the remediation, regardless if there is a manually created `MachineConfig` object for `KubeletConfig`. As a result, `KubeletConfig` remediations now work as expected. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2040401[*BZ#2040401*])
 
 [id="compliance-operator-release-notes-0-1-47"]
 == OpenShift Compliance Operator 0.1.47
@@ -257,11 +299,11 @@ The following advisory is available for the OpenShift Compliance Operator 0.1.44
 +
 * The Compliance Operator can now remediate `KubeletConfig` objects.
 +
-* A comment containing an error message is now added to help content developers differentiate between objects that do not exist in the cluster versus objects that cannot be fetched.
+* A comment containing an error message is now added to help content developers differentiate between objects that do not exist in the cluster compared to objects that cannot be fetched.
 +
 * Rule objects now contain two new attributes, `checkType` and `description`. These attributes allow you to determine if the rule pertains to a node check or platform check, and also allow you to review what the rule does.
 +
-* This enhancement removes the requirement that you have to extend an existing profile in order to create a tailored profile. This means the `extends` field in the `TailoredProfile` CRD is no longer mandatory. You can now select a list of rule objects to create a tailored profile.  Note that you must select whether your profile applies to nodes or the platform by setting the `compliance.openshift.io/product-type:` annotation or by setting the `-node` suffix for the `TailoredProfile` CR.
+* This enhancement removes the requirement that you have to extend an existing profile to create a tailored profile. This means the `extends` field in the `TailoredProfile` CRD is no longer mandatory. You can now select a list of rule objects to create a tailored profile. Note that you must select whether your profile applies to nodes or the platform by setting the `compliance.openshift.io/product-type:` annotation or by setting the `-node` suffix for the `TailoredProfile` CR.
 +
 * In this release, the Compliance Operator is now able to schedule scans on all nodes irrespective of their taints. Previously, the scan pods would only tolerated the `node-role.kubernetes.io/master taint`, meaning that they would either ran on nodes with no taints or only on nodes with the `node-role.kubernetes.io/master` taint. In deployments that use custom taints for their nodes, this resulted in the scans not being scheduled on those nodes. Now, the scan pods tolerate all node taints.
 +
diff --git a/security/compliance_operator/compliance-operator-troubleshooting.adoc b/security/compliance_operator/compliance-operator-troubleshooting.adoc
@@ -47,4 +47,6 @@ include::modules/compliance-increasing-operator-limits.adoc[leveloffset=+1]
 
 include::modules/operator-resource-constraints.adoc[leveloffset=+1]
 
+include::modules/compliance-timeout.adoc[leveloffset=+1]
+
 include::modules/support.adoc[leveloffset=+1]
diff --git a/security/security_profiles_operator/spo-release-notes.adoc b/security/security_profiles_operator/spo-release-notes.adoc
@@ -23,6 +23,4 @@ The following advisory is available for Security Profiles Operator 0.5.0:
 [id="spo-0-5-0-known-issue"]
 === Known issue
 
-* When uninstalling the Security Profiles Operator, the `MutatingWebhookConfiguration` object is not deleted and must be manually removed. As a workaround, delete the `MutatingWebhookConfiguration` object after uninstalling the Security Profiles Operator. These steps are defined in xref:../security_profiles_operator/spo-uninstalling.adoc#[Uninstalling the Security Profiles Operator].
-+
-link:https://issues.redhat.com/browse/OCPBUGS-4687[OCPBUGS-4687]
+* When uninstalling the Security Profiles Operator, the `MutatingWebhookConfiguration` object is not deleted and must be manually removed. As a workaround, delete the `MutatingWebhookConfiguration` object after uninstalling the Security Profiles Operator. These steps are defined in xref:../security_profiles_operator/spo-uninstalling.adoc#[Uninstalling the Security Profiles Operator]. link:https://issues.redhat.com/browse/OCPBUGS-4687[OCPBUGS-4687]
