支持控制台（Console）开发人员开始试用联系人

5.9. 管理 Compliance Operator 结果和补救

每个 ComplianceCheckResult 都代表一次合规性规则检查的结果。如果该规则可自动修复，则创建一个具有相同名称的 ComplianceRemediation 对象，由 ComplianceCheckResult 拥有。除非请求，否则不会自动应用补救，这使 OpenShift Container Platform 管理员有机会审阅补救的用途，且仅在验证后应用补救。

5.9.1. 过滤合规性检查结果

默认情况下，ComplianceCheckResult 对象使用几个有用的标签标记，允许您查询检查，并决定生成结果后的后续步骤。

列出属于特定套件的检查： 

$ oc get compliancecheckresults -l compliance.openshift.io/suite=example-compliancesuite

列出属于特定扫描的检查： 

$ oc get compliancecheckresults -l compliance.openshift.io/scan=example-compliancescan

不是所有的 ComplianceCheckResult 对象都会创建 ComplianceRemediation 对象。只有可自动修复的 ComplianceCheckResult 对象。如果 ComplianceCheckResult 对象带有 compliance.openshift.io/automated-remediation 标签，则该对象具有相关的补救。补救的名称与检查的名称相同。

列出可自动修复的所有失败检查： 

$ oc get compliancecheckresults -l 'compliance.openshift.io/check-status=FAIL,compliance.openshift.io/automated-remediation'

列出必须手动修复的所有失败检查： 

$ oc get compliancecheckresults -l 'compliance.openshift.io/check-status=FAIL,!compliance.openshift.io/automated-remediation'

手动补救步骤通常存储在 ComplianceCheckResult 对象的 description 属性中。

表 5.3. ComplianceCheckResult 状态
ComplianceCheckResult 状态描述

PASS

合规检查运行完成并通过。

FAIL

合规检查运行完并失败。

INFO

合规检查运行完毕，并发现一些不严重的、不被视为错误的问题。

手动

合规检查没有方法自动评估成功或失败，必须手动检查。

INCONSISTENT

合规检查报告来自不同来源的结果，通常是集群节点。

ERROR

合规性检查运行，但无法正确完成。

NOT-APPLICABLE

合规检查未运行，因为它不适用或未选中。

5.9.2. 审阅补救

审阅拥有补救的 ComplianceRemediation 对象和 ComplianceCheckResult 对象。ComplianceCheckResult 对象包含有关检查作用和试图避免的强化的人类可读描述，以及其他 metadata，如重要性和相关的安全控制。ComplianceRemediation 对象代表可以解决 ComplianceCheckResult 中描述的问题的一种方式。第一次扫描后，检查状态为 MissingDependencies 的补救。

下面是名为 sysctl-net-ipv4-conf-all-accept-redirects 的检查和补救示例。此示例经过修订，仅显示 spec 和 status，省略了 metadata： 

spec:
  apply: false
  current:
  object:
    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    spec:
      config:
        ignition:
          version: 3.2.0
        storage:
          files:
            - path: /etc/sysctl.d/75-sysctl_net_ipv4_conf_all_accept_redirects.conf
              mode: 0644
              contents:
                source: data:,net.ipv4.conf.all.accept_redirects%3D0
  outdated: {}
status:
  applicationState: NotApplied

补救有效负载存储在 spec.current 属性中。有效负载可以是任何 Kubernetes 对象，但因为此补救是通过节点扫描生成的，上例中的补救有效负载是 MachineConfig 对象。对于平台扫描，补救有效负载通常是其他类型的对象（如 ConfigMap 或 Secret），但是否应用这种补救通常取决于管理员，否则 Compliance Operator 需要一组非常广泛的权限才能操作任何通用 Kubernetes 对象。本文稍后会提供补救平台检查的示例。

要查看应用补救时的具体操作，MachineConfig 对象内容将使用 Ignition 对象进行配置。有关格式的更多信息，请参阅 Ignition 规格。在示例中，spec.config.storage.files[0].path 属性指定由该补救创建的文件 (/etc/sysctl.d/75-sysctl_net_ipv4_conf_all_accept_redirects.conf)，spec.config.storage.files[0].contents.source 属性指定该文件的内容。

注意

