执行高级 Compliance Operator 任务 - Compliance Operator | 安全和合规性 | OpenShift Container Platform 4.17

直接使用 ComplianceSuite 和 ComplianceScan 对象
为 `ScanSetting` 扫描设置 `PriorityClass`
使用原始定制配置文件
执行重新扫描
为结果设置自定义存储大小
- 使用自定义结果存储值
应用套件扫描生成的补救措施
自动更新补救措施
为 Compliance Operator 创建自定义 SCC
其他资源

Compliance Operator 包含供高级用户用于调试或与现有工具集成的选项。

直接使用 ComplianceSuite 和 ComplianceScan 对象

建议用户利用 `ScanSetting` 和 `ScanSettingBinding` 对象来定义套件和扫描，但也有一些有效的用例需要直接定义 `ComplianceSuite` 对象。

仅指定单个规则进行扫描。这对于结合 `debug: true` 属性（它会增加 OpenSCAP 扫描器的详细程度）进行调试非常有用，因为调试模式往往会变得非常冗长。将测试限制在一个规则有助于减少调试信息的数量。
提供自定义 nodeSelector。为了使补救措施适用，nodeSelector 必须与一个池匹配。
将扫描指向包含定制文件的专用 ConfigMap。
在测试或开发过程中，不需要从包中解析配置文件的开销。

以下示例显示一个 `ComplianceSuite`，它只使用单个规则扫描工作机器。

apiVersion: compliance.openshift.io/v1alpha1
kind: ComplianceSuite
metadata:
  name: workers-compliancesuite
spec:
  scans:
    - name: workers-scan
      profile: xccdf_org.ssgproject.content_profile_moderate
      content: ssg-rhcos4-ds.xml
      contentImage: registry.redhat.io/compliance/openshift-compliance-content-rhel8@sha256:45dc...
      debug: true
      rule: xccdf_org.ssgproject.content_rule_no_direct_root_logins
      nodeSelector:
      node-role.kubernetes.io/worker: ""

上面提到的 `ComplianceSuite` 对象和 `ComplianceScan` 对象以 OpenSCAP 预期的格式指定了多个属性。

要查找配置文件、内容或规则值，您可以首先从 `ScanSetting` 和 `ScanSettingBinding` 创建类似的套件，或者检查从 `ProfileBundle` 对象（如规则或配置文件）解析的对象。这些对象包含您可以从 `ComplianceSuite` 中引用它们的 `xccdf_org` 标识符。

为 `ScanSetting` 扫描设置 `PriorityClass`

在大规模环境中，默认的 `PriorityClass` 对象可能太低，无法保证 Pod 按时执行扫描。对于必须保持合规性或保证自动扫描的集群，建议设置 `PriorityClass` 变量，以确保在资源受限的情况下始终优先考虑 Compliance Operator。

步骤

设置 `PriorityClass` 变量

apiVersion: compliance.openshift.io/v1alpha1
strictNodeScan: true
metadata:
  name: default
  namespace: openshift-compliance
priorityClass: compliance-high-priority (1)
kind: ScanSetting
showNotApplicable: false
rawResultStorage:
  nodeSelector:
    node-role.kubernetes.io/master: ''
  pvAccessModes:
    - ReadWriteOnce
  rotation: 3
  size: 1Gi
  tolerations:
    - effect: NoSchedule
      key: node-role.kubernetes.io/master
      operator: Exists
    - effect: NoExecute
      key: node.kubernetes.io/not-ready
      operator: Exists
      tolerationSeconds: 300
    - effect: NoExecute
      key: node.kubernetes.io/unreachable
      operator: Exists
      tolerationSeconds: 300
    - effect: NoSchedule
      key: node.kubernetes.io/memory-pressure
      operator: Exists
schedule: 0 1 * * *
roles:
  - master
  - worker
scanTolerations:
  - operator: Exists

1	如果找不到 `ScanSetting` 中引用的 `PriorityClass`，则 Operator 将使 `PriorityClass` 保持为空，发出警告，并继续在没有 `PriorityClass` 的情况下调度扫描。

使用原始定制配置文件

`TailoredProfile` CR 启用了最常见的定制操作，但 XCCDF 标准允许在定制 OpenSCAP 配置文件方面具有更大的灵活性。此外，如果您的组织以前使用过 OpenScap，您可能已经有现有的 XCCDF 定制文件，并且可以重复使用它。

`ComplianceSuite` 对象包含一个可选的 `TailoringConfigMap` 属性，您可以将其指向自定义定制文件。`TailoringConfigMap` 属性的值是一个 ConfigMap 的名称，该 ConfigMap 必须包含一个名为 `tailoring.xml` 的键，该键的值是定制内容。

步骤

从文件创建 `ConfigMap` 对象

$ oc -n openshift-compliance \
create configmap nist-moderate-modified \
--from-file=tailoring.xml=/path/to/the/tailoringFile.xml

在属于套件的扫描中引用定制文件

apiVersion: compliance.openshift.io/v1alpha1
kind: ComplianceSuite
metadata:
  name: workers-compliancesuite
spec:
  debug: true
  scans:
    - name: workers-scan
      profile: xccdf_org.ssgproject.content_profile_moderate
      content: ssg-rhcos4-ds.xml
      contentImage: registry.redhat.io/compliance/openshift-compliance-content-rhel8@sha256:45dc...
      debug: true
  tailoringConfigMap:
      name: nist-moderate-modified
  nodeSelector:
    node-role.kubernetes.io/worker: ""

执行重新扫描

通常，您希望按定义的时间表重新运行扫描，例如每周一或每天。在修复节点上的问题后，重新运行一次扫描也很有用。要执行单次扫描，请使用 `compliance.openshift.io/rescan=` 选项为扫描添加注释。

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

