合规性操作员发行说明

Compliance Operator 现在包含对支付卡行业数据安全标准 (PCI-DSS) 版本 4 的支持配置文件。有关更多信息，请参阅 支持的合规性配置文件。

Compliance Operator 现在包含对国防信息系统机构安全技术实施指南 (DISA STIG) V2R1 的支持配置文件。有关更多信息，请参阅 支持的合规性配置文件。

现在可用于安装在 x86、ppc64le 和 s390x 架构上的 Compliance Operator 的 `must-gather` 扩展。`must-gather` 工具为 Red Hat 客户支持和工程团队提供了重要的配置详细信息。有关更多信息，请参阅 使用 Compliance Operator 的 must-gather 工具。

在此版本之前，`ocp4-route-ip-whitelist` 规则中的描述误导性，导致误解，可能导致错误配置。通过此更新，该规则现在定义得更清晰。（CMP-2485）

以前，对于 `DONE` 状态的 `ComplianceScan`，所有 `ComplianceCheckResults` 的报告不完整。通过此更新，已添加注释以报告 `DONE` 状态的 `ComplianceScan` 的总 `ComplianceCheckResults` 数量。（CMP-2615）

以前，`ocp4-cis-scc-limit-container-allowed-capabilities` 规则描述包含模棱两可的指南，导致用户混淆。通过此更新，规则描述和可操作步骤已明确。（OCPBUGS-17828）

在此更新之前，sysctl 配置导致 RHCOS4 规则的某些自动补救措施在受影响的集群中扫描失败。通过此更新，应用正确的 sysctl 设置，并且 FedRAMP High 配置文件的 RHCOS4 规则可以正确通过扫描。（OCPBUGS-19690）

在此更新之前，`jq` 过滤器的某个问题导致合规性检查期间 `rhacs-operator-controller-manager` 部署出现错误。通过此更新，`jq` 过滤器表达式已更新，并且 `rhacs-operator-controller-manager` 部署免于与容器资源限制相关的合规性检查，从而消除了误报结果。（OCPBUGS-19690）

在此更新之前，`rhcos4-high` 和 `rhcos4-moderate` 配置文件检查了标题错误的配置文件的值。结果，一些扫描检查可能会失败。通过此更新，`rhcos4` 配置文件现在检查正确的配置文件，并且扫描可以正确通过。（OCPBUGS-31674）

以前，`oauthclient-inactivity-timeout` 规则中使用的 `accessokenInactivityTimeoutSeconds` 变量是不可变的，在执行 DISA STIG 扫描时导致 `FAIL` 状态。通过此更新，`accessTokenInactivityTimeoutSeconds` 变量的正确执行可以正常运行，现在可以获得 `PASS` 状态。（OCPBUGS-32551）

在此更新之前，一些规则的注释未更新，显示不正确的控制标准。通过此更新，规则的注释已正确更新，确保显示正确的控制标准。（OCPBUGS-34982）

以前，在升级到 Compliance Operator 1.5.1 时，`ServiceMonitor` 配置中错误引用的密钥导致与 Prometheus Operator 集成出现问题。通过此更新，Compliance Operator 将准确引用包含 `ServiceMonitor` 指标令牌的密钥。（OCPBUGS-39417）

通过此更新，Compliance Operator 提供唯一的配置文件 ID，以便于编程使用。（CMP-2450）

本版本中，合规性操作符现在已在 ROSA HCP 环境中经过测试并受支持。在 ROSA HCP 上运行时，合规性操作符仅加载节点配置文件。这是因为 Red Hat 管理的平台限制了对控制平面的访问，这使得平台配置文件与操作符的功能无关。（CMP-2581)

合规性操作符 1.5.0 版本已解决 CVE-2024-2961 漏洞。（CVE-2024-2961)

以前，对于 ROSA HCP 系统，配置文件列表不正确。此更新允许合规性操作符提供正确的配置文件输出。（OCPBUGS-34535)

在本版本中，可以通过在定制配置文件中设置 `ocp4-var-network-policies-namespaces-exempt-regex` 变量，将命名空间从 `ocp4-configure-network-policies-namespaces` 检查中排除。（CMP-2543)