文件的内容是 URL 编码的。

使用以下 Python 脚本查看内容： 

$ echo "net.ipv4.conf.all.accept_redirects%3D0" | python3 -c "import sys, urllib.parse; print(urllib.parse.unquote(''.join(sys.stdin.readlines())))"

输出示例

net.ipv4.conf.all.accept_redirects=0

5.9.3. 使用自定义机器配置池时应用补救

当您创建自定义 MachineConfigPool 时，在 MachineConfigPool 中添加一个标签，以便 KubeletConfig 中的 machineConfigPoolSelector 可以与 MachineConfigPool 的标签匹配。

重要

不要在 KubeletConfig 文件中设置 protectKernelDefaults: false，因为 Compliance Operator 完成应用补救后，MachineConfigPool 对象可能无法意外暂停。

流程

  1. 列出节点。 

    $ oc get nodes

    输出示例

    NAME                                       STATUS  ROLES  AGE    VERSION
ip-10-0-128-92.us-east-2.compute.internal  Ready   master 5h21m  v1.23.3+d99c04f
ip-10-0-158-32.us-east-2.compute.internal  Ready   worker 5h17m  v1.23.3+d99c04f
ip-10-0-166-81.us-east-2.compute.internal  Ready   worker 5h17m  v1.23.3+d99c04f
ip-10-0-171-170.us-east-2.compute.internal Ready   master 5h21m  v1.23.3+d99c04f
ip-10-0-197-35.us-east-2.compute.internal  Ready   master 5h22m  v1.23.3+d99c04f

  2. 为节点添加标签。 

    $ oc label node ip-10-0-166-81.us-east-2.compute.internal node-role.kubernetes.io/<machine_config_pool_name>=

    输出示例

    node/ip-10-0-166-81.us-east-2.compute.internal labeled

  3. 创建自定义 MachineConfigPool CR。 

    apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  name: <machine_config_pool_name>
  labels:
    pools.operator.machineconfiguration.openshift.io/<machine_config_pool_name>: '' 1
spec:
  machineConfigSelector:
  matchExpressions:
  - {key: machineconfiguration.openshift.io/role, operator: In, values: [worker,<machine_config_pool_name>]}
  nodeSelector:
  matchLabels:
    node-role.kubernetes.io/<machine_config_pool_name>: ""
    1
    labels 字段定义要为机器配置池(MCP)添加的标签名称。

  4. 验证 MCP 是否已成功创建。 

    $ oc get mcp -w

5.9.4. 应用补救

布尔值属性 spec.apply 控制 Compliance Operator 是否应该应用补救。您可以通过将属性设置为 true 来应用补救： 

$ oc patch complianceremediations/<scan_name>-sysctl-net-ipv4-conf-all-accept-redirects --patch '{"spec":{"apply":true}}' --type=merge

在 Compliance Operator 处理应用的补救后，status.ApplicationState 属性会更改为 Applied 或在出错时更改为 Error。应用机器配置补救时，该补救与其他应用的补救一起渲染为名为 75-$scan-name-$suite-name 的 MachineConfig 对象。MachineConfig 对象随后由 Machine Config Operator 渲染，最终由在每个节点上运行的机器控制守护进程实例应用到机器配置池中的所有节点。

请注意，当 MachineConfigOperator 将新的 MachineConfig 对象应用到池中的节点时，属于池的所有节点都会重启。应用多个补救时，这可能会不方便，每个补救都会重新渲染组合 75-$scan-name-$suite-name MachineConfig 对象。要防止立即应用补救，您可以通过将 MachineConfigPool 对象的 .spec.paused 属性设置为 true 来暂停机器配置池。

Compliance Operator 可以自动应用补救。在 ScanSetting 顶层对象中设置 autoApplyRemediations: true。

警告

只有经过仔细考虑才能自动应用补救。

5.9.5. 手动补救平台检查

检查平台扫描通常必须由管理员手动修复，原因有两个：

  • 并不总是能够自动决定必须设置的值。其中一项检查要求提供允许的 registry 列表，但扫描程序并不知道组织要允许哪些 registry。
  • 不同的检查会修改不同的 API 对象，需要自动补救以拥有 root 或超级用户访问权限来修改集群中的对象，但不建议这样做。

