第 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 时,使用带有非默认 MachineConfigPoolTailoredProfileScanSettingBinding 标记为 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-dssocp4-pci-dss-node 配置集。

5.1.3.2. 程序错误修复

  • 在以前的版本中,Compliance Operator 不支持在不同架构上(如 ppc64le)的 Payment Card industry Data Security Standard (PCI DSS) ocp4-pci-dssocp4-pci-dss-node 配置集。现在,Compliance Operator 在 ppc64le 架构上支持 ocp4-pci-dssocp4-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-scoperhcos4-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 会检查编码来处理 base64url-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. 新功能及功能增强

  • Compliance Operator 现在支持以下架构:

    • IBM Power
    • IBM Z
    • IBM LinuxONE

5.1.7.2. 程序错误修复

  • 在以前的版本中,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)定义关联的规则带有为 NonecheckType。这是因为 Compliance Operator 在解析规则时没有处理扩展的 OVAL 定义。在这个版本中,通过扩展 OVAL 定义的内容会被解析,这些规则现在具有 NodePlatformcheckType。(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 选项被添加到 ComplianceScanComplianceSuiteScanSetting CR 中。这个选项默认为与之前行为匹配的 true,当扫描无法调度到某个节点上时出现错误。将选项设置为 false 可让 Compliance Operator 针对调度扫描更加宽松。具有临时节点的环境可将 strictNodeScan 值设为 false,这可以允许进行合规性扫描,即使集群中的某些节点无法调度。
  • 现在,您可以通过配置 ScanSetting 对象的 nodeSelectortolerations 属性来自定义用于调度结果服务器工作负载的节点。这些属性用于放置 ResultServer pod,用于挂载 PV 存储卷并存储原始资产报告格式(ARF)结果。在以前的版本中,nodeSelectortolerations 参数默认选择其中一个 control plane 节点,并容限 node-role.kubernetes.io/master 污点。在不允许 control plane 节点挂载 PV 的环境中工作。此功能为您提供了选择节点并容许这些环境中的不同污点的方法。
  • Compliance Operator 现在可以修复 KubeletConfig 对象。
  • 现在,添加了一个包含错误消息的注释,以帮助内容开发人员区分集群中不存在的对象与无法获取的对象。
  • 规则对象现在包含两个新属性,checkTypedescription。通过这些属性,您可以确定与节点检查或平台检查相关的规则,并允许您检查规则的作用。
  • 此功能增强删除了需要扩展现有配置集的要求,以创建定制的配置集。这意味着 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. 其他资源