从本版本开始，合规性操作符现在提供 CIS OpenShift 1.5.0 配置文件规则。（CMP-2447)

此更新中，合规性操作符现在提供配置文件规则中的 `OCP4 STIG ID` 和 `SRG`。（CMP-2401)

此更新中，已删除应用于 `s390x` 的过时规则。（CMP-2471)

以前，对于使用 Red Hat Enterprise Linux (RHEL) 9 的 Red Hat Enterprise Linux CoreOS (RHCOS) 系统，`ocp4-kubelet-enable-protect-kernel-sysctl-file-exist` 规则的应用会失败。此更新将该规则替换为 `ocp4-kubelet-enable-protect-kernel-sysctl`。现在，应用自动修复后，基于 RHEL 9 的 RHCOS 系统将显示 `PASS`。（OCPBUGS-13589)

以前，使用配置文件 `rhcos4-e8` 应用合规性修复后，将无法使用 SSH 访问节点的核心用户帐户。此更新后，可以使用 `sshkey1` 选项通过 SSH 访问节点。（OCPBUGS-18331)

以前，`STIG` 配置文件缺少来自 CaC 的规则，这些规则满足 OpenShift Container Platform 已发布的 `STIG` 的要求。此更新后，修复后，集群将满足可以使用合规性操作符修复的 `STIG` 要求。（OCPBUGS-26193)

以前，使用不同类型的多个产品的配置文件创建 `ScanSettingBinding` 对象会绕过对绑定中多个产品类型的限制。此更新后，产品验证现在允许多个产品，无论 `ScanSettingBinding` 对象中的配置文件类型如何。（OCPBUGS-26229)

以前，即使应用了自动修复，运行 `rhcos4-service-debug-shell-disabled` 规则也会显示为 `FAIL`。此更新后，应用自动修复后，运行 `rhcos4-service-debug-shell-disabled` 规则现在显示 `PASS`。（OCPBUGS-28242)

此更新中，增强了 `rhcos4-banner-etc-issue` 规则的使用说明，以提供更多详细信息。（OCPBUGS-28797)

以前，`api_server_api_priority_flowschema_catch_all` 规则在 OpenShift Container Platform 4.16 集群上提供 `FAIL` 状态。此更新后，`api_server_api_priority_flowschema_catch_all` 规则在 OpenShift Container Platform 4.16 集群上提供 `PASS` 状态。（OCPBUGS-28918)

以前，从 `ScanSettingBinding` (SSB) 对象中显示的已完成扫描中删除配置文件后，合规性操作符不会删除旧扫描。之后，当使用已删除的配置文件启动新的 SSB 时，合规性操作符无法更新结果。在本版本的合规性操作符中，新的 SSB 现在显示新的合规性检查结果。（OCPBUGS-29272)

以前，在 `ppc64le` 架构上，未创建指标服务。此更新后，在 `ppc64le` 架构上部署合规性操作符 v1.4.1 时，现在将正确创建指标服务。（OCPBUGS-32797)

以前，在 HyperShift 托管集群上，使用 `ocp4-pci-dss` 配置文件的扫描会因 `filter cannot iterate` 问题而遇到不可恢复的错误。在本版本中，`ocp4-pci-dss` 配置文件的扫描将达到 `done` 状态，并返回 `Compliance` 或 `Non-Compliance` 测试结果。（OCPBUGS-33067)

此更新后，使用默认 `worker` 和 `master` 节点池之外的自定义节点池的集群不再需要提供其他变量来确保合规性操作符聚合该节点池的配置文件。

用户现在可以通过将 `ScanSetting.suspend` 属性设置为 `True` 来暂停扫描计划。这允许用户暂停扫描计划并在无需删除和重新创建 `ScanSettingBinding` 的情况下重新激活它。这简化了在维护期间暂停扫描计划的过程。（CMP-2123)

合规性操作符现在支持 `Profile` 自定义资源上的可选 `version` 属性。（CMP-2125)

