6.5. 执行高级自定义 File Integrity Operator 任务

6.5.1. 重新初始化数据库

如果 File Integrity Operator 检测到计划进行的更改，则可能需要重新初始化数据库。

流程

  • 使用 file-integrity.openshift.io/re-init 注解 FileIntegrity 自定义资源（CR）： 

    $ oc annotate fileintegrities/worker-fileintegrity file-integrity.openshift.io/re-init=

    旧的数据库和日志文件已备份，新的数据库被初始化。旧的数据库和日志保留在 /etc/kubernetes 下的节点上，参见使用 oc debug 生成的 Pod 中的以下输出：

    输出示例

     ls -lR /host/etc/kubernetes/aide.*
-rw-------. 1 root root 1839782 Sep 17 15:08 /host/etc/kubernetes/aide.db.gz
-rw-------. 1 root root 1839783 Sep 17 14:30 /host/etc/kubernetes/aide.db.gz.backup-20200917T15_07_38
-rw-------. 1 root root   73728 Sep 17 15:07 /host/etc/kubernetes/aide.db.gz.backup-20200917T15_07_55
-rw-r--r--. 1 root root       0 Sep 17 15:08 /host/etc/kubernetes/aide.log
-rw-------. 1 root root     613 Sep 17 15:07 /host/etc/kubernetes/aide.log.backup-20200917T15_07_38
-rw-r--r--. 1 root root       0 Sep 17 15:07 /host/etc/kubernetes/aide.log.backup-20200917T15_07_55

    为了提供一些永久记录，生成的配置映射不归 FileIntegrity 所有，因此需要手动清理。因此，任何之前的完整性失败仍在 FileIntegrityNodeStatus 对象中可见。

6.5.2. 机器配置集成

在 OpenShift Container Platform 4 中，集群节点配置通过 MachineConfig 对象提供。您可以假定因 MachineConfig 对象导致的对文件进行的更改是预期行为，不应该导致文件完整性扫描失败。为禁止由于 MachineConfig 对象更新导致对文件进行更改，File Integrity Operator 会监视节点对象；在更新节点期间，会暂停 AIDE 扫描。更新完成后，数据库会重新初始化并恢复扫描。

此暂停和恢复逻辑只适用于通过 MachineConfig API 进行的更新，因为它们反映在节点对象注解中。

6.5.3. 探索守护进程集

每个 FileIntegrity 对象代表多个节点上的扫描。扫描本身由守护进程集管理的 Pod 执行。

要查找代表 FileIntegrity 对象的守护进程集，请运行： 

$ oc -n openshift-file-integrity get ds/aide-worker-fileintegrity

要列出该守护进程集中的 Pod，请运行： 

$ oc -n openshift-file-integrity get pods -lapp=aide-worker-fileintegrity

要查看单个 AIDE Pod 的日志，调用其中一个 Pod 上的 oc logs。 

$ oc -n openshift-file-integrity logs pod/aide-worker-fileintegrity-mr8x6

输出示例

Starting the AIDE runner daemon
initializing AIDE db
initialization finished
running aide check
...

由 AIDE 守护进程创建的配置映射不会保留，在 File Integrity Operator 处理后会被删除。但是，如果失败和出错，这些配置映射的内容会被复制到 FileIntegrityNodeStatus 对象指向的配置映射中。