5.2. Compliance Operator 发行注记
通过 Compliance Operator,OpenShift Container Platform 管理员可以描述集群所需的合规状态,并概述缺陷及修复方法。
本发行注记介绍了 OpenShift Container Platform 中 Compliance Operator 的开发。
有关 Compliance Operator 的概述,请参阅了解 Compliance Operator。
要访问最新版本,请参阅更新 Compliance Operator。
有关所有红帽产品合规支持的更多信息,请参阅 产品合规性。
5.2.1. OpenShift Compliance Operator 1.6.0
以下公告可用于 OpenShift Compliance Operator 1.6.0:
5.2.1.1. 新功能及功能增强
- Compliance Operator 现在包含支付卡行业数据安全标准 (PCI-DSS) 版本 4 支持的配置集。如需更多信息,请参阅支持的合规性配置集。
- Compliance Operator 现在包含国防信息系统局安全技术实施指南(DISA STIG) V2R1 支持的配置集。如需更多信息,请参阅支持的合规性配置集。
-
现在,在
x86
、ppc64le
、和s390x
架构上安装的 Compliance Operator 提供了must-gather
扩展。must-gather
工具为红帽客户支持和工程提供了关键配置详情。如需更多信息,请参阅为 Compliance Operator 使用 must-gather 工具。
5.2.1.2. 程序错误修复
-
在此版本之前,
ocp4-route-ip-whitelist
规则中的信息会造成误导,从而导致错误配置不当。在这个版本中,该规则被更为明确地定义。(CMP-2485) -
在以前的版本中,对于
DONE
状态为ComplianceScan
的所有ComplianceCheckResults
的报告并不完全。在这个版本中,添加了一个注解来报告带有DONE
状态的ComplianceScan
的ComplianceCheckResult
总数。(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
配置中错误地引用 secret 会导致 Prometheus Operator 的集成问题。在这个版本中,Compliance Operator 会准确引用包含ServiceMonitor
指标的令牌的 secret。(OCPBUGS-39417)
5.2.2. OpenShift Compliance Operator 1.5.1
以下公告可用于 OpenShift Compliance Operator 1.5.1:
5.2.3. OpenShift Compliance Operator 1.5.0
以下公告可用于 OpenShift Compliance Operator 1.5.0:
5.2.3.1. 新功能及功能增强
5.2.3.2. 程序错误修复
- CVE-2024-2961 在 Compliance Operator 1.5.0 版本中解决。(CVE-2024-2961)
- 在以前的版本中,对于 ROSA HCP 系统,配置集列表不正确。在这个版本中,Compliance Operator 提供了正确的配置集输出。(OCPBUGS-34535)
-
在这个版本中,通过在定制的配置集中设置
ocp4-var-network-policies-namespaces-exempt-regex
变量,可以从ocp4-configure-network-policies-namespaces
中排除命名空间。(CMP-2543)
5.2.4. OpenShift Compliance Operator 1.4.1
以下公告可用于 OpenShift Compliance Operator 1.4.1:
5.2.4.1. 新功能及功能增强
5.2.4.2. 程序错误修复
-
在以前的版本中,对于使用 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 访问 core 用户帐户。在这个版本中,节点可以使用 'sshkey1 选项通过 SSH 访问。(OCPBUGS-18331) -
在以前的版本中,
STIG
配置文件缺少来自 CaC 的规则,它们满足对 OpenShift Container Platform 公布的STIG
的要求。在这个版本中,在补救时,集群满足可以使用 Compliance Operator 修复的STIG
要求。(OCPBUGS-26193) -
在以前的版本中,为多个产品创建一个带有不同类型配置集的
ScanSettingBinding
对象,针对绑定中的多个产品类型绕过限制。在这个版本中,产品验证允许多个产品,无论ScanSettingBinding
对象中的配置集类型是什么。(OCPBUGS-26229) -
在以前的版本中,运行
rhcos4-service-debug-shell-disabled
规则显示FAIL
,即使使用了自动补救(auto-remediation)功能。在这个版本中,运行rhcos4-service-debug-shell-disabled
规则会在应用 auto-remediation 后显示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) 对象中显示的完成扫描中删除配置集时,Compliance Operator 不会删除旧的扫描。之后,当使用删除的配置集启动新的 SSB 时,Compliance Operator 无法更新结果。在这个版本中,新的 SSB 会显示新的合规性检查结果。(OCPBUGS-29272) -
在以前的版本中,在
ppc64le
架构中,不会创建 metrics 服务。在这个版本中,当在ppc64le
架构上部署 Compliance Operator v1.4.1 时,指标服务会被正确创建。(OCPBUGS-32797) -
在以前的版本中,在 HyperShift 托管集群中,带有
ocp4-pci-dss profile
的扫描会遇到一个不可恢复的错误,因为过滤器无法迭代
问题。在这个版本中,对ocp4-pci-dss
配置集的扫描将到达done
状态,并返回Compliance
或Non-Compliance
测试结果。(OCPBUGS-33067)
5.2.5. OpenShift Compliance Operator 1.4.0
以下公告可用于 OpenShift Compliance Operator 1.4.0:
5.2.5.1. 新功能及功能增强
-
在这个版本中,使用默认
worker
和master
节点池以外的自定义节点池的集群不再需要提供额外变量,以确保 Compliance Operator 聚合该节点池的配置文件。 -
用户现在可以通过将
ScanSetting.suspend
属性设置为True
来暂停扫描调度。这允许用户挂起扫描调度,并在不需要删除并重新创建ScanSettingBinding
的情况下重新激活它。这简化了维护期间的暂停扫描计划。(CMP-2123) -
Compliance Operator 现在支持
Profile
自定义资源上的可选version
属性。(CMP-2125) -
Compliance Operator 现在支持
ComplianceRules
中的配置集名称。(CMP-2126) -
这个版本提供了与改进的
cronjob
API 的改进 Operator 兼容性。(CMP-2310)
5.2.5.2. 程序错误修复
- 在以前的版本中,在带有 Windows 节点的集群中,一些规则会在应用自动补救后 FAIL,因为合规性扫描不会跳过 Windows 节点。在这个版本中,扫描时会正确跳过 Windows 节点。(OCPBUGS-7355)
-
在这个版本中,对依赖多路径的 pod 的 root 卷挂载可以正确地处理
rprivate
默认挂载传播。(OCPBUGS-17494) -
在以前的版本中,Compliance Operator 会在不协调规则的情况下为
coreos_vsyscall_kernel_argument
生成补救,即使应用补救也是如此。在版本 1.4.0 中,coreos_vsyscall_kernel_argument
规则可以正确地评估内核参数并生成适当的补救。(OCPBUGS-8041) -
在此次更新之前,即使应用了 auto-remediation 后,规则
rhcos4-audit-rules-login-events-faillock
将失败。在这个版本中,rhcos4-audit-rules-login-events-faillock
失败锁定会在 auto-remediation 后被正确应用。(OCPBUGS-24594) -
在以前的版本中,从 Compliance Operator 1.3.1 升级到 Compliance Operator 1.4.0 会导致 OVS 规则扫描结果从
PASS
变为NOT-APPLICABLE
。在这个版本中,OVS 规则扫描结果显示PASS
(OCPBUGS-25323)
5.2.6. OpenShift Compliance Operator 1.3.1
以下公告可用于 OpenShift Compliance Operator 1.3.1:
这个版本解决了底层依赖项中的 CVE。
在将 OpenShift Container Platform 集群更新至版本 4.14 或更高版本前,建议将 Compliance Operator 更新至 1.3.1 或更高版本。
5.2.6.1. 新功能及功能增强
您可以在以 FIPS 模式运行的 OpenShift Container Platform 集群中安装和使用 Compliance Operator。
重要要为集群启用 FIPS 模式,您必须从配置为以 FIPS 模式操作的 RHEL 计算机运行安装程序。有关在 RHEL 中配置 FIPS 模式的更多信息,请参阅在 FIPS 模式中安装该系统。
5.2.6.2. 已知问题
- 在带有 Windows 节点的集群上,一些规则会在应用自动补救后 FAIL,因为合规性扫描不会跳过 Windows 节点。这与预期结果不同,因为扫描时必须跳过 Windows 节点。(OCPBUGS-7355)
5.2.7. OpenShift Compliance Operator 1.3.0
以下公告可用于 OpenShift Compliance Operator 1.3.0 :
5.2.7.1. 新功能及功能增强
- 从 Compliance Operator 1.3.0 开始,Defense Information Systems Agency Security Technical Implementation Guide (DISA-STIG) for OpenShift Container Platform 可用。如需更多信息,请参阅支持的合规性配置集。
- Compliance Operator 1.3.0 现在支持用于 NIST 800-53 Moderate-Impact Baseline 的 IBM Power® 和 IBM Z® 用于 OpenShift Container Platform 平台和节点配置集。
5.2.8. OpenShift Compliance Operator 1.2.0
以下公告可用于 OpenShift Compliance Operator 1.2.0 :
5.2.8.1. 新功能及功能增强
CIS OpenShift Container Platform 4 Benchmark v1.4.0 配置集现在可用于平台和节点应用程序。要找到 CIS OpenShift Container Platform v4 Benchmark,进入 CIS Benchmarks 并点 Download Latest CIS Benchmark,然后注册以下载基准。
重要升级到 Compliance Operator 1.2.0 将覆盖 CIS OpenShift Container Platform 4 Benchmark 1.1.0 配置集。
如果您的 OpenShift Container Platform 环境包含现有的
cis
和cis-node
补救,在升级到 Compliance Operator 1.2.0 后,扫描结果可能会有一些区别。-
现在,
scc-limit-container-allowed-capabilities
规则提供了额外的审计安全性上下文约束(SCC)。
5.2.9. OpenShift Compliance Operator 1.1.0
以下公告可用于 OpenShift Compliance Operator 1.1.0:
5.2.9.1. 新功能及功能增强
-
现在,在
ComplianceScan
自定义资源定义 (CRD) 状态中提供了 start 和 end 时间戳。 -
现在,通过创建一个
Subscription
文件,可以使用 OperatorHub 部署 Compliance Operator。如需更多信息,请参阅在托管的 control plane 上安装 Compliance Operator。
5.2.9.2. 程序错误修复
在此次更新之前,一些 Compliance Operator 规则指令不存在。在这个版本中,以下规则改进了说明:
-
classification_banner
-
oauth_login_template_set
-
oauth_logout_url_set
-
oauth_provider_selection_set
-
ocp_allowed_registries
ocp_allowed_registries_for_import
-
在此次更新之前,检查准确性和规则指令并不明确。在这个版本中,以下
sysctl
规则改进了检查准确性和说明:-
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
-
-
在此次更新之前,
ocp4-alert-receiver-configured
规则不包括指令。在这个版本中,ocp4-alert-receiver-configured
规则包括改进的指令。(OCPBUGS-7307) -
在此次更新之前,对于
rhcos4-e8
配置集,rhcos4-sshd-set-loglevel-info
规则会失败。在这个版本中,sshd-set-loglevel-info
规则的补救已更新,以应用正确的配置更改,允许在应用补救后进行后续扫描通过。(OCPBUGS-7816) -
在此次更新之前,带有最新 Compliance Operator 安装的新 OpenShift Container Platform 在
scheduler-no-bind-address
规则中会失败。在这个版本中,自删除参数后,在 OpenShift Container Platform 较新版本的 OpenShift Container Platform 上禁用了scheduler-no-bind-address
规则。(OCPBUGS-8347)
5.2.10. OpenShift Compliance Operator 1.0.0
以下公告可用于 OpenShift Compliance Operator 1.0.0:
5.2.10.1. 新功能及功能增强
-
Compliance Operator 现在是稳定的,发行频道已升级到
stable
。将来的版本将遵循 Semantic Versioning。要访问最新版本,请参阅更新 Compliance Operator。
5.2.10.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.2.11. OpenShift Compliance Operator 0.1.61
以下公告可用于 OpenShift Compliance Operator 0.1.61:
5.2.11.1. 新功能及功能增强
-
Compliance Operator 现在支持 Scanner Pod 的超时配置。超时在
ScanSetting
对象中指定。如果在超时时间内没有完成扫描,扫描会重试,直到达到最大重试次数为止。如需更多信息,请参阅配置 ScanSetting 超时。
5.2.11.2. 程序错误修复
-
在此次更新之前,Compliance Operator 补救需要变量作为输入。没有变量集的补救会在集群范围内应用,并导致节点卡住,即使它正确应用了补救。在这个版本中,Compliance Operator 会验证是否需要使用
TailoredProfile
进行补救提供变量。(OCPBUGS-3864) -
在此次更新之前,
ocp4-kubelet-configure-tls-cipher-suites
的说明不完整,需要用户手动优化查询。在这个版本中,ocp4-kubelet-configure-tls-cipher-suites
中提供的查询会返回实际结果来执行审计步骤。(OCPBUGS-3017) - 在此次更新之前,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)
-
在此次更新之前,当试图创建一个
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.2.12. OpenShift Compliance Operator 0.1.59
以下公告可用于 OpenShift Compliance Operator 0.1.59:
5.2.12.1. 新功能及功能增强
-
Compliance Operator 现在支持
ppc64le
架构上的支付卡行业数据安全标准 (PCI-DSS)ocp4-pci-dss
和ocp4-pci-dss-node
配置集。
5.2.12.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)
5.2.13. OpenShift Compliance Operator 0.1.57
以下公告可用于 OpenShift Compliance Operator 0.1.57:
5.2.13.1. 新功能及功能增强
-
KubeletConfig
检查从Node
改为Platform
类型。KubeletConfig
检查KubeletConfig
的默认配置。配置文件从所有节点聚合到每个节点池的一个位置。请参阅针对默认配置值评估KubeletConfig
规则。 -
ScanSetting
自定义资源现在允许用户通过scanLimits
属性覆盖扫描程序 Pod 的默认 CPU 和内存限值。如需更多信息,请参阅增加 Compliance Operator 资源限制。 -
现在,可以通过
ScanSetting
设置PriorityClass
对象。这样可确保 Compliance Operator 被优先处理,并尽可能减少集群不合规的可能性。如需更多信息,请参阅为ScanSetting
扫描设置PriorityClass
。
5.2.13.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
的规则没有正确描述成功标准。因此,RotateKubeletClientCertificate
的要求不明确。现在,无论 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.2.13.3. 启用
-
指定 Install into all namespaces in the cluster 或将
WATCH_NAMESPACES
环境变量设置为""
时不会在影响所有命名空间。在 Compliance Operator 安装时没有指定的命名空间中安装的任何 API 资源都不再可以正常工作。API 资源可能需要在所选命名空间中创建,或默认在openshift-compliance
命名空间中创建。此更改改进了 Compliance Operator 的内存用量。
5.2.14. OpenShift Compliance Operator 0.1.53
以下公告可用于 OpenShift Compliance Operator 0.1.53:
5.2.14.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.2.14.2. 已知问题
当在
ScanSettingBinding
对象中设置"debug":true
时,当删除该绑定时,由ScanSettingBinding
对象生成的 pod 不会被删除。作为临时解决方案,运行以下命令来删除剩余的 pod:$ oc delete pods -l compliance.openshift.io/scan-name=ocp4-cis
5.2.15. OpenShift Compliance Operator 0.1.52
以下公告可用于 OpenShift Compliance Operator 0.1.52:
5.2.15.1. 新功能及功能增强
- FedRAMP high SCAP 配置集现在可用于 OpenShift Container Platform 环境。如需更多信息,请参阅支持的合规性配置集。
5.2.15.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.2.15.3. 已知问题
当在
ScanSettingBinding
对象中设置"debug":true
时,当删除该绑定时,由ScanSettingBinding
对象生成的 pod 不会被删除。作为临时解决方案,运行以下命令来删除剩余的 pod:$ oc delete pods -l compliance.openshift.io/scan-name=ocp4-cis
5.2.16. OpenShift Compliance Operator 0.1.49
以下公告可用于 OpenShift Compliance Operator 0.1.49:
5.2.16.1. 新功能及功能增强
Compliance Operator 现在支持以下架构:
- IBM Power®
- IBM Z®
- IBM® LinuxONE
5.2.16.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)历史记录中的第一个条目。因此,当验证后续版本的 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 worker 节点运行的平台检查。因此,对不是基于 Linux 的 worker 节点运行扫描会导致永不结束扫描循环。现在,扫描将根据平台类型和标签进行适当调度,并会完全成功。(BZ#2056911)
5.2.17. OpenShift Compliance Operator 0.1.48
以下公告可用于 OpenShift Compliance Operator 0.1.48:
5.2.17.1. 程序错误修复
-
在以前的版本中,与扩展开放漏洞和评估语言(OVAL)定义关联的规则带有为
None
的checkType
。这是因为 Compliance Operator 在解析规则时没有处理扩展的 OVAL 定义。在这个版本中,通过扩展 OVAL 定义的内容会被解析,这些规则现在具有Node
或Platform
的checkType
。(BZ#2040282) -
在以前的版本中,为
KubeletConfig
手动创建的MachineConfig
对象会阻止为补救生成KubeletConfig
对象,从而使补救处于Pending
状态。在这个版本中,补救会创建一个KubeletConfig
对象,无论是否有为KubeletConfig
手动创建的MachineConfig
对象。因此,KubeletConfig
补救现在可以正常工作。(BZ#2040401)
5.2.18. OpenShift Compliance Operator 0.1.47
以下公告可用于 OpenShift Compliance Operator 0.1.47:
5.2.18.1. 新功能及功能增强
Compliance Operator 现在支持支付卡行业数据安全标准(PCI DSS)的以下合规性基准:
- ocp4-pci-dss
- ocp4-pci-dss-node
- FedRAMP 模式影响级别的额外规则和补救被添加到 OCP4-moderate、OCP4-moderate-node 和 rhcos4-moderate 配置集中。
- KubeletConfig 的补救现在包括在节点级别的配置集中。
5.2.18.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.2.19. OpenShift Compliance Operator 0.1.44
以下公告可用于 OpenShift Compliance Operator 0.1.44:
5.2.19.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.2.19.2. 模板和变量使用
- 在本发行版本中,补救模板现在允许多值变量。
-
在这个版本中,Compliance Operator 可以根据合规性配置集中设置的变量更改补救。这可用于包括特定于部署的补救值,如超时、NTP 服务器主机名或类似值。另外,
ComplianceCheckResult
对象现在使用标签compliance.openshift.io/check-has-value
列出检查使用的变量。
5.2.19.3. 程序错误修复
- 在以前的版本中,在执行扫描时,pod 的扫描程序容器中会发生意外终止。在本发行版本中,Compliance Operator 使用最新的 OpenSCAP 版本 1.3.5 来避免崩溃。
-
在以前的版本中,使用
autoReplyRemediations
应用补救会触发对集群节点的更新。如果某些补救不包括所有所需的输入变量,则会出现破坏性。现在,如果缺少一个或多个所需的输入变量,则会为其分配一个NeedsReview
状态。如果一个或多个补救处于NeedsReview
状态,机器配置池会保持暂停,且在设置所有需要的变量前不会应用补救。这有助于最小化对节点的中断。 - 用于 Prometheus 指标的 RBAC 角色和角色绑定改为 'ClusterRole' 和 'ClusterRoleBinding',以确保监控在没有自定义的情况下正常工作。
-
在以前的版本中,如果在解析配置集时出现错误,规则或变量对象会从配置集中删除并删除。现在,如果解析过程中出现错误,
profileparser
会使用临时注解为对象添加注解,该注解会阻止对象在解析完成后被删除。(BZ#1988259) -
在以前的版本中,当自定义配置集中没有标题或描述时会出现一个错误。由于 XCCDF 标准需要定制配置集的标题和描述,现在需要在
TailoredProfile
CR 中设置标题和描述。 -
在以前的版本中,当使用定制配置集时,允许使用特定的选择设置
TailoredProfile
变量值。这个限制现已被删除,TailoredProfile
变量可以设置为任何值。
5.2.20. Compliance Operator 0.1.39 发行注记
以下公告可用于 OpenShift Compliance Operator 0.1.39:
5.2.20.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 控制的规则。