合规性操作符现在支持 `ComplianceRules` 中的配置文件名称。（CMP-2126)

此版本中提供了合规性操作符与改进的 `cronjob` API 改进的兼容性。（CMP-2310)

以前，在具有 Windows 节点的集群上，一些规则在应用自动修复后将失败，因为合规性扫描未跳过 Windows 节点。在本版本中，扫描时会正确跳过 Windows 节点。（OCPBUGS-7355)

此更新正确处理了依赖于多路径的 Pod 的根卷挂载的rprivate默认挂载传播。(OCPBUGS-17494)

此前，合规性操作符会在应用修复的同时，生成coreos_vsyscall_kernel_argument的修复建议，但不会协调规则。在1.4.0版本中，coreos_vsyscall_kernel_argument规则会正确评估内核参数并生成相应的修复建议。(OCPBUGS-8041)

在此更新之前，即使应用了自动修复，规则rhcos4-audit-rules-login-events-faillock也会失败。此更新后，rhcos4-audit-rules-login-events-faillock失败锁定现在会在自动修复后正确应用。(OCPBUGS-24594)

在此更新之前，从合规性操作符1.3.1升级到合规性操作符1.4.0会导致OVS规则扫描结果从PASS变为NOT-APPLICABLE。此更新后，OVS规则扫描结果现在显示PASS(OCPBUGS-25323)

您可以在FIPS模式下运行的OpenShift Container Platform集群中安装和使用合规性操作符。

在具有Windows节点的集群上，应用自动修复后，某些规则将失败，因为合规性扫描不会跳过Windows节点。这与预期结果不同，因为扫描时必须跳过Windows节点。(OCPBUGS-7355)

OpenShift Container Platform的国防信息系统机构安全技术实施指南(DISA-STIG)现已从合规性操作符1.3.0提供。有关更多信息，请参阅支持的合规性配置文件。

合规性操作符1.3.0现在支持IBM Power®和IBM Z®的NIST 800-53中等影响基线，适用于OpenShift Container Platform平台和节点配置文件。

CIS OpenShift Container Platform 4基准测试v1.4.0配置文件现已适用于平台和节点应用程序。要查找CIS OpenShift Container Platform v4基准测试，请访问CIS基准测试并点击“下载最新CIS基准测试”，然后您可以注册下载基准测试。

现在为scc-limit-container-allowed-capabilities规则提供了审核安全上下文约束(SCC)的更多说明。

ComplianceScan自定义资源定义(CRD)状态中现在提供开始和结束时间戳。

合规性操作符现在可以通过创建Subscription文件在使用OperatorHub的托管控制平面中部署。有关更多信息，请参阅在托管控制平面上安装合规性操作符。

在此更新之前，一些合规性操作符规则说明不存在。此更新后，以下规则的说明已改进：

在此更新之前，检查准确性和规则说明不清楚。此更新后，以下sysctl规则的检查准确性和说明已改进：

在此更新之前，ocp4-alert-receiver-configured规则不包含说明。此更新后，ocp4-alert-receiver-configured规则现在包含改进的说明。(OCPBUGS-7307)

在此更新之前，rhcos4-sshd-set-loglevel-info规则对于rhcos4-e8配置文件会失败。此更新后，sshd-set-loglevel-info规则的修复建议已更新为应用正确的配置更改，允许在应用修复建议后后续扫描通过。(OCPBUGS-7816)

在此更新之前，使用最新的合规性操作符安装的OpenShift Container Platform的新安装在scheduler-no-bind-address规则上失败。此更新后，由于该参数已删除，因此在较新版本的OpenShift Container Platform上已禁用scheduler-no-bind-address规则。(OCPBUGS-8347)

合规性操作符现已稳定，发布渠道已升级为stable。未来的版本将遵循语义化版本控制。要访问最新版本，请参见更新合规性操作符。

在此更新之前，compliance_operator_compliance_scan_error_total 指标的 ERROR 标签对于每个错误消息的值都不同。在此更新之后，compliance_operator_compliance_scan_error_total 指标的值不会增加。（OCPBUGS-1803）

