安全性与合规性

• 守护进程集：如果您需要在每个节点上运行某个服务，您可以使用 Kubernetes 的 DaemonSet 对象添加该服务。
• 机器配置：MachineConfig 对象包含 Ignition 配置的子集，其格式相同。通过将机器配置应用到所有 worker 或 control plane 节点，您可以确保添加到集群中的同类型的下一个节点会应用相同的更改。

先决条件

• 已安装 skopeo 命令行工具。

• 运行特权容器
• 容器可请求添加的功能
• 将主机目录用作卷。
• 容器的 SELinux 上下文。
• 容器用户 ID。

• 范围限制为特定项目
• 名称来自其项目
• 会被自动分配一个 API 令牌和凭证来访问 OpenShift Container Registry

• 使用传输层安全 (TLS) 访问 master
• 使用 X.509 证书或 OAuth 访问令牌访问 API 服务器
• 通过项目配额限制异常令牌可以造成的破坏
• Etcd 服务不直接向集群公开

其他资源

• 了解 Machine Config Operator。
• 关于 OpenShift SDN 网络插件。

• Compliance Operator 现在包含支付卡行业数据安全标准 (PCI-DSS) 版本 4 支持的配置集。如需更多信息，请参阅支持的合规性配置集。
• Compliance Operator 现在包含国防信息系统局安全技术实施指南(DISA STIG) V2R1 支持的配置集。如需更多信息，请参阅支持的合规性配置集。
• 现在，在 x86、ppc64le、和 s390x 架构上安装的 Compliance Operator 提供了 must-gather 扩展。must-gather 工具为红帽客户支持和工程提供了关键配置详情。如需更多信息，请参阅为 Compliance Operator 使用 must-gather 工具。

• 在此版本之前，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)

• 在这个版本中，Compliance Operator 提供了一个唯一的配置集 ID，以便更轻松地使用。(CMP-2450)
• 在这个版本中，Compliance Operator 在 ROSA HCP 环境中经过测试和支持。在 ROSA HCP 上运行时，Compliance Operator 只加载 Node 配置集。这是因为红帽托管平台限制对 control plane 的访问，这使得 Platform 配置集与 Operator 的功能无关。(CMP-2581)

• 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)

• 在这个版本中，Compliance Operator 提供了 CIS OpenShift 1.5.0 配置集规则。(CMP-2447)
• 在这个版本中，Compliance Operator 为 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 访问 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)

• 在这个版本中，使用默认 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)

• 在以前的版本中，在带有 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)

• 您可以在以 FIPS 模式运行的 OpenShift Container Platform 集群中安装和使用 Compliance Operator。

  重要

  要为集群启用 FIPS 模式，您必须从配置为以 FIPS 模式操作的 RHEL 计算机运行安装程序。有关在 RHEL 中配置 FIPS 模式的更多信息，请参阅在 FIPS 模式中安装该系统。

• 在带有 Windows 节点的集群上，一些规则会在应用自动补救后 FAIL，因为合规性扫描不会跳过 Windows 节点。这与预期结果不同，因为扫描时必须跳过 Windows 节点。(OCPBUGS-7355)

• 从 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 平台和节点配置集。

• 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)。

• 当使用 CIS OpenShift Container Platform 4 Benchmark v1.4.0 配置集时，一些控制可能会因为 CIS 配置集中的更紧密的权限而不是 OpenShift Container Platform 中的权限而失败。如需更多信息，请参阅 解决方案 :7024725。

• 现在，在 ComplianceScan 自定义资源定义 (CRD) 状态中提供了 start 和 end 时间戳。
• 现在，通过创建一个 Subscription 文件，可以使用 OperatorHub 部署 Compliance Operator。如需更多信息，请参阅在托管 Control Planes 上安装 Compliance Operator。

• 在此次更新之前，一些 Compliance Operator 规则指令不存在。在这个版本中，以下规则改进了说明：

  • classification_banner
  • oauth_login_template_set
  • oauth_logout_url_set
  • oauth_provider_selection_set
  • ocp_allowed_registries

  • ocp_allowed_registries_for_import

    (OCPBUGS-10473)

• 在此次更新之前，检查准确性和规则指令并不明确。在这个版本中，以下 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

    (OCPBUGS-11334)

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

• Compliance Operator 现在是稳定的，发行频道已升级到 stable。将来的版本将遵循 Semantic Versioning。要访问最新版本，请参阅更新 Compliance Operator。

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

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

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

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

