Chapter 5. Compliance Operator

• The Compliance Operator now contains supported profiles for Payment Card Industry Data Security Standard (PCI-DSS) version 4. For more information, see 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 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 Using the must-gather tool for the Compliance Operator.

• 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. (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. (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. (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. (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. (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. (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. (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. (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. (OCPBUGS-39417)

• With this update, the Compliance Operator provides a unique profile ID for easier programmatic use. (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 Hat managed platform restricts access to the control plane, which makes Platform profiles irrelevant to the operator’s function.(CMP-2581)

• CVE-2024-2961 is resolved in the Compliance Operator 1.5.0 release. (CVE-2024-2961)
• Previously, for ROSA HCP systems, profile listings were incorrect. This update allows the Compliance Operator to provide correct profile output. (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. (CMP-2543)

• As of this release, the Compliance Operator now provides the CIS OpenShift 1.5.0 profile rules. (CMP-2447)
• With this update, the Compliance Operator now provides OCP4 STIG ID and SRG with the profile rules. (CMP-2401)
• With this update, obsolete rules being applied to s390x have been removed. (CMP-2471)

• Previously, for Red Hat Enterprise Linux CoreOS (RHCOS) systems using Red Hat Enterprise Linux (RHEL) 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, RHEL 9-based RHCOS systems will show PASS upon the application of this rule. (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. (OCPBUGS-18331)
• Previously, the STIG profile was missing rules from CaC that fulfill requirements on the published STIG for OpenShift Container Platform. With this update, upon remediation, the cluster satisfies STIG requirements that can be remediated using Compliance Operator. (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. (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. (OCPBUGS-28242)
• With this update, instructions for the use of the rhcos4-banner-etc-issue rule are enhanced to provide more detail. (OCPBUGS-28797)
• Previously the api_server_api_priority_flowschema_catch_all rule provided FAIL status on OpenShift Container Platform 4.16 clusters. With this update, the api_server_api_priority_flowschema_catch_all rule provides PASS status on OpenShift Container Platform 4.16 clusters. (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. (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. (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. (OCPBUGS-33067)

• 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. (CMP-2123)
• Compliance Operator now supports an optional version attribute on Profile custom resources. (CMP-2125)
• Compliance Operator now supports profile names in ComplianceRules. (CMP-2126)
• Compliance Operator compatibility with improved cronjob API improvements is available in this release. (CMP-2310)

• 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. (OCPBUGS-7355)
• With this update, rprivate default mount propagation is now handled correctly for root volume mounts of pods that rely on multipathing. (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.(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. (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 (OCPBUGS-25323)

• You can install and use the Compliance Operator in an OpenShift Container Platform cluster running in FIPS mode.

  Important

  To enable FIPS mode for your cluster, you must run the installation program from a Red Hat Enterprise Linux (RHEL) computer configured to operate in FIPS mode. For more information about configuring FIPS mode on RHEL, see Switching RHEL to FIPS mode.

  When running Red Hat Enterprise Linux (RHEL) or Red Hat Enterprise Linux CoreOS (RHCOS) booted in FIPS mode, OpenShift Container Platform core components use the RHEL cryptographic libraries that have been submitted to NIST for FIPS 140-2/140-3 Validation on only the x86_64, ppc64le, and s390x architectures.

• 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. (OCPBUGS-7355)

• The Defense Information Systems Agency Security Technical Implementation Guide (DISA-STIG) for OpenShift Container Platform is now available from Compliance Operator 1.3.0. See Supported compliance profiles for additional information.
• Compliance Operator 1.3.0 now supports IBM Power® and IBM Z® for NIST 800-53 Moderate-Impact Baseline for OpenShift Container Platform platform and node profiles.

• The CIS OpenShift Container Platform 4 Benchmark v1.4.0 profile is now available for platform and node applications. To locate the CIS OpenShift Container Platform v4 Benchmark, go to 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 OpenShift Container Platform 4 Benchmark 1.1.0 profiles.

  If your OpenShift Container Platform 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.

• A start and end timestamp is now available in the ComplianceScan custom resource definition (CRD) status.
• The Compliance Operator can now be deployed on hosted control planes using the OperatorHub by creating a Subscription file. For more information, see Installing the Compliance Operator on hosted control planes.

• 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

    (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

    (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. (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. (OCPBUGS-7816)
• Before this update, a new installation of OpenShift Container Platform 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 OpenShift Container Platform since the parameter was removed. (OCPBUGS-8347)

• The Compliance Operator is now stable and the release channel is upgraded to stable. Future releases will follow Semantic Versioning. To access the latest release, see Updating the Compliance Operator.

• 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. (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. (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. (OCPBUGS-8358)

• 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 Configuring ScanSetting timeout for more information.

• 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. (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. (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. (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. (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. (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. (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. (OCPBUGS-6827)

• Before this update, some kubelet configuration parameters did not have default values. With this update, the following parameters contain default values (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. (OCPBUGS-6968)

• 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.

• 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. (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. (OCPBUGS-3452)

• 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 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 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 Setting PriorityClass for ScanSetting scans.

• 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. (BZ#2060726)
• Previously, the Compliance Operator was unable to evaluate default configurations used by kubelet objects, resulting in inaccurate results and false positives. This new feature evaluates the kubelet configuration and now reports accurately. (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. (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. (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.(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. (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. (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. (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. (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. (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. (BZ#2117747)

• 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.

• 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. (BZ#2069891)
• Previously, group ownership for /etc/openvswitch/conf.db was incorrect on IBM Z® architectures, resulting in ocp4-cis-node-worker-file-groupowner-ovs-conf-db check failures. Now, the check is marked NOT-APPLICABLE on IBM Z® architecture systems. (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. (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. (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. (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. (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.(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. (BZ#2094854)

• 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:

  $ oc delete pods -l compliance.openshift.io/scan-name=ocp4-cis

  (BZ#2092913)

• The FedRAMP high SCAP profile is now available for use in OpenShift Container Platform environments. For more information, See Supported compliance profiles.

• 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. (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. (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. (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. (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. (BZ#2082431)

• 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:

  $ oc delete pods -l compliance.openshift.io/scan-name=ocp4-cis

  (BZ#2092913)

• The Compliance Operator is now supported on the following architectures:

  • IBM Power®
  • IBM Z®
  • IBM® LinuxONE

• 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. (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. (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. (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. (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 OpenShift Container Platform 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. (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. (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. (BZ#2056911)

• 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. (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. (BZ#2040401)

• 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.

• Previously, if your cluster was running OpenShift Container Platform 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 OpenShift Container Platform 4.6. If your cluster is using OpenShift Container Platform 4.6, you must manually create remediations for USBGuard-related rules.

  Additionally, remediations are created only for rules that satisfy minimum version requirements. (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. (BZ#2033009)

• 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.

• 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.

• 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. (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.

• 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.

• View the available profiles:

  $ oc get profile.compliance -n openshift-compliance

  Example output

  NAME                       AGE     VERSION
  ocp4-cis                   3h49m   1.5.0
  ocp4-cis-1-4               3h49m   1.4.0
  ocp4-cis-1-5               3h49m   1.5.0
  ocp4-cis-node              3h49m   1.5.0
  ocp4-cis-node-1-4          3h49m   1.4.0
  ocp4-cis-node-1-5          3h49m   1.5.0
  ocp4-e8                    3h49m
  ocp4-high                  3h49m   Revision 4
  ocp4-high-node             3h49m   Revision 4
  ocp4-high-node-rev-4       3h49m   Revision 4
  ocp4-high-rev-4            3h49m   Revision 4
  ocp4-moderate              3h49m   Revision 4
  ocp4-moderate-node         3h49m   Revision 4
  ocp4-moderate-node-rev-4   3h49m   Revision 4
  ocp4-moderate-rev-4        3h49m   Revision 4
  ocp4-nerc-cip              3h49m
  ocp4-nerc-cip-node         3h49m
  ocp4-pci-dss               3h49m   3.2.1
  ocp4-pci-dss-3-2           3h49m   3.2.1
  ocp4-pci-dss-4-0           3h49m   4.0.0
  ocp4-pci-dss-node          3h49m   3.2.1
  ocp4-pci-dss-node-3-2      3h49m   3.2.1
  ocp4-pci-dss-node-4-0      3h49m   4.0.0
  ocp4-stig                  3h49m   V2R1
  ocp4-stig-node             3h49m   V2R1
  ocp4-stig-node-v1r1        3h49m   V1R1
  ocp4-stig-node-v2r1        3h49m   V2R1
  ocp4-stig-v1r1             3h49m   V1R1
  ocp4-stig-v2r1             3h49m   V2R1
  rhcos4-e8                  3h49m
  rhcos4-high                3h49m   Revision 4
  rhcos4-high-rev-4          3h49m   Revision 4
  rhcos4-moderate            3h49m   Revision 4
  rhcos4-moderate-rev-4      3h49m   Revision 4
  rhcos4-nerc-cip            3h49m
  rhcos4-stig                3h49m   V2R1
  rhcos4-stig-v1r1           3h49m   V1R1
  rhcos4-stig-v2r1           3h49m   V2R1

  These profiles represent different compliance benchmarks. Each profile has the product name that it applies to added as a prefix to the profile’s name. ocp4-e8 applies the Essential 8 benchmark to the OpenShift Container Platform product, while rhcos4-e8 applies the Essential 8 benchmark to the Red Hat Enterprise Linux CoreOS (RHCOS) product.

• Run the following command to view the details of the rhcos4-e8 profile:

  $ oc get -n openshift-compliance -oyaml profiles.compliance rhcos4-e8

  Example 5.1. Example output

  apiVersion: compliance.openshift.io/v1alpha1
  description: 'This profile contains configuration checks for Red Hat Enterprise Linux
    CoreOS that align to the Australian Cyber Security Centre (ACSC) Essential Eight.
    A copy of the Essential Eight in Linux Environments guide can be found at the ACSC
    website: https://www.cyber.gov.au/acsc/view-all-content/publications/hardening-linux-workstations-and-servers'
  id: xccdf_org.ssgproject.content_profile_e8
  kind: Profile
  metadata:
    annotations:
      compliance.openshift.io/image-digest: pb-rhcos4hrdkm
      compliance.openshift.io/product: redhat_enterprise_linux_coreos_4
      compliance.openshift.io/product-type: Node
    creationTimestamp: "2022-10-19T12:06:49Z"
    generation: 1
    labels:
      compliance.openshift.io/profile-bundle: rhcos4
    name: rhcos4-e8
    namespace: openshift-compliance
    ownerReferences:
    - apiVersion: compliance.openshift.io/v1alpha1
      blockOwnerDeletion: true
      controller: true
      kind: ProfileBundle
      name: rhcos4
      uid: 22350850-af4a-4f5c-9a42-5e7b68b82d7d
    resourceVersion: "43699"
    uid: 86353f70-28f7-40b4-bf0e-6289ec33675b
  rules:
  - rhcos4-accounts-no-uid-except-zero
  - rhcos4-audit-rules-dac-modification-chmod
  - rhcos4-audit-rules-dac-modification-chown
  - rhcos4-audit-rules-execution-chcon
  - rhcos4-audit-rules-execution-restorecon
  - rhcos4-audit-rules-execution-semanage
  - rhcos4-audit-rules-execution-setfiles
  - rhcos4-audit-rules-execution-setsebool
  - rhcos4-audit-rules-execution-seunshare
  - rhcos4-audit-rules-kernel-module-loading-delete
  - rhcos4-audit-rules-kernel-module-loading-finit
  - rhcos4-audit-rules-kernel-module-loading-init
  - rhcos4-audit-rules-login-events
  - rhcos4-audit-rules-login-events-faillock
  - rhcos4-audit-rules-login-events-lastlog
  - rhcos4-audit-rules-login-events-tallylog
  - rhcos4-audit-rules-networkconfig-modification
  - rhcos4-audit-rules-sysadmin-actions
  - rhcos4-audit-rules-time-adjtimex
  - rhcos4-audit-rules-time-clock-settime
  - rhcos4-audit-rules-time-settimeofday
  - rhcos4-audit-rules-time-stime
  - rhcos4-audit-rules-time-watch-localtime
  - rhcos4-audit-rules-usergroup-modification
  - rhcos4-auditd-data-retention-flush
  - rhcos4-auditd-freq
  - rhcos4-auditd-local-events
  - rhcos4-auditd-log-format
  - rhcos4-auditd-name-format
  - rhcos4-auditd-write-logs
  - rhcos4-configure-crypto-policy
  - rhcos4-configure-ssh-crypto-policy
  - rhcos4-no-empty-passwords
  - rhcos4-selinux-policytype
  - rhcos4-selinux-state
  - rhcos4-service-auditd-enabled
  - rhcos4-sshd-disable-empty-passwords
  - rhcos4-sshd-disable-gssapi-auth
  - rhcos4-sshd-disable-rhosts
  - rhcos4-sshd-disable-root-login
  - rhcos4-sshd-disable-user-known-hosts
  - rhcos4-sshd-do-not-permit-user-env
  - rhcos4-sshd-enable-strictmodes
  - rhcos4-sshd-print-last-log
  - rhcos4-sshd-set-loglevel-info
  - rhcos4-sysctl-kernel-dmesg-restrict
  - rhcos4-sysctl-kernel-kptr-restrict
  - rhcos4-sysctl-kernel-randomize-va-space
  - rhcos4-sysctl-kernel-unprivileged-bpf-disabled
  - rhcos4-sysctl-kernel-yama-ptrace-scope
  - rhcos4-sysctl-net-core-bpf-jit-harden
  title: Australian Cyber Security Centre (ACSC) Essential Eight

• Run the following command to view the details of the rhcos4-audit-rules-login-events rule:

  $ oc get -n openshift-compliance -oyaml rules rhcos4-audit-rules-login-events

  Example 5.2. Example output

  apiVersion: compliance.openshift.io/v1alpha1
  checkType: Node
  description: |-
    The audit system already collects login information for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix.rules in the directory /etc/audit/rules.d in order to watch for attempted manual edits of files involved in storing logon events:
  
    -w /var/log/tallylog -p wa -k logins
    -w /var/run/faillock -p wa -k logins
    -w /var/log/lastlog -p wa -k logins
  
    If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file in order to watch for unattempted manual edits of files involved in storing logon events:
  
    -w /var/log/tallylog -p wa -k logins
    -w /var/run/faillock -p wa -k logins
    -w /var/log/lastlog -p wa -k logins
  id: xccdf_org.ssgproject.content_rule_audit_rules_login_events
  kind: Rule
  metadata:
    annotations:
      compliance.openshift.io/image-digest: pb-rhcos4hrdkm
      compliance.openshift.io/rule: audit-rules-login-events
      control.compliance.openshift.io/NIST-800-53: AU-2(d);AU-12(c);AC-6(9);CM-6(a)
      control.compliance.openshift.io/PCI-DSS: Req-10.2.3
      policies.open-cluster-management.io/controls: AU-2(d),AU-12(c),AC-6(9),CM-6(a),Req-10.2.3
      policies.open-cluster-management.io/standards: NIST-800-53,PCI-DSS
    creationTimestamp: "2022-10-19T12:07:08Z"
    generation: 1
    labels:
      compliance.openshift.io/profile-bundle: rhcos4
    name: rhcos4-audit-rules-login-events
    namespace: openshift-compliance
    ownerReferences:
    - apiVersion: compliance.openshift.io/v1alpha1
      blockOwnerDeletion: true
      controller: true
      kind: ProfileBundle
      name: rhcos4
      uid: 22350850-af4a-4f5c-9a42-5e7b68b82d7d
    resourceVersion: "44819"
    uid: 75872f1f-3c93-40ca-a69d-44e5438824a4
  rationale: Manual editing of these files may indicate nefarious activity, such as
    an attacker attempting to remove evidence of an intrusion.
  severity: medium
  title: Record Attempts to Alter Logon and Logout Events
  warning: Manual editing of these files may indicate nefarious activity, such as an
    attacker attempting to remove evidence of an intrusion.

Prerequisites

• You must have admin privileges.
• You must have a StorageClass resource configured.

Prerequisites

• You must have admin privileges.
• You must have a StorageClass resource configured.

Prerequisites

• You must have admin privileges.
• You must have a StorageClass resource configured.

Prerequisites

• You must have admin privileges.

• Red Hat OpenShift Container Platform Operator Update Information Checker

Prerequisites

• An Operator previously installed using Operator Lifecycle Manager (OLM).

Prerequisites

• An Operator previously installed using Operator Lifecycle Manager (OLM).

Prerequisites

• Access to an OpenShift Container Platform cluster using an account with cluster-admin permissions.
• The OpenShift Compliance Operator must be installed.

Prerequisites

• Access to an OpenShift Container Platform cluster using an account with cluster-admin permissions.
• The OpenShift Compliance Operator must be installed.

Procedure

• Create a ScanSetting custom resource (CR) for the Compliance Operator:

  1. Define the ScanSetting CR, and save the YAML file, for example, rs-workers.yaml:

     apiVersion: compliance.openshift.io/v1alpha1
     kind: ScanSetting
     metadata:
       name: rs-on-workers
       namespace: openshift-compliance
     rawResultStorage:
       nodeSelector:
         node-role.kubernetes.io/worker: "" 1
       pvAccessModes:
       - ReadWriteOnce
       rotation: 3
       size: 1Gi
       tolerations:
       - operator: Exists 2
     roles:
     - worker
     - master
     scanTolerations:
       - operator: Exists
     schedule: 0 1 * * *

     1

     The Compliance Operator uses this node to store scan results in ARF format.

     2

     The result server pod tolerates all taints.

  2. To create the ScanSetting CR, run the following command:

     $ oc create -f rs-workers.yaml

Verification

• To verify that the ScanSetting object is created, run the following command:

  $ oc get scansettings rs-on-workers -n openshift-compliance -o yaml

  Example output

  apiVersion: compliance.openshift.io/v1alpha1
  kind: ScanSetting
  metadata:
    creationTimestamp: "2021-11-19T19:36:36Z"
    generation: 1
    name: rs-on-workers
    namespace: openshift-compliance
    resourceVersion: "48305"
    uid: 43fdfc5f-15a7-445a-8bbc-0e4a160cd46e
  rawResultStorage:
    nodeSelector:
      node-role.kubernetes.io/worker: ""
    pvAccessModes:
    - ReadWriteOnce
    rotation: 3
    size: 1Gi
    tolerations:
    - operator: Exists
  roles:
  - worker
  - master
  scanTolerations:
  - operator: Exists
  schedule: 0 1 * * *
  strictNodeScan: true

Prerequisites

• The Compliance Operator is installed in the management cluster.

• Node scan: Scans the Operating System.
• Platform scan: Scans the OpenShift Container Platform configuration.

Procedure

• Set the following annotation on the TailoredProfile object:

Verification

• The Platform KubeletConfig rules are checked through the Node/Proxy object. You can find those rules by running the following command:

  $ oc get rules -o json | jq '.items[] | select(.checkType == "Platform") | select(.metadata.name | contains("ocp4-kubelet-")) | .metadata.name'

Procedure

• Add a label to the sub-pool MachineConfigPool CR:

  $ oc label mcp <sub-pool-name> pools.operator.machineconfiguration.openshift.io/<sub-pool-name>=

• It is not always possible to automatically determine the value that must be set. One of the checks requires that a list of allowed registries is provided, but the scanner has no way of knowing which registries the organization wants to allow.
• Different checks modify different API objects, requiring automated remediation to possess root or superuser access to modify objects in the cluster, which is not advised.

• Specifying only a single rule to scan. This can be useful for debugging together with the debug: true attribute which increases the OpenSCAP scanner verbosity, as the debug mode tends to get quite verbose otherwise. Limiting the test to one rule helps to lower the amount of debug information.
• Providing a custom nodeSelector. In order for a remediation to be applicable, the nodeSelector must match a pool.
• Pointing the Scan to a bespoke config map with a tailoring file.
• For testing or development when the overhead of parsing profiles from bundles is not required.

Procedure

• Set the PriorityClass variable:

  apiVersion: compliance.openshift.io/v1alpha1
  strictNodeScan: true
  metadata:
    name: default
    namespace: openshift-compliance
  priorityClass: compliance-high-priority 1
  kind: ScanSetting
  showNotApplicable: false
  rawResultStorage:
    nodeSelector:
      node-role.kubernetes.io/master: ''
    pvAccessModes:
      - ReadWriteOnce
    rotation: 3
    size: 1Gi
    tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/master
        operator: Exists
      - effect: NoExecute
        key: node.kubernetes.io/not-ready
        operator: Exists
        tolerationSeconds: 300
      - effect: NoExecute
        key: node.kubernetes.io/unreachable
        operator: Exists
        tolerationSeconds: 300
      - effect: NoSchedule
        key: node.kubernetes.io/memory-pressure
        operator: Exists
  schedule: 0 1 * * *
  roles:
    - master
    - worker
  scanTolerations:
    - operator: Exists

  1

  If the PriorityClass referenced in the ScanSetting cannot be found, the Operator will leave the PriorityClass empty, issue a warning, and continue scheduling scans without a PriorityClass.

Procedure

• Apply the compliance.openshift.io/apply-remediations annotation by running:

Procedure

• Apply the compliance.openshift.io/remove-outdated annotation:

Prerequisites

• You must have admin privileges.

Procedure

• Inject a request of 0.25 cpu and 64 Mi of memory, and a limit of 0.5 cpu and 128 Mi of memory in each container by editing the Subscription object:

  kind: Subscription
  metadata:
    name: compliance-operator
    namespace: openshift-compliance
  spec:
    package: package-name
    channel: stable
    config:
      resources:
        requests:
          memory: "64Mi"
          cpu: "250m"
        limits:
          memory: "128Mi"
          cpu: "500m"

Procedure

• To set a timeout and maxRetryOnTimeout in ScanSetting, modify an existing ScanSetting object:

  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. To disable the timeout, set the value to 0s.

  2

  The maxRetryOnTimeout variable defines how many times a retry is attempted. The default value is 3.

• Search or browse through the Red Hat Knowledgebase of articles and solutions relating to Red Hat products.
• Submit a support case to Red Hat Support.
• Access other product documentation.

Procedure

• Fetching the results from the PV with the Compliance Operator is a four-step process. However, with the oc-compliance plugin, you can use a single command:

  $ oc compliance fetch-raw <object-type> <object-name> -o <output-path>

• <object-type> can be either scansettingbinding, compliancescan or compliancesuite, depending on which of these objects the scans were launched with.

• <object-name> is the name of the binding, suite, or scan object to gather the ARF file for, and <output-path> is the local directory to place the results.

  For example:

  $ oc compliance fetch-raw scansettingbindings my-binding -o /tmp/

  Example output

  Fetching results for my-binding scans: ocp4-cis, ocp4-cis-node-worker, ocp4-cis-node-master
  Fetching raw compliance results for scan 'ocp4-cis'.......
  The raw compliance results are available in the following directory: /tmp/ocp4-cis
  Fetching raw compliance results for scan 'ocp4-cis-node-worker'...........
  The raw compliance results are available in the following directory: /tmp/ocp4-cis-node-worker
  Fetching raw compliance results for scan 'ocp4-cis-node-master'......
  The raw compliance results are available in the following directory: /tmp/ocp4-cis-node-master

Procedure

• Rerunning a scan with the Compliance Operator requires use of an annotation on the scan object. However, with the oc-compliance plugin you can rerun a scan with a single command. Enter the following command to rerun the scans for the ScanSettingBinding object named my-binding:

  $ oc compliance rerun-now scansettingbindings my-binding

  Example output

  Rerunning scans from 'my-binding': ocp4-cis
  Re-running scan 'openshift-compliance/ocp4-cis'

• A benchmark is the top-level definition of a set of controls for a particular standard. For example, FedRAMP Moderate or Center for Internet Security (CIS) v.1.6.0.
• A control describes a family of requirements that must be met in order to be in compliance with the benchmark. For example, FedRAMP AC-01 (access control policy and procedures).
• A rule is a single check that is specific for the system being brought into compliance, and one or more of these rules map to a control.
• The Compliance Operator handles the grouping of rules into a profile for a single benchmark. It can be difficult to determine which controls that the set of rules in a profile satisfy.

Procedure

• The oc compliance controls subcommand provides a report of the standards and controls that a given profile satisfies:

  $ oc compliance controls profile ocp4-cis-node

  Example output

  +-----------+----------+
  | FRAMEWORK | CONTROLS |
  +-----------+----------+
  | CIS-OCP   | 1.1.1    |
  +           +----------+
  |           | 1.1.10   |
  +           +----------+
  |           | 1.1.11   |
  +           +----------+
  ...

Procedure

• Run:

  $ oc compliance view-result ocp4-cis-scheduler-no-bind-address