在此更新之前，ocp4-api-server-audit-log-maxsize规则会导致FAIL状态。在此更新之后，错误消息已从指标中移除，从而减少了指标的基数，符合最佳实践。（OCPBUGS-7520）

在此更新之前，rhcos4-enable-fips-mode规则的描述误导性地说明了安装后可以启用FIPS。在此更新之后，rhcos4-enable-fips-mode规则的描述已澄清，FIPS必须在安装时启用。（OCPBUGS-8358）

合规性操作符现在支持扫描程序 Pod 的超时配置。超时时间在ScanSetting对象中指定。如果扫描在超时时间内未完成，则扫描将重试，直到达到最大重试次数。有关更多信息，请参见配置ScanSetting超时。

在此更新之前，合规性操作符的补救措施需要变量作为输入。未设置变量的补救措施会应用于整个集群，并导致节点卡住，即使补救措施看起来已正确应用。在此更新之后，合规性操作符会使用TailoredProfile验证补救措施是否需要提供变量。（OCPBUGS-3864）

在此更新之前，ocp4-kubelet-configure-tls-cipher-suites 的说明不完整，要求用户手动细化查询。在此更新之后，ocp4-kubelet-configure-tls-cipher-suites中提供的查询会返回执行审核步骤的实际结果。（OCPBUGS-3017）

在此更新之前，系统保留参数未在 kubelet 配置文件中生成，导致合规性操作符无法取消暂停机器配置池。在此更新之后，合规性操作符在机器配置池评估期间会忽略系统保留参数。（OCPBUGS-4445）

在此更新之前，ComplianceCheckResult 对象没有正确的描述。在此更新之后，合规性操作符从规则描述中获取ComplianceCheckResult信息。（OCPBUGS-4615）

在此更新之前，合规性操作符在解析机器配置时未检查 kubelet 配置文件是否为空。结果，合规性操作符会发生恐慌并崩溃。在此更新之后，合规性操作符改进了对 kubelet 配置数据结构的检查，并且只有在完全呈现后才会继续。（OCPBUGS-4621）

在此更新之前，合规性操作符根据机器配置池名称和宽限期为 kubelet 驱逐生成补救措施，导致单个驱逐规则有多个补救措施。在此更新之后，合规性操作符会应用单个规则的所有补救措施。（OCPBUGS-4338）

在此更新之前，尝试创建使用带有非默认MachineConfigPool的TailoredProfile的ScanSettingBinding时出现回归，这会将ScanSettingBinding标记为Failed。在此更新之后，功能已恢复，使用TailoredProfile的自定义ScanSettingBinding可以正确执行。（OCPBUGS-6827）

在此更新之前，一些 kubelet 配置参数没有默认值。在此更新之后，以下参数包含默认值（OCPBUGS-6708）

在此更新之前，由于 kubelet 运行所需的权限，selinux_confinement_of_daemons 规则在 kubelet 上运行失败。在此更新之后，selinux_confinement_of_daemons规则已禁用。（OCPBUGS-6968）

合规性操作符现在支持在ppc64le架构上使用支付卡行业数据安全标准 (PCI-DSS) ocp4-pci-dss 和 ocp4-pci-dss-node 配置文件。

之前，合规性操作符不支持在ppc64le等不同架构上使用支付卡行业数据安全标准 (PCI DSS) ocp4-pci-dss 和 ocp4-pci-dss-node 配置文件。现在，合规性操作符支持在ppc64le架构上使用ocp4-pci-dss和ocp4-pci-dss-node配置文件。（OCPBUGS-3252）

之前，在最近更新到 0.1.57 版本后，rerunner 服务帐户 (SA) 不再由集群服务版本 (CSV) 拥有，这会导致在操作符升级期间删除 SA。现在，CSV 在 0.1.59 中拥有rerunner SA，并且从任何以前的版本升级都不会导致 SA 丢失。（OCPBUGS-3452）

KubeletConfig 检查已从Node类型更改为Platform类型。KubeletConfig检查KubeletConfig的默认配置。配置文件从所有节点聚合到每个节点池中的单个位置。请参见针对默认配置值评估KubeletConfig规则。

