5.14. 使用 oc-compliance 插件

虽然 Compliance Operator 为集群自动执行许多检查和补救，但将集群设置为合规的完整过程通常需要管理员与 Compliance Operator API 和其他组件交互。oc-compliance 插件使进程变得更加容易。

5.14.1. 安装 oc-compliance 插件

流程

  1. 提取 oc-compliance 镜像以获取 oc-compliance 二进制文件： 

    $ podman run --rm -v ~/.local/bin:/mnt/out:Z registry.redhat.io/compliance/oc-compliance-rhel8:stable /bin/cp /usr/bin/oc-compliance /mnt/out/

    输出示例

    W0611 20:35:46.486903   11354 manifest.go:440] Chose linux/amd64 manifest from the manifest list.

    现在，您可以运行 oc-compliance。

5.14.2. 获取原始结果

当合规性扫描完成后，生成的 ComplianceCheckResult 自定义资源（CR）中会列出单个检查的结果。但是，管理员或审核员可能需要扫描的完整详情。OpenSCAP 工具创建带有详细结果的高级记录格式（ARF）格式的文件。这个 ARF 文件太大，无法存储在配置映射或其他标准 Kubernetes 资源中，因此会创建一个持久性卷（PV）来包含它。

流程

  • 使用 Compliance Operator 从 PV 获取结果是一个包括四步的过程。但是，在 oc-compliance 插件中，您可以使用单个命令： 

    $ oc compliance fetch-raw <object-type> <object-name> -o <output-path>
  • <object-type> 可以是 scansettingbinding、compliancescan 或 compliancesuite，具体取决于扫描通过哪个对象启动。

  • <object-name> 是用于收集 ARF 文件的绑定、套件或扫描对象的名称，<output-path> 是放置结果的本地目录。

    例如： 

    $ oc compliance fetch-raw scansettingbindings my-binding -o /tmp/

    输出示例

    Fetching results for my-binding scans: ocp4-cis, ocp4-cis-node-worker, ocp4-cis-node-master
Fetching raw compliance results for scan 'ocp4-cis'.......
The raw compliance results are available in the following directory: /tmp/ocp4-cis
Fetching raw compliance results for scan 'ocp4-cis-node-worker'...........
The raw compliance results are available in the following directory: /tmp/ocp4-cis-node-worker
Fetching raw compliance results for scan 'ocp4-cis-node-master'......
The raw compliance results are available in the following directory: /tmp/ocp4-cis-node-master

查看目录中的文件列表： 

$ ls /tmp/ocp4-cis-node-master/

输出示例

ocp4-cis-node-master-ip-10-0-128-89.ec2.internal-pod.xml.bzip2  ocp4-cis-node-master-ip-10-0-150-5.ec2.internal-pod.xml.bzip2  ocp4-cis-node-master-ip-10-0-163-32.ec2.internal-pod.xml.bzip2

提取结果： 

$ bunzip2 -c resultsdir/worker-scan/worker-scan-stage-459-tqkg7-compute-0-pod.xml.bzip2 > resultsdir/worker-scan/worker-scan-ip-10-0-170-231.us-east-2.compute.internal-pod.xml

查看结果： 

$ ls resultsdir/worker-scan/

输出示例

worker-scan-ip-10-0-170-231.us-east-2.compute.internal-pod.xml
worker-scan-stage-459-tqkg7-compute-0-pod.xml.bzip2
worker-scan-stage-459-tqkg7-compute-1-pod.xml.bzip2

5.14.3. 重新运行扫描

虽然可以作为调度的作业运行扫描，但通常必须根据需要重新运行扫描，特别是在应用修复或进行其他更改集群时。

流程

  • 使用 Compliance Operator 重新运行扫描需要使用扫描对象上的注解。但是，通过 oc-compliance 插件，您可以使用单个命令重新运行扫描。输入以下命令为名为 my-binding 的 ScanSettingBinding 对象重新运行扫描： 

    $ oc compliance rerun-now scansettingbindings my-binding

    输出示例

    Rerunning scans from 'my-binding': ocp4-cis
Re-running scan 'openshift-compliance/ocp4-cis'

5.14.4. 使用 ScanSettingBinding 自定义资源

当使用由 Compliance Operator 提供的 ScanSetting 和 ScanSettingBinding 自定义资源（CR）时，可以在使用一组常用的扫描选项时，对多个配置集运行扫描，如 schedule、machine roles、tolerations 等。虽然这比使用多个 ComplianceSuite 或 ComplianceScan 对象更容易，但可能会让新用户混淆。

oc compliance bind 子命令可帮助您创建 ScanSettingBinding CR。

流程

  1. 运行： 

    $ oc compliance bind [--dry-run] -N <binding name> [-S <scansetting name>] <objtype/objname> [..<objtype/objname>]
    • 如果省略 -S 标志，则使用 Compliance Operator 提供的 default 扫描设置。
    • 对象类型是 Kubernetes 对象类型，可以是 profile 或 tailorprofile。可以提供多个对象。
    • 对象名称是 Kubernetes 资源的名称，如 .metadata.name。

    • 添加 --dry-run 选项，以显示所创建对象的 YAML 文件。

      例如，给定以下配置集和扫描设置： 

      $ oc get profile.compliance -n openshift-compliance

      输出示例

      NAME              AGE
