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.
To access the latest release, see Updating the File Integrity Operator.
The following advisory is available for the OpenShift File Integrity Operator 1.3.4:
Previously, File Integrity Operator would issue a NodeHasIntegrityFailure
alert due to multus certificate rotation. With this release, the alert and failing status are now correctly triggered. (OCPBUGS-31257)
The following advisory is available for the OpenShift File Integrity Operator 1.3.3:
This update addresses a CVE in an underlying dependency.
You can install and use the File Integrity Operator in an OpenShift Container Platform cluster running in FIPS mode.
To enable FIPS mode for your cluster, you must run the installation program from a RHEL computer configured to operate in FIPS mode. For more information about configuring FIPS mode on RHEL, see (Installing the system in FIPS mode) |
Previously, some FIO pods with private default mount propagation in combination with hostPath: path: /
volume mounts would break the CSI driver relying on multipath. This problem has been fixed and the CSI driver works correctly. (Some OpenShift Operator pods blocking unmounting of CSI volumes when multipath is in use)
This update resolves CVE-2023-39325. (CVE-2023-39325)
The following advisory is available for the OpenShift File Integrity Operator 1.3.2:
This update addresses a CVE in an underlying dependency.
The following advisory is available for the OpenShift File Integrity Operator 1.3.1:
FIO now includes kubelet certificates as default files, excluding them from issuing warnings when they’re managed by OpenShift Container Platform. (OCPBUGS-14348)
FIO now correctly directs email to the address for Red Hat Technical Support. (OCPBUGS-5023)
Previously, FIO would not clean up FileIntegrityNodeStatus
CRDs when nodes are removed from the cluster. FIO has been updated to correctly clean up node status CRDs on node removal. (OCPBUGS-4321)
Previously, FIO would also erroneously indicate that new nodes failed integrity checks. FIO has been updated to correctly show node status CRDs when adding new nodes to the cluster. This provides correct node status notifications. (OCPBUGS-8502)
Previously, when FIO was reconciling FileIntegrity
CRDs, it would pause scanning until the reconciliation was done. This caused an overly aggressive re-initiatization process on nodes not impacted by the reconciliation. This problem also resulted in unnecessary daemonsets for machine config pools which are unrelated to the FileIntegrity
being changed. FIO correctly handles these cases and only pauses AIDE scanning for nodes that are affected by file integrity changes. (CMP-1097)
In FIO 1.3.1, increasing nodes in IBM Z® clusters might result in Failed
File Integrity node status. For more information, see Adding nodes in IBM Power® clusters can result in failed File Integrity node status.
The following advisory is available for the OpenShift File Integrity Operator 1.2.1:
RHBA-2023:1684 OpenShift File Integrity Operator Bug Fix Update
This release includes updated container dependencies.
The following advisory is available for the OpenShift File Integrity Operator 1.2.0:
The File Integrity Operator Custom Resource (CR) now contains an initialDelay
feature that specifies the number of seconds to wait before starting the first AIDE integrity check. For more information, see Creating the FileIntegrity custom resource.
The File Integrity Operator is now stable and the release channel is upgraded to stable
. Future releases will follow Semantic Versioning. To access the latest release, see Updating the File Integrity Operator.
The following advisory is available for the OpenShift File Integrity Operator 1.0.0:
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 Power®
IBM Z® and IBM® 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 file_integrity_operator_
.
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:
/etc/machine-config-daemon/currentconfig
/etc/pki/ca-trust/extracted/java/cacerts
/etc/cvo/updatepayloads
/root/.kube
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.