ScanSetting自定义资源现在允许用户通过scanLimits属性覆盖扫描程序pod的默认CPU和内存限制。有关更多信息，请参见增加合规性操作符资源限制。

现在可以通过ScanSetting设置PriorityClass对象。这确保了合规性操作符的优先级，并最大限度地减少了集群偏离合规性的可能性。有关更多信息，请参见为ScanSetting扫描设置PriorityClass。

之前，合规性操作符将通知硬编码到默认的openshift-compliance命名空间。如果操作符安装在非默认命名空间中，则通知将无法按预期工作。现在，通知可在非默认的openshift-compliance命名空间中工作。（BZ#2060726）

之前，合规性操作符无法评估kubelet对象使用的默认配置，导致结果不准确和出现误报。此新功能评估kubelet配置，现在可以准确地进行报告。（BZ#2075041）

之前，应用自动修复后，合规性操作符会将ocp4-kubelet-configure-event-creation规则报告为FAIL状态，因为eventRecordQPS值设置为高于默认值。现在，ocp4-kubelet-configure-event-creation规则修复程序设置默认值，并且规则可以正确应用。（BZ#2082416）

ocp4-configure-network-policies规则需要手动干预才能有效执行。新的描述性说明和规则更新提高了使用Calico CNI的集群中ocp4-configure-network-policies规则的适用性。（BZ#2091794）

之前，在扫描设置中使用debug=true选项时，合规性操作符不会清理用于扫描基础设施的pod。这导致即使删除了ScanSettingBinding，pod仍然留在集群中。现在，删除ScanSettingBinding时始终会删除pod。（BZ#2092913）

之前，合规性操作符使用的是旧版本的operator-sdk命令，该命令会导致有关已弃用功能的警报。现在，已包含更新版本的operator-sdk命令，并且不再出现有关已弃用功能的警报。（BZ#2098581）

之前，如果合规性操作符无法确定kubelet和机器配置之间的关系，则将无法应用修复程序。现在，合规性操作符改进了对机器配置的处理，并且能够确定kubelet配置是否是机器配置的子集。（BZ#2102511）

之前，ocp4-cis-node-master-kubelet-enable-cert-rotation的规则没有正确描述成功标准。因此，RotateKubeletClientCertificate的要求不清楚。现在，无论kubelet配置文件中是否存在配置，ocp4-cis-node-master-kubelet-enable-cert-rotation规则都会准确地进行报告。（BZ#2105153）

之前，检查空闲流超时时间的规则没有考虑默认值，导致规则报告不准确。现在，更强大的检查确保了基于默认配置值的更高结果准确性。（BZ#2105878）

之前，在解析没有Ignition规范的机器配置时，合规性操作符将无法获取API资源，这会导致api-check-pods进程出现崩溃循环。现在，合规性操作符可以正确处理没有Ignition规范的机器配置池。（BZ#2117268）

之前，即使应用了修复程序，评估modprobe配置的规则也会失败，因为modprobe配置的值不匹配。现在，检查和修复程序中使用相同的值进行modprobe配置，从而确保结果一致。（BZ#2117747）

指定**安装到集群中的所有命名空间**或将WATCH_NAMESPACES环境变量设置为""不再影响所有命名空间。在合规性操作符安装时未指定的命名空间中安装的任何API资源将不再运行。可能需要在选定的命名空间或默认的openshift-compliance命名空间中创建API资源。此更改提高了合规性操作符的内存使用率。

之前，ocp4-kubelet-enable-streaming-connections规则包含不正确的变量比较，导致出现误报扫描结果。现在，设置streamingConnectionIdleTimeout时，合规性操作符提供准确的扫描结果。（BZ#2069891）

之前，在IBM Z®架构上，/etc/openvswitch/conf.db的组所有权不正确，导致ocp4-cis-node-worker-file-groupowner-ovs-conf-db检查失败。现在，在IBM Z®架构系统上，该检查标记为NOT-APPLICABLE。（BZ#2072597）

