管理 Compliance Operator 补救措施 - Compliance Operator | 安全和合规 | OpenShift Container Platform 4.17

合规性检查结果过滤器
审查补救措施
在使用自定义机器配置池时应用补救措施
根据默认配置值评估KubeletConfig规则
扫描自定义节点池
补救KubeletConfig子池
应用补救措施
手动补救平台检查
更新补救措施
取消应用补救措施
删除KubeletConfig补救措施
不一致的ComplianceScan
其他资源

每个ComplianceCheckResult代表一个合规性规则检查的结果。如果该规则可以自动补救，则会创建一个与ComplianceCheckResult同名、由其拥有的ComplianceRemediation对象。除非请求，否则不会自动应用补救措施，这使OpenShift Container Platform管理员有机会审查补救措施的作用，并且只有在验证后才应用补救措施。

要完全满足联邦信息处理标准 (FIPS) 合规性，需要为集群启用 FIPS 模式。要启用 FIPS 模式，必须从配置为在 FIPS 模式下运行的 Red Hat Enterprise Linux (RHEL) 计算机运行安装程序。有关在 RHEL 上配置 FIPS 模式的更多信息，请参见在 FIPS 模式下安装系统。

FIPS模式支持以下架构

x86_64
ppc64le
s390x

合规性检查结果过滤器

默认情况下，ComplianceCheckResult对象使用多个有用的标签进行标记，这些标签允许您查询检查并在生成结果后确定后续步骤。

列出属于特定套件的检查

$ oc get -n openshift-compliance compliancecheckresults \
  -l compliance.openshift.io/suite=workers-compliancesuite

列出属于特定扫描的检查

$ oc get -n openshift-compliance compliancecheckresults \
-l compliance.openshift.io/scan=workers-scan

并非所有ComplianceCheckResult对象都会创建ComplianceRemediation对象。只有可以自动补救的ComplianceCheckResult对象才会创建。如果ComplianceCheckResult对象标有compliance.openshift.io/automated-remediation标签，则它具有相关的补救措施。补救措施的名称与检查的名称相同。

列出所有可以自动补救的失败检查

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

列出按严重性排序的所有失败检查

$ oc get compliancecheckresults -n openshift-compliance \
-l 'compliance.openshift.io/check-status=FAIL,compliance.openshift.io/check-severity=high'

示例输出

NAME                                                           STATUS   SEVERITY
nist-moderate-modified-master-configure-crypto-policy          FAIL     high
nist-moderate-modified-master-coreos-pti-kernel-argument       FAIL     high
nist-moderate-modified-master-disable-ctrlaltdel-burstaction   FAIL     high
nist-moderate-modified-master-disable-ctrlaltdel-reboot        FAIL     high
nist-moderate-modified-master-enable-fips-mode                 FAIL     high
nist-moderate-modified-master-no-empty-passwords               FAIL     high
nist-moderate-modified-master-selinux-state                    FAIL     high
nist-moderate-modified-worker-configure-crypto-policy          FAIL     high
nist-moderate-modified-worker-coreos-pti-kernel-argument       FAIL     high
nist-moderate-modified-worker-disable-ctrlaltdel-burstaction   FAIL     high
nist-moderate-modified-worker-disable-ctrlaltdel-reboot        FAIL     high
nist-moderate-modified-worker-enable-fips-mode                 FAIL     high
nist-moderate-modified-worker-no-empty-passwords               FAIL     high
nist-moderate-modified-worker-selinux-state                    FAIL     high
ocp4-moderate-configure-network-policies-namespaces            FAIL     high
ocp4-moderate-fips-mode-enabled-on-all-nodes                   FAIL     high

列出所有必须手动补救的失败检查

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

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

表1. ComplianceCheckResult状态
ComplianceCheckResult状态	描述
PASS	合规性检查已完成并通过。
FAIL	合规性检查已完成并失败。
INFO	合规性检查已完成，但发现的内容不足以被视为错误。
MANUAL	合规性检查无法自动评估成功或失败，必须手动检查。
INCONSISTENT	合规性检查报告来自不同来源（通常是集群节点）的不同结果。
ERROR	合规性检查已运行，但无法正常完成。
NOT-APPLICABLE	合规性检查未运行，因为它不适用或未选中。

审查补救措施

审查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对象），但通常情况下，应用该修复由管理员负责，因为否则合规性操作员将需要非常广泛的权限来操作任何通用的 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

合规性操作员不会自动解决修复之间可能出现的依赖性问题。应用修复后，用户应执行重新扫描以确保结果准确。

使用自定义 Machine Config 池时应用修复