ocp4-cis          9m54s
ocp4-cis-node     9m54s
ocp4-e8           9m54s
ocp4-moderate     9m54s
ocp4-ncp          9m54s
rhcos4-e8         9m54s
rhcos4-moderate   9m54s
rhcos4-ncp        9m54s
rhcos4-ospp       9m54s
rhcos4-stig       9m54s

      $ oc get scansettings -n openshift-compliance

      输出示例

      NAME                 AGE
default              10m
default-auto-apply   10m

  2. 要将 default 设置应用到 ocp4-cis 和 ocp4-cis-node 配置集，请运行： 

    $ oc compliance bind -N my-binding profile/ocp4-cis profile/ocp4-cis-node

    输出示例

    Creating ScanSettingBinding my-binding

    创建 ScanSettingBinding CR 后，绑定配置集开始使用相关设置扫描两个配置集。总体而言，这是开始使用 Compliance Operator 扫描的最快方法。

5.14.5. 打印控制

合规标准通常分为层次结构，如下所示：

  • 基准是特定标准的一组控制的顶级定义。例如，FedRAMP Moderate 或 Center for Internet Security（CIS）v.1.6.0。
  • 控制描述了遵守基准必须满足的一系列要求。例如，FedRAMP AC-01（访问控制政策和程序）。
  • 规则是单一检查，特定于要纳入合规性的系统，以及一个或多个这些规则映射到控制。
  • Compliance Operator 处理将规则分组到配置集中的单个基准测试。可能很难确定哪些控制配置集中的规则集是否满足要求。

流程

  • oc compliance control 子命令提供有关给定配置集满足的标准和控制标准的报告： 

    $ oc compliance controls profile ocp4-cis-node

    输出示例

    +-----------+----------+
| FRAMEWORK | CONTROLS |
+-----------+----------+
| CIS-OCP   | 1.1.1    |
+           +----------+
|           | 1.1.10   |
+           +----------+
|           | 1.1.11   |
+           +----------+
...

5.14.6. 获取合规补救详情

Compliance Operator 提供了补救对象，用于自动执行与集群兼容所需的更改。fetch-fixes 子命令可帮助您准确了解使用了哪些配置修复。使用 fetch-fixes 子命令，将修复对象从配置集、规则或 ComplianceRemediation 对象提取到要检查的目录中。

流程

  1. 查看配置集的补救： 

    $ oc compliance fetch-fixes profile ocp4-cis -o /tmp

    输出示例

    No fixes to persist for rule 'ocp4-api-server-api-priority-flowschema-catch-all' 1
No fixes to persist for rule 'ocp4-api-server-api-priority-gate-enabled'
No fixes to persist for rule 'ocp4-api-server-audit-log-maxbackup'
Persisted rule fix to /tmp/ocp4-api-server-audit-log-maxsize.yaml
No fixes to persist for rule 'ocp4-api-server-audit-log-path'
No fixes to persist for rule 'ocp4-api-server-auth-mode-no-aa'
No fixes to persist for rule 'ocp4-api-server-auth-mode-node'
No fixes to persist for rule 'ocp4-api-server-auth-mode-rbac'
No fixes to persist for rule 'ocp4-api-server-basic-auth'
No fixes to persist for rule 'ocp4-api-server-bind-address'
No fixes to persist for rule 'ocp4-api-server-client-ca'
Persisted rule fix to /tmp/ocp4-api-server-encryption-provider-cipher.yaml
Persisted rule fix to /tmp/ocp4-api-server-encryption-provider-config.yaml

    1
    当配置集中没有对应的修复规则时会出现 No fixes to persist警告，因为规则无法自动修复，或者没有提供相应的补救。

  2. 您可以查看 YAML 文件示例。head 命令将显示前 10 行： 

    $ head /tmp/ocp4-api-server-audit-log-maxsize.yaml

    输出示例

    apiVersion: config.openshift.io/v1
kind: APIServer
metadata:
  name: cluster
spec:
  maximumFileSizeMegabytes: 100

  3. 查看扫描后创建的 ComplianceRemediation 对象的补救： 

    $ oc get complianceremediations -n openshift-compliance

    输出示例

    NAME                                             STATE
ocp4-cis-api-server-encryption-provider-cipher   NotApplied
ocp4-cis-api-server-encryption-provider-config   NotApplied

    $ oc compliance fetch-fixes complianceremediations ocp4-cis-api-server-encryption-provider-cipher -o /tmp

    输出示例

    Persisted compliance remediation fix to /tmp/ocp4-cis-api-server-encryption-provider-cipher.yaml

  4. 您可以查看 YAML 文件示例。head 命令将显示前 10 行： 

    $ head /tmp/ocp4-cis-api-server-encryption-provider-cipher.yaml

    输出示例

    apiVersion: config.openshift.io/v1
kind: APIServer
metadata:
  name: cluster
spec:
  encryption:
    type: aescbc

警告

在直接应用补救前请小心。有些补救可能不适用于批量，如中等配置集中的 usbguard 规则。在这些情况下，允许 Compliance Operator 应用规则，因为它解决了依赖项并确保集群处于良好状态。

5.14.7. 查看 ComplianceCheckResult 对象详情

扫描运行结束时，会针对各个扫描规则创建 ComplianceCheckResult 对象。view-result 子命令提供了 ComplianceCheckResult 对象详细信息人类可读的输出。

流程

  • 运行： 

    $ oc compliance view-result ocp4-cis-scheduler-no-bind-address