之前，由于部署中的安全上下文约束（SCC）规则数据不完整，ocp4-cis-scc-limit-container-allowed-capabilities规则报告为FAIL状态。现在，结果为MANUAL，这与需要人工干预的其他检查一致。（BZ#2077916）

之前，以下规则未能考虑API服务器和TLS证书和密钥的其他配置路径，即使证书和密钥设置正确，也会导致报告失败

之前，content_rule_oauth_or_oauthclient_inactivity_timeout规则在评估超时的合规性时，没有考虑部署设置的可配置超时。这导致即使超时有效，规则也会失败。现在，合规性操作符使用var_oauth_inactivity_timeout变量来设置有效的超时长度。（BZ#2081952）

之前，合规性操作符在未正确标记为特权使用的命名空间上使用管理权限，导致出现有关pod安全级别违规的警告消息。现在，合规性操作符具有适当的命名空间标签和权限调整，可以访问结果而不会违反权限。（BZ#2088202）

之前，应用rhcos4-high-master-sysctl-kernel-yama-ptrace-scope和rhcos4-sysctl-kernel-core-pattern的自动修复程序会导致这些规则在扫描结果中随后失败，即使它们已得到修复。现在，即使应用了修复程序，这些规则也会准确地报告PASS。（BZ#2094382）

之前，由于内存不足异常，合规性操作符会处于CrashLoopBackoff状态。现在，合规性操作符得到改进，可以处理内存中大型机器配置数据集并正常运行。（BZ#2094854）

当在ScanSettingBinding对象中设置"debug":true时，删除该绑定时不会删除ScanSettingBinding对象生成的pod。作为解决方法，请运行以下命令以删除剩余的pod

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

FedRAMP 高级 SCAP 配置文件现已可用于 OpenShift Container Platform 环境。更多信息，请参见 支持的合规性配置文件。

此前，由于在删除了 DAC_OVERRIDE 功能的安全环境中存在挂载权限问题，OpenScap 容器会崩溃。现在，可执行挂载权限已应用于所有用户。（BZ#2082151）

此前，合规性规则 ocp4-configure-network-policies 可以配置为 MANUAL。现在，合规性规则 ocp4-configure-network-policies 已设置为 AUTOMATIC。（BZ#2072431）

此前，集群自动伸缩器无法缩减规模，因为扫描结束后合规性操作符扫描 Pod 从未被删除。现在，默认情况下，这些 Pod 将从每个节点中删除，除非明确保存以用于调试目的。（BZ#2075029）

此前，将合规性操作符应用于 KubeletConfig 会导致节点进入 NotReady 状态，因为机器配置池过早地取消暂停。现在，机器配置池已适当地取消暂停，节点可以正常运行。（BZ#2071854）

此前，机器配置操作符在最新版本中使用的是 base64 而不是 url-encoded 编码，导致合规性操作符修复失败。现在，合规性操作符检查编码以处理 base64 和 url-encoded 机器配置代码，并且修复可以正确应用。（BZ#2082431）

当在ScanSettingBinding对象中设置"debug":true时，删除该绑定时不会删除ScanSettingBinding对象生成的pod。作为解决方法，请运行以下命令以删除剩余的pod

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

合规性操作符现在支持以下架构

此前，openshift-compliance 内容不包含针对网络类型的特定于平台的检查。因此，基于网络配置，OVN 和 SDN 特定的检查将显示为 failed 而不是 not-applicable。现在，新的规则包含对网络规则的平台检查，从而更准确地评估特定于网络的检查。（BZ#1994609）

此前，ocp4-moderate-routes-protected-by-tls 规则错误地检查了 TLS 设置，即使连接使用安全的 SSL/TLS 协议，也会导致规则检查失败。现在，该检查可以正确评估与网络指南和配置文件建议一致的 TLS 设置。（BZ#2002695）

此前，ocp-cis-configure-network-policies-namespace 在请求命名空间时使用分页。这导致规则失败，因为部署截断了超过 500 个命名空间的列表。现在，请求整个命名空间列表，并且检查已配置网络策略的规则适用于具有超过 500 个命名空间的部署。（BZ#2038909）

