openshift/openshift-docs
1
0
Fork 0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-05 12:46:18 +01:00
Code Issues Releases Activity
Files
2ba4a675e5bac61681a22a0b0b61b66ff429f6b8
openshift-docs/security/compliance_operator/compliance-operator-release-notes.adoc
GroceryBoyJr 2ba4a675e5 CMP-4076: Compliance Operator 1.8.2 Release Note
2026-02-04 15:40:46 +00:00

800 lines
74 KiB
Plaintext
Raw Blame History

:_mod-docs-content-type: ASSEMBLY
//OpenShift Compliance Operator Release Notes
[id="compliance-operator-release-notes"]
= Compliance Operator release notes
:context: compliance-operator-release-notes-v0
include::_attributes/common-attributes.adoc[]
toc::[]
The Compliance Operator lets {product-title} administrators describe the required compliance state of a cluster and provides them with an overview of gaps and ways to remediate them.
These release notes track the development of the Compliance Operator in the {product-title}.
For an overview of the Compliance Operator, see xref:../../security/compliance_operator/co-concepts/compliance-operator-understanding.adoc#understanding-compliance-operator[Understanding the Compliance Operator].
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].
For more information on compliance support for all Red{nbsp}Hat products, see link:https://access.redhat.com/compliance[Product Compliance].
[id="compliance-operator-release-notes-1-8-2_{context}"]
== OpenShift Compliance Operator 1.8.2
The following advisory is available for the OpenShift Compliance Operator 1.8.2:
* link:https://access.redhat.com/errata/RHSA-2026:1859[RHSA-2026:1859 - OpenShift Compliance Operator 1.8.2 bug fix and enhancement update]
[id="compliance-operator-1-8-2-bug-fixes_{context}"]
=== Bug Fixes
* Red{nbsp}Hat recommends that customers upgrade to version 1.8.2 of Compliance Operator. For more information, see (link:https://access.redhat.com/security/cve/cve-2025-68973[CVE-2025-68973]).
[id="compliance-operator-release-notes-1-8-1_{context}"]
== OpenShift Compliance Operator 1.8.1
The following advisory is available for the OpenShift Compliance Operator 1.8.1:
* link:https://access.redhat.com/errata/RHSA-2026:0737[RHSA-2026:0737 - OpenShift Compliance Operator 1.8.1 bug fix and enhancement update]
[id="compliance-operator-1-8-1-bug-fixes_{context}"]
=== Bug Fixes
* Before this release, Compliance Operator could cause a privilege escalation due to incorrect permissions on `/etc/passwd`. With this release, the permissions have been corrected. For more information, see (link:https://access.redhat.com/security/cve/cve-2025-7195[CVE-2025-7195]).
* Previously, Compliance Operator scans using rhcos4 profile would incorrectly return `NOT-APPLICABLE` scan results when using {op-system-first} 10 systems. With this release, scans using rhcos4 profiles return `COMPLIANT` and `NON-COMPLIANT` results. For more information, see (link:https://issues.redhat.com/browse/CMP-4034[CMP-4034]).
[id="compliance-operator-release-notes-1-8-0_{context}"]
== OpenShift Compliance Operator 1.8.0
The following advisory is available for the OpenShift Compliance Operator 1.8.0:
* link:https://access.redhat.com/errata/RHSA-2025:21885[RHSA-2025:21885 - OpenShift Compliance Operator 1.8.0 bug fix and enhancement update]
[id="compliance-operator-1-8-0-new-features-and-enhancements_{context}"]
=== New features and enhancements
* With this update, the Compliance Operator provides the Common Expression Language (CEL) scanner in TECH PREVIEW status. The CEL scanner implements a new `CustomRule` Custom Resource Definition (CRD) that allows administrators to define and enforce custom security policies using CEL expressions. This new content format does not replace the existing XCCDF (Extensible Configuration Checklist Description Format) profiles but extends the ability to comply with custom security policies. For more information, see (link:https://issues.redhat.com/browse/CMP-3118[CMP-3118]).
* Previously, Compliance Operator required persistent storage to save raw scan results, which presented challenges for edge deployments and environments without storage infrastructure. With this release, Compliance Operator supports running scans without persistent storage. Administrators can set `rawResultStorage.enabled: false` in `ScanSetting` resources to disable storage of scan result files, allowing compliance scans to run in storage-constrained environments such as edge deployments and {sno}. Compliance check results remain fully available through `ComplianceCheckResult` resources. Raw result storage remains enabled by default for backward compatibility. For more information, see (link:https://issues.redhat.com/browse/CMP-1225[CMP-1225]).
* Previously, Compliance Operator provided `ocp4-bsi` and `ocp4-bsi-node` profiles for BSI compliance scanning. With this release, the `rhcos4-bsi` profile is now available, extending BSI standard coverage to RHCOS systems. For more information, see (link:https://issues.redhat.com/browse/CMP-3720[CMP-3720]).
* This release removes the deprecated CIS 1.4.0, CIS 1.5.0, DISA STIG V1R1 and DISA STIG V2R1 profiles. The newer versions have replaced these obsolete profiles for customer use. For more information, see (link:https://issues.redhat.com/browse/CMP-3712[CMP-3712]).
* With this release, PCI-DSS profiles 3.2.1 and 4.0.0 are now supported on ARM architecture systems. For more information, see (link:https://issues.redhat.com/browse/CMP-3723[CMP-3723]).
[id="compliance-operator-1-8-0-bug-fixes_{context}"]
=== Bug fixes
* With this release, automatic remediation for API server encryption now applies the appropriate encryption mode based on OpenShift version: AES-GCM for OpenShift 4.13.0 and higher versions, AES-CBC for earlier versions. Both encryption modes remain compliant across all OpenShift versions. For more information, see (link:https://issues.redhat.com/browse/CMP-3248[CMP-3248]).
* Prior to this release, Compliance Operator would remediate SSH settings on RHCOS hosts by deploying a fixed sshd_config file containing all SSH hardening settings. If the scan for corresponding rules failed, this could result in unintended configuration changes to SSH. With this release, Compliance Operator applies very specific remediations to SSH according to the rules shown in https://github.com/ComplianceAsCode/content/blob/master/shared/macros/10-kubernetes.jinja#L1-L154. For more information, see (link:https://issues.redhat.com/browse/CMP-3553[CMP-3553]).
* For prior versions of Compliance Operator, the log rotation function depended on finding the `logrotate` file in the `/etc/cron.daily` folder. With this release, Compliance Operator works with the `logrotate.timer` service. This provides reliable log rotation behavior from Compliance Operator.
// For more information, see (link:https://issues.redhat.com/browse/CMP-3172[CMP-3172]).
* For previous versions of Compliance Operator, it is possible for the `STIG ID` to be omitted from the compliance report. These omissions were caused by missing `stigref` and `stigid` values. With this release, the omissions have been corrected and now `STIG ID` reliably shows up in the compliance report.
// For more information, see (link:https://issues.redhat.com/browse/OCPBUGS-60143[OCPBUGS-60143].
* Prior to this release, Compliance Operator STIG control CNTR-OS-000720 selected rule `rhcos4-audit-rules-suid-privilege-function`, but since the rule was not available in Compliance Operator, no output was generated. With this release, the rule, `rhcos4-audit-rules-suid-privilege-function` is now available in Compliance Operator and listed in the scan output. For more information, see (link:https://issues.redhat.com/browse/CMP-3558[CMP-3558]).
* In previous versions of Compliance Operator, scanning with the `ocp4-stig` profile would fail for the rule `ocp4-stig-modified-audit-log-forwarding-uses-tls` even if TLS is enabled correctly. This would occur because the `tls://` field is no longer required by the `ClusterLogForwarder` resource, causing the scan output to show an incorrect `FAIL` result. With this release, the protocol prefix is not required and the scan output produces correct results. For more information, see (link:https://access.redhat.com/solutions/7016445[routes-protected-by-tls compliance check failing when ODF 4.11 is installed]).
* Previously, there was no automated method to check if API servers were using unsupported configuration overrides as recommended by CIS Benchmark control 1.2.31 or 1.2.33. This release provides dedicated rules for checking for unsupported configuration overrides.
* For prior releases of Compliance Operator, some rules were missing a variable reference in the annotation, such as rule `resource-requests-limits`. With this release, the variable reference is available for rules and the erroneous output is eliminated. For more information, see (link:https://issues.redhat.com/browse/CMP-3582[CMP-3582]).
* Previously, the `ocp4-routes-rate-limit` rule required setting rate limits for all routes outside the `openshift` and `kube` namespaces. However, using the feature and scanning for it presented problems because other namespaces managed by critical Operators should not be modified and not be scanned for the modification by Compliance Operator. With this release, routes managed by critical Operators are not flagged as errors by the Compliance Operator.
// For more information, see (link:https://issues.redhat.com/browse/CMP-3589[CMP-3589]).
* In prior versions of Compliance Operator, a `ComplianceScan` reported the warning `SDN not found` when the `openshift-sdn` networking provider was not found. In this release, Compliance Operator suppresses the warning when OpenShift-SDN is not the active networking provider. For more information, see (link:https://issues.redhat.com/browse/CMP-3591[CMP-3591]).
* Previously, duplicate variables could be accidentally created in `TailoredProfile` and were not correctly detected by Compliance Operator. With this release, duplicate `setValues` in `TailoredProfile` are identified and trigger a warning event from a compliance scan.
// For more information, see (link:https://issues.redhat.com/browse/CMP-3596[CMP-3596]).
* In previous releases of Compliance Operator, the rule ocp4-audit-log-forwarding-uses-tls failed when the `clusterlogforwarder` output configuration contained maps without a URL key. With this release, the rule correctly filters for outputs that have a URL field, showing `PASS` when TLS is properly enabled for `clusterlogforwarder`. For more information, see (link:https://issues.redhat.com/browse/CMP-3597[CMP-3597]).
* In prior versions of Compliance Operator, for the rule `rhcos4-service-systemd-coredump-disabled`, no remediation was generated after scanning the cluster. In this release, remediation is provided for `rhcos4-service-systemd-coredump-disabled`.
// For more information, see (link:https://issues.redhat.com/browse/CMP-3599[CMP-3599]).
* In prior versions of Compliance Operator, the rule to check the setting of `imagestream.spec.tags.importPolicy.scheduled` would return `FAIL` even when the configuration was correct. With this release, the rule now correctly excludes imagestreams managed by the samples operator and those owned by ClusterVersion, resulting in accurate compliance status reporting.
// For more information, see (link:https://issues.redhat.com/browse/CMP-3601[CMP-3601]).
* In prior releases, Compliance Operator included outdated TLS cipher suite rules which used unsupported configuration overrides with defective remediations. With this release, these outdated rules have been removed from the default profile. Also, the `ocp4-kubelet-configure-tls-cipher-suites-ingresscontroller` rule has been renamed to `ocp4-ingress-controller-tls-cipher-suites` for better organization. For more information, see (link:https://issues.redhat.com/browse/CMP-3606[CMP-3606]).
* In prior versions of Compliance Operator, creating `ComplianceScans` directly with custom content images failed during the profile deprecation check. With this release, Compliance Operator gracefully handles cases where the `ProfileBundle` cannot be determined, logging an informational message instead of failing the scan. For more information, see (link:https://issues.redhat.com/browse/CMP-3613[CMP-3613]).
* Previously, Compliance Operator scanned incorrectly flagged passthrough routes as NON-COMPLIANT with the `ocp4-routes-protected-by-tls` rule. With this release, passthrough routes are properly excluded from this rule because they delegate TLS termination to the backend application.
// For more information, see (link:https://issues.redhat.com/browse/CMP-3630[CMP-3630]).
[id="compliance-operator-release-notes-1-7-1_{context}"]
== OpenShift Compliance Operator 1.7.1
The following advisory is available for the OpenShift Compliance Operator 1.7.1:
* link:https://access.redhat.com/errata/RHBA-2025:14639[RHBA-2025:14639 - OpenShift Compliance Operator 1.7.1 bug fix update]
[NOTE]
====
The OpenShift Compliance Operator 1.7.1 supports PCI-DSS versions 3.2.1 and 4.0.0 on {ibm-z-name} (`s390x`) architecture.
====
[id="compliance-operator-1-7-1-bug-fixes_{context}"]
=== Bug fixes
* Previously, the Compliance Operator's `pauser` container could be terminated due to running out of memory, showing the status `OOMKilled). With this update, the memory limit for the `pauser` container is increased to prevent the error and improve overall stability. (link:https://issues.redhat.com/browse/OCPBUGS-50924[OCPBUGS-50924])
[id="compliance-operator-release-notes-1-7-0_{context}"]
== OpenShift Compliance Operator 1.7.0
The following advisory is available for the OpenShift Compliance Operator 1.7.0:
* link:https://access.redhat.com/errata/RHBA-2025:3728[RHBA-2025:3728 - OpenShift Compliance Operator 1.7.0 bug fix and enhancement update]
[id="compliance-operator-1-7-0-new-features-and-enhancements_{context}"]
=== New features and enhancements
* A `must-gather` extension is now available for the Compliance Operator installed on `aarch64`, `x86`, `ppc64le`, and `s390x` architectures. The `must-gather` tool provides crucial configuration details to Red Hat Customer Support and engineering. For more information, see xref:../../security/compliance_operator/co-support.adoc#compliance-must-gather_co-support[Using the must-gather tool for the Compliance Operator].
* CIS Benchmark Support has been added to Compliance Operator 1.7.0. The profile supported is CIS OpenShift Benchmark 1.7.0. For more information, see (link:https://issues.redhat.com/browse/CMP-3081[CMP-3081])
* Compliance Operator is now supported on `aarch64` architecture for CIS OpenShift Benchmark 1.7.0 and FedRAMP Moderate Revision 4. For more information, see (link:https://issues.redhat.com/browse/CMP-2960[CMP-2960])
* Compliance Operator 1.7.0 now supports OpenShift DISA STIG V2R2 profiles for OpenShift and RHCOS. For more information, see (link:https://issues.redhat.com/browse/CMP-3142[CMP-3142])
* Compliance Operator 1.7.0 now supports deprecation of old, unsupported profile versions, such as deprecation of CIS 1.4 profiles, CIS 1.5 profiles, DISA STIG V1R1 profiles and DISA STIG V2R1 profiles. For more information, see (link:https://issues.redhat.com/browse/CMP-3149[CMP-3149])
* With this release of Compliance Operator 1.7.0, the deprecation of older CIS and DISA STIG profiles mean that these older profiles will no longer be supported with the appearance of Compliance Operator 1.8.0. For more information, see (link:https://issues.redhat.com/browse/CMP-3284[CMP-3284])
* With this release of Compliance Operator 1.7.0, BSI profile support is added for OpenShift. For more information, refer to the KCS article link:https://access.redhat.com/articles/7045834[BSI Quick Check] and link:https://access.redhat.com/compliance/bsi[*BSI Compliance Summary*].
[id="compliance-operator-1-7-0-bug-fixes_{context}"]
=== Bug fixes
* Before this release, Compliance Operator would provide an unneeded remediation recommendation due to differences in filesystem structure for the `s390x` architecture. With this release, the Compliance Operator now recognizes the differences in filesystem structure and does not provide the misleading remediation. With this update, the rule is now more clearly defined. (link:https://issues.redhat.com/browse/OCPBUGS-33194[OCPBUGS-33194])
* Previously, the instructions for rule `ocp4-etcd-unique-ca` did not work for OpenShift 4.17 and later. With this update, the instructions and actionable steps are corrected. (link:https://issues.redhat.com/browse/OCPBUGS-42350[OCPBUGS-42350])
* When using the Compliance Operator with Cluster Logging Operator (CLO) version 6.0, various rules would fail. This is due to backwards incompatible changes to the CRDs that CLO uses. The Compliance Operator relies on those CRDs to verify logging functionality. The CRDs have been corrected to support the PCI-DSS profiles with CLO. (link:https://issues.redhat.com/browse/OCPBUGS-43229[OCPBUGS-43229])
* After installing Cluster Logging Operator (CLO) 6.0, users found that the ComplianceCheckResult `ocp4-cis-audit-log-forwarding-enabled` was failing because there was a change in the APIversion of the `clusterlogforwarder` resource. Log collection and forwarding configurations are now specified under the new API, part of the observability.openshift.io API group. (link:https://issues.redhat.com/browse/OCPBUGS-43585[OCPBUGS-43585])
* For previous releases of Compliance Operator, the scans would generate an error log for the reconcile loop on the Operator pod. With this release, the Compliance Operator controller logic is more stable. (link:https://issues.redhat.com/browse/OCPBUGS-51267[OCPBUGS-51267])
* Previously, the rules `file-integrity-exists` or `file-integrity-notification-enabled` would fail on `aarch64` OpenShift clusters. With this update, these rules evaluate as `NOT-APPLICABLE` on `aarch64` systems. (link:https://issues.redhat.com/browse/OCPBUGS-52884[OCPBUGS-52884])
* Before this release of the Compliance Operator, the rule `kubelet-configure-tls-cipher-suites` failed for the API server ciphers, resulting in `E2E-FAILURE` status. The rule has been updated to check new ciphers from RFC 8446, which are included with OpenShift 4.18. The rule is now being evaluated correctly. (link:https://issues.redhat.com/browse/OCPBUGS-54212[OCPBUGS-54212])
* Previously, the Compliance Operator platform scan would fail and produce the message `failed to parse Ignition config`. With this release, the Compliance Operator is safe to run on 4.19 clusters, when that version of OpenShift is available to customers. (link:https://issues.redhat.com/browse/OCPBUGS-54403[OCPBUGS-54403])
* Before this release of Compliance Operator, several rules were not platform aware, creating unneeded errors. Now that the rules have been properly ported to other architectures, those rules run correctly and users can observe some Compliance Check Results reporting `NOT-APPLICABLE` appropriately, depending on the architecture they are using. (link:https://issues.redhat.com/browse/OCPBUGS-53041[OCPBUGS-53041])
* Previously, the rule `file-groupowner-ovs-conf-db-hugetlbf` would fail unexpectedly. With this release, the rule fails only when this is the needed result. (link:http://issues.redhat.com/browse/OCPBUGS-55180[OCPBUGS-55190])
[id="compliance-operator-release-notes-1-6-2_{context}"]
== OpenShift Compliance Operator 1.6.2
The following advisory is available for the OpenShift Compliance Operator 1.6.2:
* link:https://access.redhat.com/errata/RHBA-2025:2659[RHBA-2025:2659 - OpenShift Compliance Operator 1.6.2 update]
CVE-2024-45338 is resolved in the Compliance Operator 1.6.2 release. (link:https://access.redhat.com/security/cve/cve-2024-45338[CVE-2024-45338])
[id="compliance-operator-release-notes-1-6-1_{context}"]
== OpenShift Compliance Operator 1.6.1
The following advisory is available for the OpenShift Compliance Operator 1.6.1:
* link:https://access.redhat.com/errata/RHBA-2024:10367[RHBA-2024:10367 - OpenShift Compliance Operator 1.6.1 update]
This update includes upgraded dependencies in underlying base images.
[id="compliance-operator-release-notes-1-6-0_{context}"]
== OpenShift Compliance Operator 1.6.0
The following advisory is available for the OpenShift Compliance Operator 1.6.0:
* link:https://access.redhat.com/errata/RHBA-2024:6761[RHBA-2024:6761 - OpenShift Compliance Operator 1.6.0 bug fix and enhancement update]
[id="compliance-operator-1-6-0-new-features-and-enhancements_{context}"]
=== New features and enhancements
* The Compliance Operator now contains supported profiles for Payment Card Industry Data Security Standard (PCI-DSS) version 4. For more information, see xref:../../security/compliance_operator/co-scans/compliance-operator-supported-profiles.adoc#compliance-supported-profiles_compliance-operator-supported-profiles[Supported compliance profiles].
* The Compliance Operator now contains supported profiles for Defense Information Systems Agency Security Technical Implementation Guide (DISA STIG) V2R1. For more information, see xref:../../security/compliance_operator/co-scans/compliance-operator-supported-profiles.adoc#compliance-supported-profiles_compliance-operator-supported-profiles[Supported compliance profiles].
* A `must-gather` extension is now available for the Compliance Operator installed on `x86`, `ppc64le`, and `s390x` architectures. The `must-gather` tool provides crucial configuration details to Red Hat Customer Support and engineering. For more information, see xref:../../security/compliance_operator/co-support.adoc#compliance-must-gather_co-support[Using the must-gather tool for the Compliance Operator].
[id="compliance-operator-1-6-0-bug-fixes_{context}"]
=== Bug fixes
* Before this release, a misleading description in the `ocp4-route-ip-whitelist` rule resulted in misunderstanding, causing potential for misconfigurations. With this update, the rule is now more clearly defined. (link:https://issues.redhat.com/browse/CMP-2485[CMP-2485])
* Previously, the reporting of all of the `ComplianceCheckResults` for a `DONE` status `ComplianceScan` was incomplete. With this update, annotation has been added to report the number of total `ComplianceCheckResults` for a `ComplianceScan` with a `DONE` status. (link:https://issues.redhat.com/browse/CMP-2615[CMP-2615])
* Previously, the `ocp4-cis-scc-limit-container-allowed-capabilities` rule description contained ambiguous guidelines, leading to confusion among users. With this update, the rule description and actionable steps are clarified. (link:https://issues.redhat.com/browse/OCPBUGS-17828[OCPBUGS-17828])
* Before this update, sysctl configurations caused certain auto remediations for RHCOS4 rules to fail scans in affected clusters. With this update, the correct sysctl settings are applied and RHCOS4 rules for FedRAMP High profiles pass scans correctly. (link:https://issues.redhat.com/browse/OCPBUGS-19690[OCPBUGS-19690])
* Before this update, an issue with a `jq` filter caused errors with the `rhacs-operator-controller-manager` deployment during compliance checks. With this update, the `jq` filter expression is updated and the `rhacs-operator-controller-manager` deployment is exempt from compliance checks pertaining to container resource limits, eliminating false positive results. (link:https://issues.redhat.com/browse/OCPBUGS-19690[OCPBUGS-19690])
* Before this update, `rhcos4-high` and `rhcos4-moderate` profiles checked values of an incorrectly titled configuration file. As a result, some scan checks could fail. With this update, the `rhcos4` profiles now check the correct configuration file and scans pass correctly. (link:https://issues.redhat.com/browse/OCPBUGS-31674[OCPBUGS-31674])
* Previously, the `accessokenInactivityTimeoutSeconds` variable used in the `oauthclient-inactivity-timeout` rule was immutable, leading to a `FAIL` status when performing DISA STIG scans. With this update, proper enforcement of the `accessTokenInactivityTimeoutSeconds` variable operates correctly and a `PASS` status is now possible. (link:https://issues.redhat.com/browse/OCPBUGS-32551[OCPBUGS-32551])
* Before this update, some annotations for rules were not updated, displaying the incorrect control standards. With this update, annotations for rules are updated correctly, ensuring the correct control standards are displayed. (link:https://issues.redhat.com/browse/OCPBUGS-34982[OCPBUGS-34982])
* Previously, when upgrading to Compliance Operator 1.5.1, an incorrectly referenced secret in a `ServiceMonitor` configuration caused integration issues with the Prometheus Operator. With this update, the Compliance Operator will accurately reference the secret containing the token for `ServiceMonitor` metrics. (link:https://issues.redhat.com/browse/OCPBUGS-39417[OCPBUGS-39417])
[id="compliance-operator-release-notes-1-5-1_{context}"]
== OpenShift Compliance Operator 1.5.1
The following advisory is available for the OpenShift Compliance Operator 1.5.1:
* link:https://access.redhat.com/errata/RHBA-2024:5956[RHBA-2024:5956 - OpenShift Compliance Operator 1.5.1 bug fix and enhancement update]
[id="compliance-operator-release-notes-1-5-0_{context}"]
== OpenShift Compliance Operator 1.5.0
The following advisory is available for the OpenShift Compliance Operator 1.5.0:
* link:https://access.redhat.com/errata/RHBA-2024:3533[RHBA-2024:3533 - OpenShift Compliance Operator 1.5.0 bug fix and enhancement update]
[id="compliance-operator-1-5-0-new-features-and-enhancements_{context}"]
=== New features and enhancements
* With this update, the Compliance Operator provides a unique profile ID for easier programmatic use. (link:https://issues.redhat.com/browse/CMP-2450[*CMP-2450*])
* With this release, the Compliance Operator is now tested and supported on the ROSA HCP environment. The Compliance Operator loads only Node profiles when running on ROSA HCP. This is because a Red{nbsp}Hat managed platform restricts access to the control plane, which makes Platform profiles irrelevant to the operator's function.(link:https://issues.redhat.com/browse/CMP-2581[*CMP-2581*])
[id="compliance-operator-1-5-0-bug-fixes_{context}"]
=== Bug fixes
* CVE-2024-2961 is resolved in the Compliance Operator 1.5.0 release. (link:https://access.redhat.com/security/cve/CVE-2024-2961[*CVE-2024-2961*])
* Previously, for ROSA HCP systems, profile listings were incorrect. This update allows the Compliance Operator to provide correct profile output. (link:https://issues.redhat.com/browse/OCPBUGS-34535[*OCPBUGS-34535*])
* With this release, namespaces can be excluded from the `ocp4-configure-network-policies-namespaces` check by setting the `ocp4-var-network-policies-namespaces-exempt-regex` variable in the tailored profile. (link:https://issues.redhat.com/browse/cmp-2543[*CMP-2543*])
[id="compliance-operator-release-notes-1-4-1"]
== OpenShift Compliance Operator 1.4.1
The following advisory is available for the OpenShift Compliance Operator 1.4.1:
* link:https://access.redhat.com/errata/RHBA-2024:1830[RHBA-2024:1830 - OpenShift Compliance Operator bug fix and enhancement update]
[id="compliance-operator-1-4-1-new-features-and-enhancements"]
=== New features and enhancements
* As of this release, the Compliance Operator now provides the CIS OpenShift 1.5.0 profile rules. (link:https://issues.redhat.com/browse/CMP-2447[*CMP-2447*])
* With this update, the Compliance Operator now provides `OCP4 STIG ID` and `SRG` with the profile rules. (link:https://issues.redhat.com/browse/CMP-2401[*CMP-2401*])
* With this update, obsolete rules being applied to `s390x` have been removed. (link:https://issues.redhat.com/browse/CMP-2471[*CMP-2471*])
[id="compliance-operator-1-4-1-bug-fixes"]
=== Bug fixes
* Previously, for {op-system-first} systems using {op-system-base-full} 9, application of the `ocp4-kubelet-enable-protect-kernel-sysctl-file-exist` rule failed. This update replaces the rule with `ocp4-kubelet-enable-protect-kernel-sysctl`. Now, after auto remediation is applied, {op-system-base} 9-based {op-system} systems will show `PASS` upon the application of this rule. (link:https://issues.redhat.com/browse/OCPBUGS-13589[*OCPBUGS-13589*])
* Previously, after applying compliance remediations using profile `rhcos4-e8`, the nodes were no longer accessible using SSH to the core user account. With this update, nodes remain accessible through SSH using the `sshkey1 option. (link:https://issues.redhat.com/browse/OCPBUGS-18331[*OCPBUGS-18331*])
* Previously, the `STIG` profile was missing rules from CaC that fulfill requirements on the published `STIG` for {product-title}. With this update, upon remediation, the cluster satisfies `STIG` requirements that can be remediated using Compliance Operator. (link:https://issues.redhat.com/browse/OCPBUGS-26193[*OCPBUGS-26193*])
* Previously, creating a `ScanSettingBinding` object with profiles of different types for multiple products bypassed a restriction against multiple products types in a binding. With this update, the product validation now allows multiple products regardless of the of profile types in the `ScanSettingBinding` object. (link:https://issues.redhat.com/browse/OCPBUGS-26229[*OCPBUGS-26229*])
* Previously, running the `rhcos4-service-debug-shell-disabled` rule showed as `FAIL` even after auto-remediation was applied. With this update, running the `rhcos4-service-debug-shell-disabled` rule now shows `PASS` after auto-remediation is applied. (link:https://issues.redhat.com/browse/OCPBUGS-28242[*OCPBUGS-28242*])
* With this update, instructions for the use of the `rhcos4-banner-etc-issue` rule are enhanced to provide more detail. (link:https://issues.redhat.com/browse/OCPBUGS-28797[*OCPBUGS-28797*])
* Previously the `api_server_api_priority_flowschema_catch_all` rule provided `FAIL` status on {product-title} 4.16 clusters. With this update, the `api_server_api_priority_flowschema_catch_all` rule provides `PASS` status on {product-title} 4.16 clusters. (link:https://issues.redhat.com/browse/OCPBUGS-28918[*OCPBUGS-28918*])
* Previously, when a profile was removed from a completed scan shown in a `ScanSettingBinding` (SSB) object, the Compliance Operator did not remove the old scan. Afterward, when launching a new SSB using the deleted profile, the Compliance Operator failed to update the result. With this release of the Compliance Operator, the new SSB now shows the new compliance check result. (link:https://issues.redhat.com/browse/OCPBUGS-29272[*OCPBUGS-29272*])
* Previously, on `ppc64le` architecture, the metrics service was not created. With this update, when deploying the Compliance Operator v1.4.1 on `ppc64le` architecture, the metrics service is now created correctly. (link:https://issues.redhat.com/browse/OCPBUGS-32797[*OCPBUGS-32797*])
* Previously, on a HyperShift hosted cluster, a scan with the `ocp4-pci-dss profile` will run into an unrecoverable error due to a `filter cannot iterate` issue. With this release, the scan for the `ocp4-pci-dss` profile will reach `done` status and return either a `Compliance` or `Non-Compliance` test result. (link:https://issues.redhat.com/browse/OCPBUGS-33067[*OCPBUGS-33067*])
[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
* Previously, on a cluster with Windows nodes, some rules will FAIL after auto remediation is applied because the Windows nodes were not skipped by the compliance scan. With this release, Windows nodes are correctly skipped when scanning. (link:https://issues.redhat.com/browse/OCPBUGS-7355[*OCPBUGS-7355*])
* 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
The following advisory is available for the OpenShift Compliance Operator 1.3.1:
* link:https://access.redhat.com/errata/RHBA-2023:5669[RHBA-2023:5669 - OpenShift Compliance Operator bug fix and enhancement update]
This update addresses a CVE in an underlying dependency.
//
// This will be un-commented for OCP 4.11-4.14 releases. Commented out in the main branch.
//
// [IMPORTANT]
// ====
// It is recommended to update the Compliance Operator to version 1.3.1 or later before updating your {product-title} cluster to version 4.14 or later.
// ====
[id="compliance-operator-1-3-1-new-features-and-enhancements"]
=== New features and enhancements
* You can install and use the Compliance Operator in an {product-title} cluster running in FIPS mode.
+
--
include::snippets/fips-snippet.adoc[]
--
[id="compliance-operator-1-3-1-known-issue"]
=== Known issue
* On a cluster with Windows nodes, some rules will FAIL after auto remediation is applied because the Windows nodes are not skipped by the compliance scan. This differs from the expected results because the Windows nodes must be skipped when scanning. (link:https://issues.redhat.com/browse/OCPBUGS-7355[*OCPBUGS-7355*])
[id="compliance-operator-release-notes-1-3-0"]
== OpenShift Compliance Operator 1.3.0
The following advisory is available for the OpenShift Compliance Operator 1.3.0:
* link:https://access.redhat.com/errata/RHBA-2023:5102[RHBA-2023:5102 - OpenShift Compliance Operator enhancement update]
[id="compliance-operator-1-3-0-new-features-and-enhancements"]
=== New features and enhancements
* The Defense Information Systems Agency Security Technical Implementation Guide (DISA-STIG) for {product-title} is now available from Compliance Operator 1.3.0. See xref:../../security/compliance_operator/co-scans/compliance-operator-supported-profiles.adoc#compliance-supported-profiles_compliance-operator-supported-profiles[Supported compliance profiles] for additional information.
* Compliance Operator 1.3.0 now supports {ibm-power-name} and {ibm-z-name} for NIST 800-53 Moderate-Impact Baseline for {product-title} platform and node profiles.
[id="compliance-operator-release-notes-1-2-0"]
== OpenShift Compliance Operator 1.2.0
The following advisory is available for the OpenShift Compliance Operator 1.2.0:
* link:https://access.redhat.com/errata/RHBA-2023:4245[RHBA-2023:4245 - OpenShift Compliance Operator enhancement update]
[id="compliance-operator-1-2-0-new-features-and-enhancements"]
=== New features and enhancements
* The CIS {product-title} 4 Benchmark v1.4.0 profile is now available for platform and node applications. To locate the CIS {product-title} v4 Benchmark, go to link:https://www.cisecurity.org/benchmark/kubernetes[CIS Benchmarks] and click *Download Latest CIS Benchmark*, where you can then register to download the benchmark.
+
[IMPORTANT]
====
Upgrading to Compliance Operator 1.2.0 will overwrite the CIS {product-title} 4 Benchmark 1.1.0 profiles.
If your {product-title} environment contains existing `cis` and `cis-node` remediations, there might be some differences in scan results after upgrading to Compliance Operator 1.2.0.
====
* Additional clarity for auditing security context constraints (SCCs) is now available for the `scc-limit-container-allowed-capabilities` rule.
[id="compliance-operator-release-notes-1-1-0"]
== OpenShift Compliance Operator 1.1.0
The following advisory is available for the OpenShift Compliance Operator 1.1.0:
* link:https://access.redhat.com/errata/RHBA-2023:3630[RHBA-2023:3630 - OpenShift Compliance Operator bug fix and enhancement update]
[id="compliance-operator-1-1-0-new-features-and-enhancements"]
=== New features and enhancements
* A start and end timestamp is now available in the `ComplianceScan` custom resource definition (CRD) status.
* The Compliance Operator can now be deployed on {hcp} using the software catalog by creating a `Subscription` file. For more information, see xref:../../security/compliance_operator/co-management/compliance-operator-installation.adoc#installing-compliance-operator-hcp_compliance-operator-installation[Installing the Compliance Operator on {hcp}].
[id="compliance-operator-1-1-0-bug-fixes"]
=== Bug fixes
* Before this update, some Compliance Operator rule instructions were not present. After this update, instructions are improved for the following rules:
+
** `classification_banner`
** `oauth_login_template_set`
** `oauth_logout_url_set`
** `oauth_provider_selection_set`
** `ocp_allowed_registries`
** `ocp_allowed_registries_for_import`
+
(link:https://issues.redhat.com/browse/OCPBUGS-10473[*OCPBUGS-10473*])
* Before this update, check accuracy and rule instructions were unclear. After this update, the check accuracy and instructions are improved for the following `sysctl` rules:
+
** `kubelet-enable-protect-kernel-sysctl`
** `kubelet-enable-protect-kernel-sysctl-kernel-keys-root-maxbytes`
** `kubelet-enable-protect-kernel-sysctl-kernel-keys-root-maxkeys`
** `kubelet-enable-protect-kernel-sysctl-kernel-panic`
** `kubelet-enable-protect-kernel-sysctl-kernel-panic-on-oops`
** `kubelet-enable-protect-kernel-sysctl-vm-overcommit-memory`
** `kubelet-enable-protect-kernel-sysctl-vm-panic-on-oom`
+
(link:https://issues.redhat.com/browse/OCPBUGS-11334[*OCPBUGS-11334*])
* Before this update, the `ocp4-alert-receiver-configured` rule did not include instructions. With this update, the `ocp4-alert-receiver-configured` rule now includes improved instructions. (link:https://issues.redhat.com/browse/OCPBUGS-7307[*OCPBUGS-7307*])
* Before this update, the `rhcos4-sshd-set-loglevel-info` rule would fail for the `rhcos4-e8` profile. With this update, the remediation for the `sshd-set-loglevel-info` rule was updated to apply the correct configuration changes, allowing subsequent scans to pass after the remediation is applied. (link:https://issues.redhat.com/browse/OCPBUGS-7816[*OCPBUGS-7816*])
* Before this update, a new installation of {product-title} with the latest Compliance Operator install failed on the `scheduler-no-bind-address` rule. With this update, the `scheduler-no-bind-address` rule has been disabled on newer versions of {product-title} since the parameter was removed. (link:https://issues.redhat.com/browse/OCPBUGS-8347[*OCPBUGS-8347*])
[id="compliance-operator-release-notes-1-0-0"]
== OpenShift Compliance Operator 1.0.0
The following advisory is available for the OpenShift Compliance Operator 1.0.0:
* link:https://access.redhat.com/errata/RHBA-2023:1682[RHBA-2023:1682 - OpenShift Compliance Operator bug fix update]
[id="compliance-operator-1-0-0-new-features-and-enhancements"]
=== New features and enhancements
* The Compliance Operator is now stable and the release channel is upgraded to `stable`. Future releases will follow link:https://semver.org/[Semantic Versioning]. 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-1-0-0-bug-fixes"]
=== Bug fixes
// 4.13 only, commenting out for now
// * Before this update, the `rhcos4-ensure-logrotate-activated` rule failed after auto-remediation was applied in {product-title} 4.13 environments. With this update, rules with auto-remediation available have a `PASS` result after the auto-remedations are applied. (link:https://issues.redhat.com/browse/OCPBUGS-10769[*OCPBUGS-10769*])
* Before this update, the compliance_operator_compliance_scan_error_total metric had an ERROR label with a different value for each error message. With this update, the compliance_operator_compliance_scan_error_total metric does not increase in values. (link:https://issues.redhat.com/browse/OCPBUGS-1803[*OCPBUGS-1803*])
* Before this update, the `ocp4-api-server-audit-log-maxsize` rule would result in a `FAIL` state. With this update, the error message has been removed from the metric, decreasing the cardinality of the metric in line with best practices. (link:https://issues.redhat.com/browse/OCPBUGS-7520[*OCPBUGS-7520*])
* Before this update, the `rhcos4-enable-fips-mode` rule description was misleading that FIPS could be enabled after installation. With this update, the `rhcos4-enable-fips-mode` rule description clarifies that FIPS must be enabled at install time. (link:https://issues.redhat.com/browse/OCPBUGS-8358[*OCPBUGS-8358*])
[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/co-scans/compliance-operator-troubleshooting.adoc#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, 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, 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
The following advisory is available for the OpenShift Compliance Operator 0.1.59:
* link:https://access.redhat.com/errata/RHBA-2022:8538[RHBA-2022:8538 - OpenShift Compliance Operator bug fix update]
[id="compliance-operator-0-1-59-new-features-and-enhancements"]
=== New features and enhancements
* The Compliance Operator now supports Payment Card Industry Data Security Standard (PCI-DSS) `ocp4-pci-dss` and `ocp4-pci-dss-node` profiles on the `ppc64le` architecture.
[id="compliance-operator-0-1-59-bug-fixes"]
=== Bug fixes
* Previously, the Compliance Operator did not support the Payment Card Industry Data Security Standard (PCI DSS) `ocp4-pci-dss` and `ocp4-pci-dss-node` profiles on different architectures such as `ppc64le`. Now, the Compliance Operator supports `ocp4-pci-dss` and `ocp4-pci-dss-node` profiles on the `ppc64le` architecture. (link:https://issues.redhat.com/browse/OCPBUGS-3252[*OCPBUGS-3252*])
* 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*])
[id="compliance-operator-release-notes-0-1-57"]
== OpenShift Compliance Operator 0.1.57
The following advisory is available for the OpenShift Compliance Operator 0.1.57:
* link:https://access.redhat.com/errata/RHBA-2022:6657[RHBA-2022:6657 - OpenShift Compliance Operator bug fix update]
[id="compliance-operator-0-1-57-new-features-and-enhancements"]
=== New features and enhancements
* `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/co-scans/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/co-scans/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/co-scans/compliance-operator-advanced.adoc#compliance-priorityclass_compliance-advanced[Setting `PriorityClass` for `ScanSetting` scans].
[id="compliance-operator-0-1-57-bug-fixes"]
=== Bug fixes
* Previously, the Compliance Operator hard-coded notifications to the default `openshift-compliance` namespace. If the Operator were installed in a non-default namespace, the notifications would not work as expected. Now, notifications work in non-default `openshift-compliance` namespaces. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2060726[*BZ#2060726*])
* Previously, the Compliance Operator was unable to evaluate default configurations used by kubelet objects, resulting in inaccurate results and false positives. xref:../../security/compliance_operator/co-scans/compliance-operator-remediation.adoc#compliance-evaluate-kubeletconfig-rules_compliance-remediation[This new feature] evaluates the kubelet configuration and now reports accurately. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2075041[*BZ#2075041*])
* Previously, the Compliance Operator reported the `ocp4-kubelet-configure-event-creation` rule in a `FAIL` state after applying an automatic remediation because the `eventRecordQPS` value was set higher than the default value. Now, the `ocp4-kubelet-configure-event-creation` rule remediation sets the default value, and the rule applies correctly. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2082416[*BZ#2082416*])
* The `ocp4-configure-network-policies` rule requires manual intervention to perform effectively. New descriptive instructions and rule updates increase applicability of the `ocp4-configure-network-policies` rule for clusters using Calico CNIs. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2091794[*BZ#2091794*])
* Previously, the Compliance Operator would not clean up pods used to scan infrastructure when using the `debug=true` option in the scan settings. This caused pods to be left on the cluster even after deleting the `ScanSettingBinding`. Now, pods are always deleted when a `ScanSettingBinding` is deleted.(link:https://bugzilla.redhat.com/show_bug.cgi?id=2092913[*BZ#2092913*])
* Previously, the Compliance Operator used an older version of the `operator-sdk` command that caused alerts about deprecated functionality. Now, an updated version of the `operator-sdk` command is included and there are no more alerts for deprecated functionality. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2098581[*BZ#2098581*])
* Previously, the Compliance Operator would fail to apply remediations if it could not determine the relationship between kubelet and machine configurations. Now, the Compliance Operator has improved handling of the machine configurations and is able to determine if a kubelet configuration is a subset of a machine configuration. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2102511[*BZ#2102511*])
* Previously, the rule for `ocp4-cis-node-master-kubelet-enable-cert-rotation` did not properly describe success criteria. As a result, the requirements for `RotateKubeletClientCertificate` were unclear. Now, the rule for `ocp4-cis-node-master-kubelet-enable-cert-rotation` reports accurately regardless of the configuration present in the kubelet configuration file. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2105153[*BZ#2105153*])
* Previously, the rule for checking idle streaming timeouts did not consider default values, resulting in inaccurate rule reporting. Now, more robust checks ensure increased accuracy in results based on default configuration values. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2105878[*BZ#2105878*])
* Previously, the Compliance Operator would fail to fetch API resources when parsing machine configurations without Ignition specifications, which caused the `api-check-pods` processes to crash loop. Now, the Compliance Operator handles Machine Config Pools that do not have Ignition specifications correctly. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2117268[*BZ#2117268*])
* Previously, rules evaluating the `modprobe` configuration would fail even after applying remediations due to a mismatch in values for the `modprobe` configuration. Now, the same values are used for the `modprobe` configuration in checks and remediations, ensuring consistent results. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2117747[*BZ#2117747*])
[id="compliance-operator-0-1-57-deprecations"]
=== Deprecations
* Specifying *Install into all namespaces in the cluster* or setting the `WATCH_NAMESPACES` environment variable to `""` no longer affects all namespaces. Any API resources installed in namespaces not specified at the time of Compliance Operator installation is no longer be operational. API resources might require creation in the selected namespace, or the `openshift-compliance` namespace by default. This change improves the Compliance Operator's memory usage.
[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-name} architectures, resulting in `ocp4-cis-node-worker-file-groupowner-ovs-conf-db` check failures. Now, the check is marked `NOT-APPLICABLE` on {ibm-z-name} 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
The following advisory is available for the OpenShift Compliance Operator 0.1.52:
* link:https://access.redhat.com/errata/RHBA-2022:4657[RHBA-2022:4657 - OpenShift Compliance Operator bug fix update]
[id="compliance-operator-0-1-52-new-features-and-enhancements"]
=== New features and enhancements
* The FedRAMP high SCAP profile is now available for use in {product-title} environments. For more information, See xref:../../security/compliance_operator/co-scans/compliance-operator-supported-profiles.adoc#compliance-operator-supported-profiles[Supported compliance profiles].
[id="compliance-operator-0-1-52-bug-fixes"]
=== Bug fixes
* Previously, the `OpenScap` container would crash due to a mount permission issue in a security environment where `DAC_OVERRIDE` capability is dropped. Now, executable mount permissions are applied to all users. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2082151[*BZ#2082151*])
* Previously, the compliance rule `ocp4-configure-network-policies` could be configured as `MANUAL`. Now, compliance rule `ocp4-configure-network-policies` is set to `AUTOMATIC`. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2072431[*BZ#2072431*])
* Previously, the Cluster Autoscaler would fail to scale down because the Compliance Operator scan pods were never removed after a scan. Now, the pods are removed from each node by default unless explicitly saved for debugging purposes. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2075029[*BZ#2075029*])
* Previously, applying the Compliance Operator to the `KubeletConfig` would result in the node going into a `NotReady` state due to unpausing the Machine Config Pools too early. Now, the Machine Config Pools are unpaused appropriately and the node operates correctly. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2071854[*BZ#2071854*])
* Previously, the Machine Config Operator used `base64` instead of `url-encoded` code in the latest release, causing Compliance Operator remediation to fail. Now, the Compliance Operator checks encoding to handle both `base64` and `url-encoded` Machine Config code and the remediation applies correctly. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2082431[*BZ#2082431*])
[id="compliance-operator-0-1-52-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-49"]
== OpenShift Compliance Operator 0.1.49
The following advisory is available for the OpenShift Compliance Operator 0.1.49:
* link:https://access.redhat.com/errata/RHBA-2022:1148[RHBA-2022:1148 - OpenShift Compliance Operator bug fix and enhancement update]
[id="compliance-operator-0-1-49-new-features-and-enhancements"]
=== New features and enhancements
* The Compliance Operator is now supported on the following architectures:
+
** {ibm-power-name}
** {ibm-z-name}
** {ibm-linuxone-name}
[id="compliance-operator-0-1-49-bug-fixes"]
=== Bug fixes
* 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, `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*])
* Previously, remediations using the `sshd jinja` macros were hard-coded to specific sshd configurations. As a result, the configurations were inconsistent with the content the rules were checking for and the check would fail. Now, the sshd configuration is parameterized and the rules apply successfully. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2049141[*BZ#2049141*])
* Previously, the `ocp4-cluster-version-operator-verify-integrity` always checked the first entry in the Cluter Version Operator (CVO) history. As a result, the upgrade would fail in situations where subsequent versions of {product-title} would be verified. Now, the compliance check result for `ocp4-cluster-version-operator-verify-integrity` is able to detect verified versions and is accurate with the CVO history. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2053602[*BZ#2053602*])
* Previously, the `ocp4-api-server-no-adm-ctrl-plugins-disabled` rule did not check for a list of empty admission controller plugins. As a result, the rule would always fail, even if all admission plugins were enabled. Now, more robust checking of the `ocp4-api-server-no-adm-ctrl-plugins-disabled` rule accurately passes with all admission controller plugins enabled. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2058631[*BZ#2058631*])
* Previously, scans did not contain platform checks for running against Linux worker nodes. As a result, running scans against worker nodes that were not Linux-based resulted in a never ending scan loop. Now, the scan schedules appropriately based on platform type and labels complete successfully. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2056911[*BZ#2056911*])
[id="compliance-operator-release-notes-0-1-48"]
== OpenShift Compliance Operator 0.1.48
The following advisory is available for the OpenShift Compliance Operator 0.1.48:
* link:https://access.redhat.com/errata/RHBA-2022:0416[RHBA-2022:0416 - OpenShift Compliance Operator bug fix and enhancement update]
[id="openshift-compliance-operator-0-1-48-bug-fixes"]
=== Bug fixes
* 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*])
[id="compliance-operator-release-notes-0-1-47"]
== OpenShift Compliance Operator 0.1.47
The following advisory is available for the OpenShift Compliance Operator 0.1.47:
* link:https://access.redhat.com/errata/RHBA-2022:0014[RHBA-2022:0014 - OpenShift Compliance Operator bug fix and enhancement update]
[id="compliance-operator-0-1-47-new-features-and-enhancements"]
=== New features and enhancements
* The Compliance Operator now supports the following compliance benchmarks for the Payment Card Industry Data Security Standard (PCI DSS):
+
** ocp4-pci-dss
** ocp4-pci-dss-node
* Additional rules and remediations for FedRAMP moderate impact level are added to the OCP4-moderate, OCP4-moderate-node, and rhcos4-moderate profiles.
* Remediations for KubeletConfig are now available in node-level profiles.
[id="openshift-compliance-operator-0-1-47-bug-fixes"]
=== Bug fixes
* Previously, if your cluster was running {product-title} 4.6 or earlier, remediations for USBGuard-related rules would fail for the moderate profile. This is because the remediations created by the Compliance Operator were based on an older version of USBGuard that did not support drop-in directories. Now, invalid remediations for USBGuard-related rules are not created for clusters running {product-title} 4.6. If your cluster is using {product-title} 4.6, you must manually create remediations for USBGuard-related rules.
+
Additionally, remediations are created only for rules that satisfy minimum version requirements. (link:https://bugzilla.redhat.com/show_bug.cgi?id=1965511[*BZ#1965511*])
* Previously, when rendering remediations, the compliance operator would check that the remediation was well-formed by using a regular expression that was too strict. As a result, some remediations, such as those that render `sshd_config`, would not pass the regular expression check and therefore, were not created. The regular expression was found to be unnecessary and removed. Remediations now render correctly. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2033009[*BZ#2033009*])
[id="compliance-operator-release-notes-0-1-44"]
== OpenShift Compliance Operator 0.1.44
The following advisory is available for the OpenShift Compliance Operator 0.1.44:
* link:https://access.redhat.com/errata/RHBA-2021:4530[RHBA-2021:4530 - OpenShift Compliance Operator bug fix and enhancement update]
[id="compliance-operator-0-1-44-new-features-and-enhancements"]
=== New features and enhancements
* In this release, the `strictNodeScan` option is now added to the `ComplianceScan`, `ComplianceSuite` and `ScanSetting` CRs. This option defaults to `true` which matches the previous behavior, where an error occurred if a scan was not able to be scheduled on a node. Setting the option to `false` allows the Compliance Operator to be more permissive about scheduling scans. Environments with ephemeral nodes can set the `strictNodeScan` value to false, which allows a compliance scan to proceed, even if some of the nodes in the cluster are not available for scheduling.
+
* You can now customize the node that is used to schedule the result server workload by configuring the `nodeSelector` and `tolerations` attributes of the `ScanSetting` object. These attributes are used to place the `ResultServer` pod, the pod that is used to mount a PV storage volume and store the raw Asset Reporting Format (ARF) results. Previously, the `nodeSelector` and the `tolerations` parameters defaulted to selecting one of the control plane nodes and tolerating the `node-role.kubernetes.io/master taint`. This did not work in environments where control plane nodes are not permitted to mount PVs. This feature provides a way for you to select the node and tolerate a different taint in those environments.
+
* 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 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 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.
+
* In this release, the Compliance Operator supports the following North American Electric Reliability Corporation (NERC) security profiles:
+
** ocp4-nerc-cip
** ocp4-nerc-cip-node
** rhcos4-nerc-cip
+
* In this release, the Compliance Operator supports the NIST 800-53 Moderate-Impact Baseline for the Red Hat OpenShift - Node level, ocp4-moderate-node, security profile.
[id="openshift-compliance-operator-0-1-44-templating"]
=== Templating and variable use
* In this release, the remediation template now allows multi-value variables.
+
* With this update, the Compliance Operator can change remediations based on variables that are set in the compliance profile. This is useful for remediations that include deployment-specific values such as time outs, NTP server host names, or similar. Additionally, the `ComplianceCheckResult` objects now use the label `compliance.openshift.io/check-has-value` that lists the variables a check has used.
[id="openshift-compliance-operator-0-1-44-bug-fixes"]
=== Bug fixes
* Previously, while performing a scan, an unexpected termination occurred in one of the scanner containers of the pods. In this release, the Compliance Operator uses the latest OpenSCAP version 1.3.5 to avoid a crash.
+
* Previously, using `autoReplyRemediations` to apply remediations triggered an update of the cluster nodes. This was disruptive if some of the remediations did not include all of the required input variables. Now, if a remediation is missing one or more required input variables, it is assigned a state of `NeedsReview`. If one or more remediations are in a `NeedsReview` state, the machine config pool remains paused, and the remediations are not applied until all of the required variables are set. This helps minimize disruption to the nodes.
+
* The RBAC Role and Role Binding used for Prometheus metrics are changed to 'ClusterRole' and 'ClusterRoleBinding' to ensure that monitoring works without customization.
+
* Previously, if an error occurred while parsing a profile, rules or variables objects were removed and deleted from the profile. Now, if an error occurs during parsing, the `profileparser` annotates the object with a temporary annotation that prevents the object from being deleted until after parsing completes. (link:https://bugzilla.redhat.com/show_bug.cgi?id=1988259[*BZ#1988259*])
+
* Previously, an error occurred if titles or descriptions were missing from a tailored profile. Because the XCCDF standard requires titles and descriptions for tailored profiles, titles and descriptions are now required to be set in `TailoredProfile` CRs.
+
* Previously, when using tailored profiles, `TailoredProfile` variable values were allowed to be set using only a specific selection set. This restriction is now removed, and `TailoredProfile` variables can be set to any value.
[id="compliance-operator-release-notes-0-1-39"]
== Release Notes for Compliance Operator 0.1.39
The following advisory is available for the OpenShift Compliance Operator 0.1.39:
* link:https://access.redhat.com/errata/RHBA-2021:3214[RHBA-2021:3214 - OpenShift Compliance Operator bug fix and enhancement update]
[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 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.
[id="compliance-operator-release-notes_additional-resources"]
[role="_additional-resources"]
== Additional resources
* xref:../../security/compliance_operator/co-concepts/compliance-operator-understanding.adoc#understanding-compliance-operator[Understanding the Compliance Operator]
View Git Blame Copy Permalink