第 5 章 Compliance Operator
5.1. Compliance Operator 发行注记
通过 Compliance Operator,OpenShift Container Platform 管理员可以描述集群所需的合规状态,并概述缺陷及修复方法。
本发行注记介绍了 OpenShift Container Platform 中 Compliance Operator 的开发。
有关 Compliance Operator 的概述,请参阅了解 Compliance Operator。
5.1.1. OpenShift Compliance Operator 0.1.53
以下公告可用于 OpenShift Compliance Operator 0.1.53:
5.1.1.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.1.2. 已知问题
当在
ScanSettingBinding
对象中设置"debug":true
时,当删除该绑定时,由ScanSettingBinding
对象生成的 pod 不会被删除。作为临时解决方案,运行以下命令来删除剩余的 pod:$ oc delete pods -l compliance.openshift.io/scan-name=ocp4-cis
5.1.2. OpenShift Compliance Operator 0.1.52
以下公告可用于 OpenShift Compliance Operator 0.1.52:
5.1.2.1. 新功能及功能增强
- FedRAMP high SCAP 配置集现在可用于 OpenShift Container Platform 环境。如需更多信息,请参阅支持的合规性配置集。
5.1.2.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.2.3. 已知问题
当在
ScanSettingBinding
对象中设置"debug":true
时,当删除该绑定时,由ScanSettingBinding
对象生成的 pod 不会被删除。作为临时解决方案,运行以下命令来删除剩余的 pod:$ oc delete pods -l compliance.openshift.io/scan-name=ocp4-cis
5.1.3. OpenShift Compliance Operator 0.1.49
以下公告可用于 OpenShift Compliance Operator 0.1.49:
5.1.3.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.4. OpenShift Compliance Operator 0.1.48
以下公告可用于 OpenShift Compliance Operator 0.1.48:
5.1.4.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.5. OpenShift Compliance Operator 0.1.47
以下公告可用于 OpenShift Compliance Operator 0.1.47:
5.1.5.1. 新功能及功能增强
Compliance Operator 现在支持支付卡行业数据安全标准(PCI DSS)的以下合规性基准:
- ocp4-pci-dss
- ocp4-pci-dss-node
- FedRAMP 模式影响级别的额外规则和补救被添加到 OCP4-moderate、OCP4-moderate-node 和 rhcos4-moderate 配置集中。
- KubeletConfig 的补救现在包括在节点级别的配置集中。
5.1.5.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.6. OpenShift Compliance Operator 0.1.44
以下公告可用于 OpenShift Compliance Operator 0.1.44:
5.1.6.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.6.2. 模板和变量使用
- 在本发行版本中,补救模板现在允许多值变量。
-
在这个版本中,Compliance Operator 可以根据合规性配置集中设置的变量更改补救。这可用于包括特定于部署的补救值,如超时、NTP 服务器主机名或类似值。另外,
ComplianceCheckResult
对象现在使用标签compliance.openshift.io/check-has-value
列出检查使用的变量。
5.1.6.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.7. Compliance Operator 0.1.39 发行注记
以下公告可用于 OpenShift Compliance Operator 0.1.39:
5.1.7.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 控制的规则。