此前，使用 sshd jinja 宏的修复被硬编码到特定的 sshd 配置中。因此，这些配置与规则检查的内容不一致，检查将失败。现在，sshd 配置已参数化，并且规则可以成功应用。（BZ#2049141）

此前，ocp4-cluster-version-operator-verify-integrity 总是检查集群版本操作符 (CVO) 历史记录中的第一条条目。因此，当验证 OpenShift Container Platform 的后续版本时，升级将失败。现在，ocp4-cluster-version-operator-verify-integrity 的合规性检查结果能够检测已验证的版本，并且与 CVO 历史记录准确一致。（BZ#2053602）

此前，ocp4-api-server-no-adm-ctrl-plugins-disabled 规则没有检查空入站控制器插件的列表。因此，即使所有入站插件都已启用，规则也会始终失败。现在，对 ocp4-api-server-no-adm-ctrl-plugins-disabled 规则进行了更强大的检查，当所有入站控制器插件都启用时，可以准确地通过。（BZ#2058631）

此前，扫描不包含针对 Linux 工作节点运行的平台检查。因此，针对非基于 Linux 的工作节点运行扫描会导致无限循环的扫描。现在，扫描根据平台类型和标签适当地调度，并成功完成。（BZ#2056911）

此前，一些与扩展的开放漏洞和评估语言 (OVAL) 定义相关的规则的 checkType 为 None。这是因为合规性操作符在解析规则时没有处理扩展的 OVAL 定义。通过此更新，解析扩展 OVAL 定义中的内容，以便这些规则现在具有 Node 或 Platform 的 checkType。（BZ#2040282）

此前，为 KubeletConfig 手动创建的 MachineConfig 对象阻止为修复生成 KubeletConfig 对象，使修复处于 Pending 状态。在此版本中，无论是否存在为 KubeletConfig 手动创建的 MachineConfig 对象，修复都会创建 KubeletConfig 对象。因此，KubeletConfig 修复现在按预期工作。（BZ#2040401）

合规性操作符现在支持以下支付卡行业数据安全标准 (PCI DSS) 合规性基准

为 FedRAMP 中等影响级别添加了针对 OCP4-moderate、OCP4-moderate-node 和 rhcos4-moderate 配置文件的附加规则和修复。

KubeletConfig 的修复方案现已在节点级配置文件中可用。

以前，如果您的集群运行的是 OpenShift Container Platform 4.6 或更早版本，则针对与 USBGuard 相关的规则的修复方案会在中等配置文件中失败。这是因为合规性操作员创建的修复方案基于旧版本的 USBGuard，该版本不支持直接插入目录。现在，对于运行 OpenShift Container Platform 4.6 的集群，不会创建与 USBGuard 相关的规则的无效修复方案。如果您的集群使用的是 OpenShift Container Platform 4.6，则必须手动创建与 USBGuard 相关的规则的修复方案。

以前，在渲染修复方案时，合规性操作员会使用过于严格的正则表达式来检查修复方案是否格式正确。结果，某些修复方案（例如渲染sshd_config 的修复方案）无法通过正则表达式检查，因此未创建。后来发现该正则表达式是不必要的，因此已将其删除。修复方案现在可以正确渲染。（BZ#2033009）

在此版本中，strictNodeScan 选项现已添加到 ComplianceScan、ComplianceSuite 和 ScanSetting CR 中。此选项默认为 true，这与之前的行为一致，即如果无法在节点上调度扫描，则会发生错误。将该选项设置为 false 允许合规性操作员对调度扫描更加宽松。具有临时节点的环境可以将 strictNodeScan 值设置为 false，即使集群中某些节点不可用于调度，也可以允许进行合规性扫描。