• 在以前的版本中，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)

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

• 在以前的版本中，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)

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

• 在以前的版本中，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)

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

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

  (BZ#2092913)

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

• 在以前的版本中，因为存在 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)

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

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

  (BZ#2092913)

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

  • IBM Power
  • IBM Z
  • IBM LinuxONE

• 在以前的版本中，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)

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

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

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

• 在以前的版本中，如果集群运行 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)

• 在这个发行版本中，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。

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

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

• 在以前的版本中，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 控制的规则。

• 查看可用的配置集：

  $ oc get profile.compliance -n openshift-compliance

  输出示例

  NAME                       AGE     VERSION
  ocp4-cis                   3h49m   1.5.0
  ocp4-cis-1-4               3h49m   1.4.0
  ocp4-cis-1-5               3h49m   1.5.0
  ocp4-cis-node              3h49m   1.5.0
  ocp4-cis-node-1-4          3h49m   1.4.0
  ocp4-cis-node-1-5          3h49m   1.5.0
  ocp4-e8                    3h49m
  ocp4-high                  3h49m   Revision 4
  ocp4-high-node             3h49m   Revision 4
  ocp4-high-node-rev-4       3h49m   Revision 4
  ocp4-high-rev-4            3h49m   Revision 4
  ocp4-moderate              3h49m   Revision 4
  ocp4-moderate-node         3h49m   Revision 4
  ocp4-moderate-node-rev-4   3h49m   Revision 4
  ocp4-moderate-rev-4        3h49m   Revision 4
  ocp4-nerc-cip              3h49m
  ocp4-nerc-cip-node         3h49m
  ocp4-pci-dss               3h49m   3.2.1
  ocp4-pci-dss-3-2           3h49m   3.2.1
  ocp4-pci-dss-4-0           3h49m   4.0.0
  ocp4-pci-dss-node          3h49m   3.2.1
  ocp4-pci-dss-node-3-2      3h49m   3.2.1
  ocp4-pci-dss-node-4-0      3h49m   4.0.0
  ocp4-stig                  3h49m   V2R1
  ocp4-stig-node             3h49m   V2R1
  ocp4-stig-node-v1r1        3h49m   V1R1
  ocp4-stig-node-v2r1        3h49m   V2R1
  ocp4-stig-v1r1             3h49m   V1R1
  ocp4-stig-v2r1             3h49m   V2R1
  rhcos4-e8                  3h49m
  rhcos4-high                3h49m   Revision 4
  rhcos4-high-rev-4          3h49m   Revision 4
  rhcos4-moderate            3h49m   Revision 4
  rhcos4-moderate-rev-4      3h49m   Revision 4
  rhcos4-nerc-cip            3h49m
  rhcos4-stig                3h49m   V2R1
  rhcos4-stig-v1r1           3h49m   V1R1
  rhcos4-stig-v2r1           3h49m   V2R1

  这些配置集代表不同的合规性基准。每个配置集将其应用到的产品名称添加为配置集名称的前缀。ocp4-e8 将 Essential 8 基准应用到 OpenShift Container Platform 产品，而 rhcos4-e8 将 Essential 8 基准应用到 Red Hat Enterprise Linux CoreOS (RHCOS) 产品。

