The File Integrity Operator for OpenShift Container Platform continually runs file integrity checks on RHCOS nodes.
These release notes track the development of the File Integrity Operator in the OpenShift Container Platform.
For an overview of the File Integrity Operator, see Understanding the File Integrity Operator.
The following advisory is available for the OpenShift File Integrity Operator 0.1.32:
Previously, alerts issued by the File Integrity Operator did not set a namespace, making it difficult to understand from which namespace the alert originated. Now, the Operator sets the appropriate namespace, providing more information about the alert. (BZ#2112394)
Previously, The File Integrity Operator did not update the metrics service on Operator startup, causing the metrics targets to be unreachable. With this release, the File Integrity Operator now ensures the metrics service is updated on Operator startup. (BZ#2115821)
The following advisory is available for the OpenShift File Integrity Operator 0.1.30:
The File Integrity Operator is now supported on the following architectures:
IBM Z and LinuxONE
Previously, alerts issued by the File Integrity Operator did not set a namespace, making it difficult to understand where the alert originated. Now, the Operator sets the appropriate namespace, increasing understanding of the alert. (BZ#2101393)
The following advisory is available for the OpenShift File Integrity Operator 0.1.24:
You can now configure the maximum number of backups stored in the
FileIntegrity Custom Resource (CR) with the
config.maxBackups attribute. This attribute specifies the number of AIDE database and log backups left over from the
re-init process to keep on the node. Older backups beyond the configured number are automatically pruned. The default is set to five backups.
Previously, upgrading the Operator from versions older than 0.1.21 to 0.1.22 could cause the
re-init feature to fail. This was a result of the Operator failing to update
configMap resource labels. Now, upgrading to the latest version fixes the resource labels. (BZ#2049206)
Previously, when enforcing the default
configMap script contents, the wrong data keys were compared. This resulted in the
aide-reinit script not being updated properly after an Operator upgrade, and caused the
re-init process to fail. Now,
daemonSets run to completion and the AIDE database
re-init process executes successfully. (BZ#2072058)
The following advisory is available for the OpenShift File Integrity Operator 0.1.22:
Previously, a system with a File Integrity Operator installed might interrupt the OpenShift Container Platform update, due to the
/etc/kubernetes/aide.reinit file. This occurred if the
/etc/kubernetes/aide.reinit file was present, but later removed prior to the
ostree validation. With this update,
/etc/kubernetes/aide.reinit is moved to the
/run directory so that it does not conflict with the OpenShift Container Platform update. (BZ#2033311)
The following advisory is available for the OpenShift File Integrity Operator 0.1.21:
The metrics related to
FileIntegrity scan results and processing metrics are displayed on the monitoring dashboard on the web console. The results are labeled with the prefix of
If a node has an integrity failure for more than 1 second, the default
PrometheusRule provided in the operator namespace alerts with a warning.
The following dynamic Machine Config Operator and Cluster Version Operator related filepaths are excluded from the default AIDE policy to help prevent false positives during node updates:
The AIDE daemon process has stability improvements over v0.1.16, and is more resilient to errors that might occur when the AIDE database is initialized.