您现在可以通过配置 ScanSetting 对象的 nodeSelector 和 tolerations 属性来自定义用于调度结果服务器工作负载的节点。这些属性用于放置 ResultServer pod，该 pod 用于挂载 PV 存储卷并存储原始资产报告格式 (ARF) 结果。以前，nodeSelector 和 tolerations 参数默认为选择一个控制平面节点并容忍 node-role.kubernetes.io/master taint。这在不允许控制平面节点挂载 PV 的环境中不起作用。此功能提供了一种方法，让您可以在这些环境中选择节点并容忍不同的污点。

合规性操作员现在可以修复 KubeletConfig 对象。

现在添加了一条包含错误消息的注释，以帮助内容开发者区分集群中不存在的对象与无法获取的对象。

规则对象现在包含两个新属性，checkType 和 description。这些属性允许您确定规则是否与节点检查或平台检查相关，并允许您查看规则的作用。

此增强功能消除了创建定制配置文件必须扩展现有配置文件的要求。这意味着 TailoredProfile CRD 中的 extends 字段不再是必需的。您现在可以选择一系列规则对象来创建定制配置文件。请注意，您必须通过设置 compliance.openshift.io/product-type: 注释或为 TailoredProfile CR 设置 -node 后缀来选择配置文件是应用于节点还是平台。

在此版本中，合规性操作员现在能够在所有节点上调度扫描，而不管其污点如何。以前，扫描 pod 仅容忍 node-role.kubernetes.io/master taint，这意味着它们要么在没有污点的节点上运行，要么仅在具有 node-role.kubernetes.io/master 污点的节点上运行。在使用自定义污点部署其节点的部署中，这会导致扫描未在这些节点上调度。现在，扫描 pod 容忍所有节点污点。

在此版本中，合规性操作员支持以下北美电力可靠性委员会 (NERC) 安全配置文件

在此版本中，合规性操作员支持针对 Red Hat OpenShift - 节点级别、ocp4-moderate-node 安全配置文件的 NIST 800-53 中等影响基线。

在此版本中，修复方案模板现在允许使用多值变量。

通过此更新，合规性操作员可以根据合规性配置文件中设置的变量更改修复方案。这对于包含特定于部署的值（例如超时、NTP 服务器主机名或类似值）的修复方案很有用。此外，ComplianceCheckResult 对象现在使用标签 compliance.openshift.io/check-has-value 列出检查已使用的变量。

以前，在执行扫描期间，pod 的一个扫描程序容器中发生了意外终止。在此版本中，合规性操作员使用最新的 OpenSCAP 版本 1.3.5 以避免崩溃。

以前，使用 autoReplyRemediations 应用修复方案会触发集群节点的更新。如果某些修复方案未包含所有必需的输入变量，则这会造成干扰。现在，如果修复方案缺少一个或多个必需的输入变量，则将其状态分配为 NeedsReview。如果一个或多个修复方案处于 NeedsReview 状态，则机器配置池将保持暂停状态，并且在设置所有必需的变量之前不会应用修复方案。这有助于最大程度地减少对节点的干扰。

用于 Prometheus 指标的 RBAC 角色和角色绑定已更改为“ClusterRole”和“ClusterRoleBinding”，以确保监控无需自定义即可正常工作。

以前，如果在解析配置文件时发生错误，则规则或变量对象将从配置文件中删除。现在，如果在解析过程中发生错误，profileparser 将使用临时注释对对象进行注释，以防止对象在解析完成之前被删除。（BZ#1988259）

以前，如果定制配置文件中缺少标题或说明，则会发生错误。由于 XCCDF 标准要求定制配置文件具有标题和说明，因此现在需要在 TailoredProfile CR 中设置标题和说明。

以前，在使用定制配置文件时，仅允许使用特定选择集设置 TailoredProfile 变量值。此限制现已删除，并且 TailoredProfile 变量可以设置为任何值。

以前，合规性操作员无法解析支付卡行业数据安全标准 (PCI DSS) 参考。现在，操作员可以解析使用 PCI DSS 配置文件提供的合规性内容。

以前，合规性操作员无法执行中等配置文件中 AU-5 控制的规则。现在，已向操作员添加权限，以便它可以读取Prometheusrules.monitoring.coreos.com 对象并运行涵盖中等配置文件中 AU-5 控制的规则。