• 运行以下命令，以查看 rhcos4-e8 配置集的详情：

  $ oc get -n openshift-compliance -oyaml profiles.compliance rhcos4-e8

  例 5.1. 输出示例

  apiVersion: compliance.openshift.io/v1alpha1
  description: 'This profile contains configuration checks for Red Hat Enterprise Linux
    CoreOS that align to the Australian Cyber Security Centre (ACSC) Essential Eight.
    A copy of the Essential Eight in Linux Environments guide can be found at the ACSC
    website: https://www.cyber.gov.au/acsc/view-all-content/publications/hardening-linux-workstations-and-servers'
  id: xccdf_org.ssgproject.content_profile_e8
  kind: Profile
  metadata:
    annotations:
      compliance.openshift.io/image-digest: pb-rhcos4hrdkm
      compliance.openshift.io/product: redhat_enterprise_linux_coreos_4
      compliance.openshift.io/product-type: Node
    creationTimestamp: "2022-10-19T12:06:49Z"
    generation: 1
    labels:
      compliance.openshift.io/profile-bundle: rhcos4
    name: rhcos4-e8
    namespace: openshift-compliance
    ownerReferences:
    - apiVersion: compliance.openshift.io/v1alpha1
      blockOwnerDeletion: true
      controller: true
      kind: ProfileBundle
      name: rhcos4
      uid: 22350850-af4a-4f5c-9a42-5e7b68b82d7d
    resourceVersion: "43699"
    uid: 86353f70-28f7-40b4-bf0e-6289ec33675b
  rules:
  - rhcos4-accounts-no-uid-except-zero
  - rhcos4-audit-rules-dac-modification-chmod
  - rhcos4-audit-rules-dac-modification-chown
  - rhcos4-audit-rules-execution-chcon
  - rhcos4-audit-rules-execution-restorecon
  - rhcos4-audit-rules-execution-semanage
  - rhcos4-audit-rules-execution-setfiles
  - rhcos4-audit-rules-execution-setsebool
  - rhcos4-audit-rules-execution-seunshare
  - rhcos4-audit-rules-kernel-module-loading-delete
  - rhcos4-audit-rules-kernel-module-loading-finit
  - rhcos4-audit-rules-kernel-module-loading-init
  - rhcos4-audit-rules-login-events
  - rhcos4-audit-rules-login-events-faillock
  - rhcos4-audit-rules-login-events-lastlog
  - rhcos4-audit-rules-login-events-tallylog
  - rhcos4-audit-rules-networkconfig-modification
  - rhcos4-audit-rules-sysadmin-actions
  - rhcos4-audit-rules-time-adjtimex
  - rhcos4-audit-rules-time-clock-settime
  - rhcos4-audit-rules-time-settimeofday
  - rhcos4-audit-rules-time-stime
  - rhcos4-audit-rules-time-watch-localtime
  - rhcos4-audit-rules-usergroup-modification
  - rhcos4-auditd-data-retention-flush
  - rhcos4-auditd-freq
  - rhcos4-auditd-local-events
  - rhcos4-auditd-log-format
  - rhcos4-auditd-name-format
  - rhcos4-auditd-write-logs
  - rhcos4-configure-crypto-policy
  - rhcos4-configure-ssh-crypto-policy
  - rhcos4-no-empty-passwords
  - rhcos4-selinux-policytype
  - rhcos4-selinux-state
  - rhcos4-service-auditd-enabled
  - rhcos4-sshd-disable-empty-passwords
  - rhcos4-sshd-disable-gssapi-auth
  - rhcos4-sshd-disable-rhosts
  - rhcos4-sshd-disable-root-login
  - rhcos4-sshd-disable-user-known-hosts
  - rhcos4-sshd-do-not-permit-user-env
  - rhcos4-sshd-enable-strictmodes
  - rhcos4-sshd-print-last-log
  - rhcos4-sshd-set-loglevel-info
  - rhcos4-sysctl-kernel-dmesg-restrict
  - rhcos4-sysctl-kernel-kptr-restrict
  - rhcos4-sysctl-kernel-randomize-va-space
  - rhcos4-sysctl-kernel-unprivileged-bpf-disabled
  - rhcos4-sysctl-kernel-yama-ptrace-scope
  - rhcos4-sysctl-net-core-bpf-jit-harden
  title: Australian Cyber Security Centre (ACSC) Essential Eight

• 运行以下命令，以查看 rhcos4-audit-rules-login-events 规则的详情：

  $ oc get -n openshift-compliance -oyaml rules rhcos4-audit-rules-login-events

  例 5.2. 输出示例

  apiVersion: compliance.openshift.io/v1alpha1
  checkType: Node
  description: |-
    The audit system already collects login information for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix.rules in the directory /etc/audit/rules.d in order to watch for attempted manual edits of files involved in storing logon events:
  
    -w /var/log/tallylog -p wa -k logins
    -w /var/run/faillock -p wa -k logins
    -w /var/log/lastlog -p wa -k logins
  
    If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file in order to watch for unattempted manual edits of files involved in storing logon events:
  
    -w /var/log/tallylog -p wa -k logins
    -w /var/run/faillock -p wa -k logins
    -w /var/log/lastlog -p wa -k logins
  id: xccdf_org.ssgproject.content_rule_audit_rules_login_events
  kind: Rule
  metadata:
    annotations:
      compliance.openshift.io/image-digest: pb-rhcos4hrdkm
      compliance.openshift.io/rule: audit-rules-login-events
      control.compliance.openshift.io/NIST-800-53: AU-2(d);AU-12(c);AC-6(9);CM-6(a)
      control.compliance.openshift.io/PCI-DSS: Req-10.2.3
      policies.open-cluster-management.io/controls: AU-2(d),AU-12(c),AC-6(9),CM-6(a),Req-10.2.3
      policies.open-cluster-management.io/standards: NIST-800-53,PCI-DSS
    creationTimestamp: "2022-10-19T12:07:08Z"
    generation: 1
    labels:
      compliance.openshift.io/profile-bundle: rhcos4
    name: rhcos4-audit-rules-login-events
    namespace: openshift-compliance
    ownerReferences:
    - apiVersion: compliance.openshift.io/v1alpha1
      blockOwnerDeletion: true
      controller: true
      kind: ProfileBundle
      name: rhcos4
      uid: 22350850-af4a-4f5c-9a42-5e7b68b82d7d
    resourceVersion: "44819"
    uid: 75872f1f-3c93-40ca-a69d-44e5438824a4
  rationale: Manual editing of these files may indicate nefarious activity, such as
    an attacker attempting to remove evidence of an intrusion.
  severity: medium
  title: Record Attempts to Alter Logon and Logout Events
  warning: Manual editing of these files may indicate nefarious activity, such as an
    attacker attempting to remove evidence of an intrusion.