流程

  1. 以下示例使用 ocp4-ocp-allowed-registries-for-import 规则，这在默认 OpenShift Container Platform 安装中会失败。检查规则 oc get rule. compliance/ocp4-ocp-allowed-registries-for-import -oyaml，该规则通过设置 allowedRegistriesForImport 属性来限制允许用户从中导入镜像的 registry，该规则的 warning 属性还会显示已检查的 API 对象，因此可以修改它并修复问题： 

    $ oc edit image.config.openshift.io/cluster

    输出示例

    apiVersion: config.openshift.io/v1
kind: Image
metadata:
  annotations:
    release.openshift.io/create-only: "true"
  creationTimestamp: "2020-09-10T10:12:54Z"
  generation: 2
  name: cluster
  resourceVersion: "363096"
  selfLink: /apis/config.openshift.io/v1/images/cluster
  uid: 2dcb614e-2f8a-4a23-ba9a-8e33cd0ff77e
spec:
  allowedRegistriesForImport:
  - domainName: registry.redhat.io
status:
  externalRegistryHostnames:
  - default-route-openshift-image-registry.apps.user-cluster-09-10-12-07.devcluster.openshift.com
  internalRegistryHostname: image-registry.openshift-image-registry.svc:5000

  2. 重新运行扫描： 

    $ oc annotate compliancescans/<scan_name> compliance.openshift.io/rescan=

5.9.6. 更新补救

使用新版本的合规性内容时，可能会提供与之前版本不同的新补救版本。Compliance Operator 将保留应用的旧版本补救。OpenShift Container Platform 管理员还收到要审核和应用的新版本通知。之前应用的 ComplianceRemediation 对象已更新，它的状态已更改为 Outdated。过时的对象已标识，因此可轻松搜索。

以前应用的补救内容将存储在 ComplianceRemediation 对象的 spec.outdated 属性中，新的更新内容将存储在 spec.current 属性中。将内容更新至新版本后，管理员需要审查补救。只要 spec.outdated 属性存在，它将用来渲染生成的 MachineConfig 对象。删除 spec.outdated 属性后，Compliance Operator 会重新渲染生成的 MachineConfig 对象，导致 Operator 将配置推送到节点。

流程

  1. 搜索任何过时的补救： 

    $ oc get complianceremediations -lcomplianceoperator.openshift.io/outdated-remediation=

    输出示例

    NAME                              STATE
workers-scan-no-empty-passwords   Outdated

    当前应用的补救存储在 Outdated 属性中，未应用的新补救存储在 Current 属性中。如果您对新版本满意，可删除 Outdated 字段。如果要保留更新的内容，可删除 Current 和 Outdated 属性。

  2. 应用更新的补救版本： 

    $ oc patch complianceremediations workers-scan-no-empty-passwords --type json -p '[{"op":"remove", "path":/spec/outdated}]'

  3. 补救状态将从 Outdated 切换为 Applied： 

    $ oc get complianceremediations workers-scan-no-empty-passwords

    输出示例

    NAME                              STATE
workers-scan-no-empty-passwords   Applied

  4. 节点将应用更新的补救版本并重新引导。

5.9.7. 取消应用补救

可能需要取消应用之前应用的补救。

流程

  1. 将 apply 标志设置为 false ： 

    $ oc patch complianceremediations/<scan_name>-sysctl-net-ipv4-conf-all-accept-redirects -p '{"spec":{"apply":false}}' --type=merge

  2. 补救状态将更改为 NotApplied，组合 MachineConfig 对象会被重新渲染，不包含补救。

    重要

    所有包含补救的受影响节点都将被重新引导。

5.9.8. 删除 KubeletConfig 补救

KubeletConfig 补救包括在节点级别的配置集中。要删除 KubeletConfig 补救，您必须手动将其从 KubeletConfig 对象中删除。本例演示了如何删除 one-rule-tp-node-master-kubelet-eviction-thresholds-set-hard-imagefs-available 补救的合规性检查。

流程

  1. 找到 one-rule-tp-node-master-kubelet-eviction-thresholds-set-hard-imagefs-available 补救的 scan-name 和合规检查： 

    $ oc get remediation one-rule-tp-node-master-kubelet-eviction-thresholds-set-hard-imagefs-available -o yaml

    输出示例

    apiVersion: compliance.openshift.io/v1alpha1