重新扫描会为 `rhcos-moderate` 配置文件生成四个额外的 `mc`。

$ oc get mc

示例输出

75-worker-scan-chronyd-or-ntpd-specify-remote-server
75-worker-scan-configure-usbguard-auditbackend
75-worker-scan-service-usbguard-enabled
75-worker-scan-usbguard-allow-hid-and-hub

当应用扫描设置default-auto-apply标签时，补救措施会自动应用，过时的补救措施会自动更新。如果由于依赖关系而未应用补救措施，或补救措施已过期，则重新扫描会应用补救措施并可能触发重新引导。只有使用MachineConfig对象的补救措施才会触发重新引导。如果没有要应用的更新或依赖关系，则不会发生重新引导。

设置自定义结果存储大小

虽然诸如ComplianceCheckResult之类的自定义资源代表了对所有已扫描节点的一次检查的聚合结果，但查看扫描程序生成的原始结果可能很有用。原始结果以ARF格式生成，可能很大（每个节点数十兆字节），将其存储在由etcd键值存储支持的Kubernetes资源中是不切实际的。取而代之的是，每次扫描都会创建一个持久卷 (PV)，其默认大小为 1GB。根据您的环境，您可能需要相应地增加 PV 大小。这是使用在ScanSetting和ComplianceScan资源中公开的rawResultStorage.size属性完成的。

相关的参数是rawResultStorage.rotation，它控制在旋转较旧的扫描之前在 PV 中保留多少次扫描。默认值为 3，将旋转策略设置为 0 将禁用旋转。鉴于默认旋转策略和每个原始 ARF 扫描报告约 100MB 的估算值，您可以计算出适合您环境的正确 PV 大小。

使用自定义结果存储值

因为OpenShift Container Platform可以部署在各种公有云或裸机上，所以Compliance Operator无法确定可用的存储配置。默认情况下，Compliance Operator将尝试使用集群的默认存储类创建用于存储结果的PV，但是可以使用rawResultStorage.StorageClassName属性配置自定义存储类。

如果您的集群未指定默认存储类，则必须设置此属性。

配置ScanSetting自定义资源以使用标准存储类并创建大小为 10GB 并保留最后 10 个结果的持久卷。

ScanSetting CR 示例

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

应用套件扫描生成的补救措施

虽然您可以在ComplianceSuite对象中使用autoApplyRemediations布尔参数，但您也可以使用compliance.openshift.io/apply-remediations注释该对象。这允许Operator应用所有已创建的补救措施。

步骤

通过运行以下命令应用compliance.openshift.io/apply-remediations注释

$ oc -n openshift-compliance \
annotate compliancesuites/workers-compliancesuite compliance.openshift.io/apply-remediations=

自动更新补救措施

在某些情况下，包含较新内容的扫描可能会将补救措施标记为OUTDATED。作为管理员，您可以应用compliance.openshift.io/remove-outdated注释以应用新的补救措施并删除过时的补救措施。

步骤

应用compliance.openshift.io/remove-outdated注释

$ oc -n openshift-compliance \
annotate compliancesuites/workers-compliancesuite compliance.openshift.io/remove-outdated=

或者，在ScanSetting或ComplianceSuite对象中设置autoUpdateRemediations标志以自动更新补救措施。

为Compliance Operator创建自定义SCC

在某些环境中，您必须创建一个自定义安全上下文约束 (SCC) 文件，以确保Compliance Operator api-resource-collector具有正确的权限。

先决条件

您必须具有admin权限。

步骤

在名为restricted-adjusted-compliance.yaml的YAML文件中定义SCC。

SecurityContextConstraints对象定义

  allowHostDirVolumePlugin: false
  allowHostIPC: false
  allowHostNetwork: false
  allowHostPID: false
  allowHostPorts: false
  allowPrivilegeEscalation: true
  allowPrivilegedContainer: false
  allowedCapabilities: null
  apiVersion: security.openshift.io/v1
  defaultAddCapabilities: null
  fsGroup:
    type: MustRunAs
  kind: SecurityContextConstraints
  metadata:
    name: restricted-adjusted-compliance
  priority: 30 (1)
  readOnlyRootFilesystem: false
  requiredDropCapabilities:
  - KILL
  - SETUID
  - SETGID
  - MKNOD
  runAsUser:
    type: MustRunAsRange
  seLinuxContext:
    type: MustRunAs
  supplementalGroups:
    type: RunAsAny
  users:
  - system:serviceaccount:openshift-compliance:api-resource-collector (2)
  volumes:
  - configMap
  - downwardAPI
  - emptyDir
  - persistentVolumeClaim
  - projected
  - secret

1	此 SCC 的优先级必须高于应用于`system:authenticated`组的任何其他 SCC。
2	Compliance Operator Scanner pod使用的服务帐户。

创建SCC

$ oc create -n openshift-compliance  -f restricted-adjusted-compliance.yaml

示例输出

securitycontextconstraints.security.openshift.io/restricted-adjusted-compliance created

验证

验证SCC是否已创建

$ oc get -n openshift-compliance scc restricted-adjusted-compliance

示例输出

NAME                             PRIV    CAPS         SELINUX     RUNASUSER        FSGROUP     SUPGROUP   PRIORITY   READONLYROOTFS   VOLUMES
restricted-adjusted-compliance   false   <no value>   MustRunAs   MustRunAsRange   MustRunAs   RunAsAny   30         false            ["configMap","downwardAPI","emptyDir","persistentVolumeClaim","projected","secret"]

其他资源

管理安全上下文约束