创建自定义MachineConfigPool时，请向MachineConfigPool添加标签，以便KubeletConfig中存在的machineConfigPoolSelector可以将标签与MachineConfigPool匹配。

请勿在KubeletConfig文件中设置protectKernelDefaults: false，因为在合规性操作员完成应用修复后，MachineConfigPool对象可能会意外失败并取消暂停。

步骤

列出节点。

$ oc get nodes -n openshift-compliance

示例输出

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

向节点添加标签。

$ oc -n openshift-compliance \
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

创建自定义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`字段定义要为 Machine Config 池 (MCP) 添加的标签名称。

验证 MCP 是否已成功创建。
```
$ oc get mcp -w
```

根据默认配置值评估 KubeletConfig 规则

OpenShift Container Platform 基础设施在运行时可能包含不完整的配置文件，并且节点会为缺少的配置选项采用默认配置值。某些配置选项可以作为命令行参数传递。因此，合规性操作员无法验证节点上的配置文件是否完整，因为它可能缺少规则检查中使用的选项。

为了防止默认配置值通过检查导致误报，合规性操作员使用 Node/Proxy API 获取节点池中每个节点的配置，然后将节点池中所有节点之间一致的所有配置选项存储在一个文件中，该文件表示该节点池中所有节点的配置。这提高了扫描结果的准确性。

对于默认的master和worker节点池配置，无需进行其他配置更改即可使用此功能。

扫描自定义节点池

合规性操作员不会维护每个节点池配置的副本。合规性操作员将单个节点池中所有节点的一致配置选项聚合到一个配置文件的副本中。然后，合规性操作员使用特定节点池的配置文件来根据该池中的节点评估规则。

步骤

将example角色添加到将存储在ScanSettingBinding CR中的ScanSetting对象中。

apiVersion: compliance.openshift.io/v1alpha1
kind: ScanSetting
metadata:
  name: default
  namespace: openshift-compliance
rawResultStorage:
  rotation: 3
  size: 1Gi
roles:
- worker
- master
- example
scanTolerations:
- effect: NoSchedule
  key: node-role.kubernetes.io/master
  operator: Exists
schedule: '0 1 * * *'

创建使用ScanSettingBinding CR的扫描。

apiVersion: compliance.openshift.io/v1alpha1
kind: ScanSettingBinding
metadata:
  name: cis
  namespace: openshift-compliance
profiles:
- apiGroup: compliance.openshift.io/v1alpha1
  kind: Profile
  name: ocp4-cis
- apiGroup: compliance.openshift.io/v1alpha1
  kind: Profile
  name: ocp4-cis-node
settingsRef:
  apiGroup: compliance.openshift.io/v1alpha1
  kind: ScanSetting
  name: default

验证

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

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

修复`KubeletConfig`子池

KubeletConfig修复标签可以应用于MachineConfigPool子池。

步骤

向子池MachineConfigPool CR添加标签

$ oc label mcp <sub-pool-name> pools.operator.machineconfiguration.openshift.io/<sub-pool-name>=

应用修复

布尔属性spec.apply控制合规性操作员是否应应用修复。您可以通过将属性设置为true来应用修复。

$ oc -n openshift-compliance \
patch complianceremediations/<scan-name>-sysctl-net-ipv4-conf-all-accept-redirects \
--patch '{"spec":{"apply":true}}' --type=merge

合规性操作员处理应用的修复后，status.ApplicationState属性将更改为**已应用**，如果错误则更改为**错误**。应用机器配置修复后，该修复以及所有其他应用的修复将呈现到名为75-$scan-name-$suite-name的MachineConfig对象中。该MachineConfig对象随后由 Machine Config 操作员呈现，最后由在每个节点上运行的机器控制守护程序实例应用于机器配置池中的所有节点。

请注意，当 Machine Config 操作员将新的MachineConfig对象应用于池中的节点时，池中的所有节点都将重新引导。在应用多个修复程序时，这可能会很不方便，因为每个修复程序都会重新呈现组合的75-$scan-name-$suite-name MachineConfig对象。为了防止立即应用修复，您可以通过将MachineConfigPool对象的.spec.paused属性设置为true来暂停机器配置池。

合规性操作员可以自动应用修复。在ScanSetting顶级对象中设置autoApplyRemediations: true。

仅应仔细考虑后才能自动应用修复。

合规性操作员不会自动解决修复之间可能出现的依赖性问题。应用修复后，用户应执行重新扫描以确保结果准确。

手动修复平台检查

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

并非总是能够自动确定必须设置的值。其中一项检查要求提供允许的注册表列表，但扫描程序无法知道组织想要允许哪些注册表。
不同的检查修改不同的 API 对象，这需要自动修复来拥有root或超级用户访问权限才能修改集群中的对象，这并不建议。

步骤

以下示例使用ocp4-ocp-allowed-registries-for-import规则，该规则在默认的 OpenShift Container Platform 安装上将失败。检查规则oc get rule.compliance/ocp4-ocp-allowed-registries-for-import -oyaml，该规则旨在通过设置allowedRegistriesForImport属性来限制用户允许从中导入镜像的注册表。规则的警告属性还显示了检查的 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

重新运行扫描。

$ oc -n openshift-compliance \
annotate compliancescans/rhcos4-e8-worker compliance.openshift.io/rescan=

更新修复

使用新版本的合规性内容时，它可能会提供与以前版本不同的新版本修复。合规性操作员将保留已应用的旧版本修复。OpenShift Container Platform 管理员还会收到新版本的通知，以便进行审核和应用。之前已应用但已更新的 ComplianceRemediation 对象会将其状态更改为**已过期**。已过期的对象已标记，以便可以轻松搜索它们。

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

步骤

搜索任何过时的修复
```
$ oc -n openshift-compliance get complianceremediations \
-l complianceoperator.openshift.io/outdated-remediation=
```
示例输出
```
NAME                              STATE
workers-scan-no-empty-passwords   Outdated
```
当前应用的修复存储在Outdated属性中，新的未应用的修复存储在Current属性中。如果您对新版本满意，请删除Outdated字段。如果您想保留更新的内容，请删除Current和Outdated属性。

应用修复的新版本

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

修复状态将从Outdated切换到Applied

$ oc get -n openshift-compliance complianceremediations workers-scan-no-empty-passwords

示例输出

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

节点将应用新的修复版本并重新启动。

合规性操作员不会自动解决修复之间可能出现的依赖性问题。应用修复后，用户应执行重新扫描以确保结果准确。

取消应用修复

可能需要取消先前应用的修复。

步骤

将apply标志设置为false

$ oc -n openshift-compliance \
patch complianceremediations/rhcos4-moderate-worker-sysctl-net-ipv4-conf-all-accept-redirects \
--patch '{"spec":{"apply":false}}' --type=merge

修复状态将更改为NotApplied，并且组合的MachineConfig对象将被重新渲染以不包含该修复。

所有应用了该修复的受影响节点都将重新启动。

合规性操作员不会自动解决修复之间可能出现的依赖性问题。应用修复后，用户应执行重新扫描以确保结果准确。

删除KubeletConfig修复

KubeletConfig修复包含在节点级配置文件中。要删除KubeletConfig修复，必须手动将其从KubeletConfig对象中删除。此示例演示如何删除one-rule-tp-node-master-kubelet-eviction-thresholds-set-hard-imagefs-available修复的合规性检查。

步骤

找到one-rule-tp-node-master-kubelet-eviction-thresholds-set-hard-imagefs-available修复的scan-name和合规性检查

$ oc -n openshift-compliance 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。如果不指定所有参数，则只应用指定的参数，修复将无法正常工作。

删除修复

将修复对象的apply设置为false

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

使用scan-name查找应用了修复的KubeletConfig对象

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

示例输出

NAME                                 AGE
compliance-operator-kubelet-master   2m34s

手动从KubeletConfig对象中删除修复imagefs.available: 10%。
```
$ oc edit -n openshift-compliance KubeletConfig compliance-operator-kubelet-master
```
所有应用了该修复的受影响节点都将重新启动。

还必须从任何自定义配置文件中排除该规则，这些配置文件会自动应用该修复，否则，该修复将在下次计划扫描期间重新应用。

不一致的ComplianceScan

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

预期机器配置池中的所有机器都相同，并且来自池中节点的所有扫描结果都应相同。

如果某些结果与其他结果不同，则Compliance Operator 将标记一个ComplianceCheckResult对象，其中一些节点将报告为INCONSISTENT。所有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注释中。

如果可能，仍然会创建修复程序，以便集群可以收敛到合规状态。但是，这并非总是可能的，必须手动纠正节点之间的差异。必须使用compliance.openshift.io/rescan=选项对扫描进行注释，以重新运行合规性扫描以获得一致的结果。

$ oc -n openshift-compliance \
annotate compliancescans/rhcos4-e8-worker compliance.openshift.io/rescan=

其他资源

修改节点.

管理合规性操作员结果和补救措施

合规性检查结果过滤器

审查补救措施

使用自定义 Machine Config 池时应用修复

根据默认配置值评估 KubeletConfig 规则

扫描自定义节点池

修复KubeletConfig子池

应用修复

手动修复平台检查

更新修复

取消应用修复

删除KubeletConfig修复

不一致的ComplianceScan

其他资源

修复`KubeletConfig`子池