The Compliance Operator lets OpenShift Container Platform 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 OpenShift Container Platform.
For an overview of the Compliance Operator, see Understanding the Compliance Operator.
Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. Because of the enormity of this endeavor, these changes will be implemented gradually over several upcoming releases. For more details, see Red Hat CTO Chris Wright’s message.
The following advisory is available for the OpenShift Compliance Operator 0.1.44:
In this release, the
strictNodeScan option is now added to the
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
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
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.
Rule objects now contain two new attributes,
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
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 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 can use.
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.
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. (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
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.
The following advisory is available for the OpenShift Compliance Operator 0.1.39:
Previously, the Compliance Operator was unable to parse Payment Card Industry Data Security Standard (PCI DSS) references. Now, the Operator can parse compliance content that ships with PCI DSS profiles.
Previously, the Compliance Operator was unable to 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.