kind: ComplianceRemediation
metadata:
  annotations:
    compliance.openshift.io/xccdf-value-used: var-kubelet-evictionhard-imagefs-available
  creationTimestamp: "2022-01-05T19:52:27Z"
  generation: 1
  labels:
    compliance.openshift.io/scan-name: one-rule-tp-node-master 1
    compliance.openshift.io/suite: one-rule-ssb-node
  name: one-rule-tp-node-master-kubelet-eviction-thresholds-set-hard-imagefs-available
  namespace: openshift-compliance
  ownerReferences:
  - apiVersion: compliance.openshift.io/v1alpha1
    blockOwnerDeletion: true
    controller: true
    kind: ComplianceCheckResult
    name: one-rule-tp-node-master-kubelet-eviction-thresholds-set-hard-imagefs-available
    uid: fe8e1577-9060-4c59-95b2-3e2c51709adc
  resourceVersion: "84820"
  uid: 5339d21a-24d7-40cb-84d2-7a2ebb015355
spec:
  apply: true
  current:
    object:
      apiVersion: machineconfiguration.openshift.io/v1
      kind: KubeletConfig
      spec:
        kubeletConfig:
          evictionHard:
            imagefs.available: 10% 2
  outdated: {}
  type: Configuration
status:
  applicationState: Applied

    1
    补救的扫描名称。
    2
    添加到 KubeletConfig 对象的补救。
    注意

    如果补救调用 evictionHard kubelet 配置，您必须指定所有 evictionHard 参数： memory.available、nodefs.available、nodefs.inodesFree、imagefs.available 和 imagefs.inodesFree。如果没有指定所有参数，则只应用指定的参数，补救无法正常工作。

  2. 删除补救：

    1. 为补救对象将 apply 设置为 false： 

      $ oc patch complianceremediations/one-rule-tp-node-master-kubelet-eviction-thresholds-set-hard-imagefs-available -p '{"spec":{"apply":false}}' --type=merge

    2. 使用 scan-name，找到补救应用到的 KubeletConfig 对象： 

      $ oc get kubeletconfig --selector compliance.openshift.io/scan-name=one-rule-tp-node-master

      输出示例

      NAME                                 AGE
compliance-operator-kubelet-master   2m34s

    3. 从 KubeletConfig 对象手动删除补救 imagefs.available: 10% ： 

      $ oc edit KubeletConfig compliance-operator-kubelet-master
      重要

      所有包含补救的受影响节点都将被重新引导。

注意

您还必须在定制的配置集中排除任何调度的扫描规则，这些配置集自动应用补救，否则会在下一次调度的扫描过程中重新应用补救。

5.9.9. Inconsistent ComplianceScan

ScanSetting 对象列出了合规性扫描从 ScanSetting 或 ScanSettingBinding 对象扫描的节点角色。每个节点角色通常映射到机器配置池。

重要

机器配置池中的所有机器都应该相同，池中节点的所有扫描结果都应该相同。

如果某些结果与其他结果不同，Compliance Operator 将标记一些节点将报告为 INCONSISTENT 的 ComplianceCheckResult 对象。所有 ComplianceCheckResult 对象也都标有 compliance.openshift.io/inconsistent-check。

因为池中的机器数量可能非常大，所以 Compliance Operator 会尝试找到最常用的状态，并列出与常见状态不同的节点。最常见的状态存储在 compliance.openshift.io/most-common-status 注解中，注解 compliance.openshift.io/inconsistent-source 包含与最常见状态不同的 hostname:status 检查状态对。如果没有找到常见状态，则所有 hostname:status 对都列在 compliance.openshift.io/inconsistent-source annotation 中。

如果可能，仍会创建补救，以便集群可以整合到兼容状态。但是，并非总是能够创建补救，必须手动纠正节点之间的差异。必须使用 compliance.openshift.io/rescan= 选项为扫描添加注解来重新运行合规性扫描，以得到一致的结果： 

$ oc annotate compliancescans/<scan_name> compliance.openshift.io/rescan=

5.9.10. 其他资源

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

© 2024 Red Hat, Inc.