第 5 章 Compliance Operator

5.1. Compliance Operator 发行注记

通过 Compliance Operator，OpenShift Container Platform 管理员可以描述集群所需的合规状态，并概述缺陷及修复方法。

本发行注记介绍了 OpenShift Container Platform 中 Compliance Operator 的开发。

有关 Compliance Operator 的概述，请参阅了解 Compliance Operator。

要访问最新版本，请参阅更新 Compliance Operator。

5.1.1. OpenShift Compliance Operator 1.0.0

以下公告可用于 OpenShift Compliance Operator 1.0.0：

5.1.1.1. 新功能及功能增强

5.1.1.2. 程序错误修复

  • 在此次更新之前，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)

5.1.2. OpenShift Compliance Operator 0.1.61

以下公告可用于 OpenShift Compliance Operator 0.1.61：

5.1.2.1. 新功能及功能增强

  • Compliance Operator 现在支持 Scanner Pod 的超时配置。超时在 ScanSetting 对象中指定。如果在超时时间内没有完成扫描，扫描会重试，直到达到最大重试次数为止。如需更多信息，请参阅配置 ScanSetting 超时。

5.1.2.2. 程序错误修复

  • 在此次更新之前，Compliance Operator 补救需要变量作为输入。没有变量集的补救会在集群范围内应用，并导致节点卡住，即使它正确应用了补救。在这个版本中，Compliance Operator 会验证是否需要使用 TailoredProfile 进行补救提供变量。(OCPBUGS-3864)
  • 在此次更新之前，ocp4-kubelet-configure-tls-cipher-suites 的说明不完整，需要用户手动优化查询。在这个版本中，ocp4-kubelet-configure-tls-cipher-suites 中提供的查询会返回实际结果来执行审计步骤。(OCPBUGS-3017)
  • 在此次更新之前，在没有 settingRef 变量的情况下创建的ScanSettingBinding 对象不使用适当的默认值。在这个版本中，没有 settingsRef 变量的 ScanSettingBinding 对象会使用默认值。(OCPBUGS-3420)
  • 在此次更新之前，kubelet 配置文件中不会生成系统保留参数，从而导致 Compliance Operator 无法取消暂停机器配置池。在这个版本中，Compliance Operator 在机器配置池评估过程中省略系统保留的参数。(OCPBUGS-4445)
  • 在此次更新之前，ComplianceCheckResult 对象没有正确描述。在这个版本中，Compliance Operator 从规则描述中找到 ComplianceCheckResult 信息。(OCPBUGS-4615)
  • 在此次更新之前，Compliance Operator 在解析机器配置时不会检查空的 kubelet 配置文件。因此，Compliance Operator 会 panic 和 crash。在这个版本中，Compliance Operator 实现 kubelet 配置数据结构的改进检查，只有在完全渲染时才继续。(OCPBUGS-4621)
  • 在此次更新之前，Compliance Operator 根据机器配置池名称和宽限期为 kubelet 驱除生成补救，从而导致单个驱除规则出现多个补救。在这个版本中，Compliance Operator 为一条规则应用所有补救。(OCPBUGS-4338)
  • 在此次更新之前，在执行重新扫描后，对之前 Applied 的补救重新运行扫描可能已被标记为 Outdated，尽管补救内容没有改变。扫描的比较没有正确地考虑修复元数据。在这个版本中，补救会保留之前生成的 Applied 状态。(OCPBUGS-6710)
  • 在此次更新之前，当试图创建一个 ScanSettingBinding 时，使用带有非默认 MachineConfigPool 的 TailoredProfile 将 ScanSettingBinding 标记为 Failed 时会出现一个回归。在这个版本中，功能会被恢复，使用 TailoredProfile 正确执行自定义 ScanSettingBinding。(OCPBUGS-6827)

  • 在此次更新之前，有些 kubelet 配置参数没有默认值。在这个版本中，以下参数包含默认值(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
  • 在此次更新之前，selinux_confinement_of_daemons 规则因为 kubelet 运行所需的权限而无法在 kubelet 上运行。在这个版本中，selinux_confinement_of_daemons 规则被禁用。(OCPBUGS-6968)

5.1.3. OpenShift Compliance Operator 0.1.59

以下公告可用于 OpenShift Compliance Operator 0.1.59：

5.1.3.1. 新功能及功能增强

  • Compliance Operator 现在支持 ppc64le 架构上的支付卡行业数据安全标准 (PCI-DSS) ocp4-pci-dss 和 ocp4-pci-dss-node 配置集。

5.1.3.2. 程序错误修复

  • 在以前的版本中，Compliance Operator 不支持在不同架构上（如 ppc64le）的 Payment Card industry Data Security Standard (PCI DSS) ocp4-pci-dss 和 ocp4-pci-dss-node 配置集。现在，Compliance Operator 在 ppc64le 架构上支持 ocp4-pci-dss 和 ocp4-pci-dss-node 配置集。(OCPBUGS-3252)
  • 在以前的版本中，在最近更新到 0.1.57 后，rerunner 服务帐户 (SA) 不再被集群服务版本 (CSV) 所有，这会导致在 Operator 升级过程中删除 SA。现在，CSV 拥有 0.1.59 中的 rerunner SA，从任何以前的版本升级都不会造成缺少的 SA。(OCPBUGS-3452)
  • 在 0.1.57 中，Operator 启动了侦听端口 8080 的控制器指标端点。这会导致 TargetDown 警报，因为集群监控的预期端口为 8383。使用 0.1.59 时，Operator 会如预期启动侦听端口 8383 的端点。(OCPBUGS-3097)

5.1.4. OpenShift Compliance Operator 0.1.57

以下公告可用于 OpenShift Compliance Operator 0.1.57：

5.1.4.1. 新功能及功能增强

  • KubeletConfig 检查从 Node 改为 Platform 类型。KubeletConfig 检查 KubeletConfig 的默认配置。配置文件从所有节点聚合到每个节点池的一个位置。请参阅针对默认配置值评估 KubeletConfig 规则。
  • ScanSetting 自定义资源现在允许用户通过 scanLimits 属性覆盖扫描程序 Pod 的默认 CPU 和内存限值。如需更多信息，请参阅增加 Compliance Operator 资源限制。
  • 现在，可以通过 ScanSetting 设置 PriorityClass 对象。这样可确保 Compliance Operator 被优先处理，并尽可能减少集群不合规的可能性。如需更多信息，请参阅为 ScanSetting 扫描设置 PriorityClass 。

5.1.4.2. 程序错误修复

  • 在以前的版本中，Compliance Operator 硬编码通知到默认的 openshift-compliance 命名空间。如果 Operator 安装在非默认命名空间中，通知将无法正常工作。现在，通知可以在非默认 openshift-compliance 命名空间中工作。(BZ#2060726)
  • 在以前的版本中，Compliance Operator 无法评估 kubelet 对象使用的默认配置，从而导致结果准确和假的正状态。这个新功能会评估 kubelet 配置，现在可以准确报告。(BZ#2075041)
  • 在以前的版本中，在应用自动补救后，Compliance Operator 会报告 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 选项时，Compliance Operator 不会清理用于扫描基础架构的 pod。这会导致 pod 在删除 ScanSettingBinding 后保留在集群中。现在，当一个 ScanSettingBinding 被删除时，pod 总是被删除。(BZ#2092913)
  • 在以前的版本中，Compliance Operator 使用了一个 operator-sdk 命令的旧版本，该命令可导致有关已弃用功能的警报。现在，包括了 operator-sdk 命令的更新版本，且没有更多用于已弃用的功能的警报。(BZ#2098581)
  • 在以前的版本中，如果 Compliance Operator 无法决定 kubelet 和机器配置之间的关系，则无法应用补救。现在，Compliance Operator 改进了机器配置的处理，并可确定 kubelet 配置是否为机器配置的子集。(BZ#2102511)
  • 在以前的版本中，ocp4-cis-node-master-kubelet-enable-cert-rotation 的规则没有正确描述成功标准。因此，RotateKubelet ClientCertificate 的要求不明确。现在，无论 kubelet 配置文件中存在的配置如何，ocp4-cis-node-master-kubelet-enable-cert-rotation 的规则会准确进行。(BZ#2105153)
  • 在以前的版本中，检查闲置流超时的规则不会考虑默认值，从而导致规则报告不准确。现在，更强大的检查确保了根据默认配置值的准确性增加。(BZ#2105878)
  • 在以前的版本中，当在没有 Ignition 规格的情况下解析机器配置时，Compliance Operator 无法获取 API 资源，这会导致 api-check-pods 进程崩溃循环。现在，Compliance Operator 处理没有 Ignition 规格的机器配置池。(BZ#2117268)
  • 在以前的版本中，因为 modprobe 配置的值不匹配，评估 modprobe 配置的规则也会失败。现在，相同的值用于 modprobe 配置检查和补救，以确保结果保持一致。(BZ#2117747)

5.1.4.3. 启用

  • 指定 Install into all namespaces in the cluster 或将 WATCH_NAMESPACES 环境变量设置为 "" 时不会在影响所有命名空间。在 Compliance Operator 安装时没有指定的命名空间中安装的任何 API 资源都不再可以正常工作。API 资源可能需要在所选命名空间中创建，或默认在 openshift-compliance 命名空间中创建。此更改改进了 Compliance Operator 的内存用量。

5.1.5. OpenShift Compliance Operator 0.1.53

以下公告可用于 OpenShift Compliance Operator 0.1.53：

5.1.5.1. 程序错误修复

  • 在以前的版本中，ocp4-kubelet-enable-streaming-connections 规则包含不正确的变量比较，从而导致假的扫描结果。现在，在设置 streamingConnectionIdleTimeout 时，Compliance Operator 提供了准确的扫描结果。(BZ#2069891)
  • 在以前的版本中，在 IBM Z 构架中，/etc/openvswitch/conf.db 的组所有权不正确，从而导致 ocp4-cis-node-worker-file-groupowner-ovs-conf-db 检查失败。现在，这个检查在 IBM Z 架构系统中被标记为 NOT-APPLICABLE。(BZ#2072597)
  • 在以前的版本中，ocp4-cis-scc-limit-container-allowed-capabilities 规则因为部署中安全性上下文约束(SCC)规则不完整，以 FAIL 状态报告。现在，结果为 MANUAL，它与需要人工干预的其他检查一致。(BZ#2077916)

  • 在以前的版本中，以下规则无法考虑 API 服务器和 TLS 证书和密钥的额外配置路径，即使正确设置了证书和密钥也会导致报告失败：

    • 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

    现在，规则报告会准确观察 kubelet 配置文件中指定的旧文件路径。(BZ#2079813)

  • 在以前的版本中，在评估超时时，content_rule_oauth_or_oauthclient_inactivity_timeout 规则不会考虑部署设置的可配置超时。这会导致规则失败，即使超时有效。现在，Compliance Operator 使用 var_oauth_inactivity_timeout 变量来设置有效的超时长度。(BZ#2081952)
  • 在以前的版本中，Compliance Operator 使用在命名空间上没有适当标记命名空间的管理权限进行特权使用，从而导致有关 Pod 安全级别违反情况的警告信息。现在，Compliance Operator 有适当的命名空间标签，并对访问结果进行适当的调整，而不违反权限。(BZ#2088202)
  • 在以前的版本中，为 rhcos4-high-master-sysctl-kernel-yama-ptrace-scope 和 rhcos4-sysctl-kernel-core-pattern 应用自动补救会导致后续这些规则失败，即使它们被修复。现在，在应用了补救后，规则会正确报告 PASS。（BZ#2094382）
  • 在以前的版本中，因为内存不足例外，Compliance Operator 会以 CrashLoopBackoff 状态失败。现在，Compliance Operator 被改进，在内存和可以正常工作的情况下可以正确处理大型机器配置数据集。(BZ#2094854)

5.1.5.2. 已知问题

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

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

    (BZ#2092913)

5.1.6. OpenShift Compliance Operator 0.1.52

以下公告可用于 OpenShift Compliance Operator 0.1.52：

5.1.6.1. 新功能及功能增强

  • FedRAMP high SCAP 配置集现在可用于 OpenShift Container Platform 环境。如需更多信息，请参阅支持的合规性配置集。

5.1.6.2. 程序错误修复

  • 在以前的版本中，因为存在 DAC_OVERRIDE 功能的安全环境中存在挂载权限问题，OpenScap 容器会崩溃。现在，可执行的挂载权限适用于所有用户。(BZ#2082151)
  • 在以前的版本中，合规性规则 ocp4-configure-network-policies 可以被配置为 MANUAL。现在，合规性规则 ocp4-configure-network-policies 设置为 AUTOMATIC。(BZ#2072431)
  • 在以前的版本中，Cluster Autoscaler 将无法缩减，因为 Compliance Operator 扫描 pod 在扫描后永远不会被删除。现在，pod 默认从每个节点中删除，除非明确为调试目的保存。(BZ#2075029)
  • 在以前的版本中，将 Compliance Operator 应用到 KubeletConfig 会导致节点进入 NotReady 状态，因为无法立即暂停 Machine Config Pools。现在，机器配置池会被正确取消暂停，节点可以正常工作。(BZ#2071854)
  • 在以前的版本中，Machine Config Operator 在最新版本中使用 base64 而不是 url-encoded 代码，从而导致 Compliance Operator 修复失败。现在，Compliance Operator 会检查编码来处理 base64 和 url-encoded Machine Config 代码，补救会正确应用。(BZ#2082431)

5.1.6.3. 已知问题

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

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

    (BZ#2092913)

5.1.7. OpenShift Compliance Operator 0.1.49

以下公告可用于 OpenShift Compliance Operator 0.1.49：

5.1.7.1. 程序错误修复

  • 在以前的版本中，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 始终检查 Cluter Version Operator(CVO)历史记录中的第一个条目。因此，当验证后续版本的 {product-name} 时，升级会失败。现在，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 worker 节点运行的平台检查。因此，对不是基于 Linux 的 worker 节点运行扫描会导致永不结束扫描循环。现在，扫描将根据平台类型和标签进行适当调度，并会完全成功。(BZ#2056911)

5.1.8. OpenShift Compliance Operator 0.1.48

以下公告可用于 OpenShift Compliance Operator 0.1.48：

5.1.8.1. 程序错误修复

  • 在以前的版本中，与扩展开放漏洞和评估语言(OVAL)定义关联的规则带有为 None 的 checkType。这是因为 Compliance Operator 在解析规则时没有处理扩展的 OVAL 定义。在这个版本中，通过扩展 OVAL 定义的内容会被解析，这些规则现在具有 Node 或 Platform 的 checkType。(BZ#2040282)
  • 在以前的版本中，为 KubeletConfig 手动创建的 MachineConfig 对象会阻止为补救生成 KubeletConfig 对象，从而使补救处于 Pending 状态。在这个版本中，补救会创建一个 KubeletConfig 对象，无论是否有为 KubeletConfig 手动创建的 MachineConfig 对象。因此，KubeletConfig 补救现在可以正常工作。(BZ#2040401)

5.1.9. OpenShift Compliance Operator 0.1.47

以下公告可用于 OpenShift Compliance Operator 0.1.47：

5.1.9.1. 新功能及功能增强

  • Compliance Operator 现在支持支付卡行业数据安全标准(PCI DSS)的以下合规性基准：

    • ocp4-pci-dss
    • ocp4-pci-dss-node
  • FedRAMP 模式影响级别的额外规则和补救被添加到 OCP4-moderate、OCP4-moderate-node 和 rhcos4-moderate 配置集中。
  • KubeletConfig 的补救现在包括在节点级别的配置集中。

5.1.9.2. 程序错误修复

  • 在以前的版本中，如果集群运行 OpenShift Container Platform 4.6 或更早版本，则与 USBGuard 相关的规则的补救将失败。这是因为 Compliance Operator 创建的补救基于旧版本的 USBGuard，但不支持丢弃目录。现在，为运行 OpenShift Container Platform 4.6 的集群不会创建与 USBGuard 相关的规则无效的补救。如果您的集群使用 OpenShift Container Platform 4.6，则必须为 USBGuard 相关的规则手动创建补救。

    另外，只会针对满足最低版本要求的规则创建补救。(BZ#1965511)

  • 在以前的版本中，当渲染补救时，合规 Operator 会使用一个太严格的正则表达式来检查补救是否良好。因此，一些补救（如呈现 sshd_config ）不会传递正则表达式检查，因此不会被创建。一些正则表达式已被认定为不必要并被删除。现在，补救可以正确地进行。(BZ#2033009)

5.1.10. OpenShift Compliance Operator 0.1.44

以下公告可用于 OpenShift Compliance Operator 0.1.44：

5.1.10.1. 新功能及功能增强

  • 在这个发行版本中，strictNodeScan 选项被添加到 ComplianceScan、ComplianceSuite 和 ScanSetting CR 中。这个选项默认为与之前行为匹配的 true，当扫描无法调度到某个节点上时出现错误。将选项设置为 false 可让 Compliance Operator 针对调度扫描更加宽松。具有临时节点的环境可将 strictNodeScan 值设为 false，这可以允许进行合规性扫描，即使集群中的某些节点无法调度。
  • 现在，您可以通过配置 ScanSetting 对象的 nodeSelector 和 tolerations 属性来自定义用于调度结果服务器工作负载的节点。这些属性用于放置 ResultServer pod，用于挂载 PV 存储卷并存储原始资产报告格式(ARF)结果。在以前的版本中，nodeSelector 和 tolerations 参数默认选择其中一个 control plane 节点，并容限 node-role.kubernetes.io/master 污点。在不允许 control plane 节点挂载 PV 的环境中工作。此功能为您提供了选择节点并容许这些环境中的不同污点的方法。
  • Compliance Operator 现在可以修复 KubeletConfig 对象。
  • 现在，添加了一个包含错误消息的注释，以帮助内容开发人员区分集群中不存在的对象与无法获取的对象。
  • 规则对象现在包含两个新属性，checkType 和 description。通过这些属性，您可以确定与节点检查或平台检查相关的规则，并允许您检查规则的作用。
  • 此功能增强删除了需要扩展现有配置集的要求，以创建定制的配置集。这意味着 TailoredProfile CRD 中的 extends 字段不再是必需的。现在，您可以选择用于创建定制配置集的规则对象列表。请注意，您必须通过设置 compliance.openshift.io/product-type: 注解或为 TailoredProfile CR 设置 -node 后缀来选择您的配置集是否应用到节点或平台。
  • 在本发行版本中，Compliance Operator 现在可以在其污点的所有节点上调度扫描。在以前的版本中，扫描 pod 只容许 node-role.kubernetes.io/master 污点，这意味着它们可以在没有污点的节点上运行，或者仅在具有 node-role.kubernetes.io/master 污点的节点上运行。在将自定义污点用于其节点的部署中，这会导致扫描不会被调度到这些节点上。现在，扫描 pod 可以容限所有节点污点。

  • 在本发行版本中，Compliance Operator 支持以下 North American Electric Reliability Corporation (NERC 安全配置集：

    • ocp4-nerc-cip
    • ocp4-nerc-cip-node
    • rhcos4-nerc-cip
  • 在本发行版本中，Compliance Operator 支持 Red Hat OpenShift - Node level、ocp4-moderate-node、security 配置集中的 NIST 800-53 Moderate-Impact Baseline。

5.1.10.2. 模板和变量使用

  • 在本发行版本中，补救模板现在允许多值变量。
  • 在这个版本中，Compliance Operator 可以根据合规性配置集中设置的变量更改补救。这可用于包括特定于部署的补救值，如超时、NTP 服务器主机名或类似值。另外，ComplianceCheckResult 对象现在使用标签 compliance.openshift.io/check-has-value 列出检查使用的变量。

5.1.10.3. 程序错误修复

  • 在以前的版本中，在执行扫描时，pod 的扫描程序容器中会发生意外终止。在本发行版本中，Compliance Operator 使用最新的 OpenSCAP 版本 1.3.5 来避免崩溃。
  • 在以前的版本中，使用 autoReplyRemediations 应用补救会触发对集群节点的更新。如果某些补救不包括所有所需的输入变量，则会出现破坏性。现在，如果缺少一个或多个所需的输入变量，则会为其分配一个 NeedsReview 状态。如果一个或多个补救处于 NeedsReview 状态，机器配置池会保持暂停，且在设置所有需要的变量前不会应用补救。这有助于最小化对节点的中断。
  • 用于 Prometheus 指标的 RBAC 角色和角色绑定改为 'ClusterRole' 和 'ClusterRoleBinding'，以确保监控在没有自定义的情况下正常工作。
  • 在以前的版本中，如果在解析配置集时出现错误，规则或变量对象会从配置集中删除并删除。现在，如果解析过程中出现错误，profileparser 会使用临时注解为对象添加注解，该注解会阻止对象在解析完成后被删除。(BZ#1988259)
  • 在以前的版本中，当自定义配置集中没有标题或描述时会出现一个错误。由于 XCCDF 标准需要定制配置集的标题和描述，现在需要在 TailoredProfile CR 中设置标题和描述。
  • 在以前的版本中，当使用定制配置集时，允许使用特定的选择设置 TailoredProfile 变量值。这个限制现已被删除，TailoredProfile 变量可以设置为任何值。

5.1.11. Compliance Operator 0.1.39 发行注记

以下公告可用于 OpenShift Compliance Operator 0.1.39：

5.1.11.1. 新功能及功能增强

  • 在以前的版本中，Compliance Operator 无法解析 Payment Card Industry Data Security Standard（PCI DSS）参考。现在，Operator 可以解析 PCI DSS 配置集附带的合规性内容。
  • 在以前的版本中，Compliance Operator 无法在 moderate 配置集中为 AU-5 控制执行规则。现在，权限被添加到 Operator 中，以便它可以读取 Prometheusrules.monitoring.coreos.com 对象，并运行在 moderate 配置集中涵盖 AU-5 控制的规则。

5.1.12. 其他资源