先决条件

• 您必须具有 admin 权限。
• 您必须配置了 StorageClass 资源。

先决条件

• 您必须具有 admin 权限。
• 您必须配置了 StorageClass 资源。

先决条件

• 您必须具有 admin 权限。
• 您必须配置了 StorageClass 资源。

先决条件

• 您必须具有 admin 权限。

• Red Hat OpenShift Container Platform Operator Update Information Checker

先决条件

• 之前使用 Operator Lifecycle Manager（OLM）安装的 Operator。

先决条件

• 之前使用 Operator Lifecycle Manager（OLM）安装的 Operator。

先决条件

• 使用具有 cluster-admin 权限的账户访问 OpenShift Container Platform 集群。
• 必须安装 OpenShift Compliance Operator。

先决条件

• 使用具有 cluster-admin 权限的账户访问 OpenShift Container Platform 集群。
• 必须安装 OpenShift Compliance Operator。

流程

• 为 Compliance Operator 创建 ScanSetting 自定义资源(CR)：

  1. 定义 ScanSetting CR，并保存 YAML 文件，如 rs-workers.yaml ：

     apiVersion: compliance.openshift.io/v1alpha1
     kind: ScanSetting
     metadata:
       name: rs-on-workers
       namespace: openshift-compliance
     rawResultStorage:
       nodeSelector:
         node-role.kubernetes.io/worker: "" 1
       pvAccessModes:
       - ReadWriteOnce
       rotation: 3
       size: 1Gi
       tolerations:
       - operator: Exists 2
     roles:
     - worker
     - master
     scanTolerations:
       - operator: Exists
     schedule: 0 1 * * *

     1

     Compliance Operator 使用此节点以 ARF 格式存储扫描结果。

     2

     结果服务器 pod 容限所有污点。

  2. 要创建 ScanSetting CR，请运行以下命令：

     $ oc create -f rs-workers.yaml

验证

• 要验证 ScanSetting 对象是否已创建，请运行以下命令：

  $ oc get scansettings rs-on-workers -n openshift-compliance -o yaml

  输出示例

  apiVersion: compliance.openshift.io/v1alpha1
  kind: ScanSetting
  metadata:
    creationTimestamp: "2021-11-19T19:36:36Z"
    generation: 1
    name: rs-on-workers
    namespace: openshift-compliance
    resourceVersion: "48305"
    uid: 43fdfc5f-15a7-445a-8bbc-0e4a160cd46e
  rawResultStorage:
    nodeSelector:
      node-role.kubernetes.io/worker: ""
    pvAccessModes:
    - ReadWriteOnce
    rotation: 3
    size: 1Gi
    tolerations:
    - operator: Exists
  roles:
  - worker
  - master
  scanTolerations:
  - operator: Exists
  schedule: 0 1 * * *
  strictNodeScan: true

先决条件

• Compliance Operator 安装在管理集群中。

• 节点扫描：扫描操作系统。
• 平台扫描：扫描 OpenShift Container Platform 配置。

流程

• 在 TailoredProfile 对象中设置以下注解：

验证

• 平台 KubeletConfig 规则通过 Node/Proxy 对象检查。您可以运行以下命令来查找这些规则：

  $ oc get rules -o json | jq '.items[] | select(.checkType == "Platform") | select(.metadata.name | contains("ocp4-kubelet-")) | .metadata.name'