Viewing FileIntegrity object attributes

As with any Kubernetes custom resources (CRs), you can run oc explain fileintegrity, and then look at the individual attributes using:

$ oc explain fileintegrity.spec
$ oc explain fileintegrity.spec.config

Important attributes

Table 1. Important spec and spec.config attributes
Attribute Description


A map of key-values pairs that must match with node’s labels in order for the AIDE pods to be schedulable on that node. The typical use is to set only a single key-value pair where "" schedules AIDE on all worker nodes, "rhcos" schedules on all Fedora CoreOS (FCOS) nodes.


A boolean attribute. If set to true, the daemon running in the AIDE deamon set’s pods would output extra information.


Specify tolerations to schedule on nodes with custom taints. When not specified, a default toleration is applied, which allows tolerations to run on master nodes.


The number of seconds to pause in between AIDE integrity checks. Frequent AIDE checks on a node can be resource intensive, so it can be useful to specify a longer interval. Defaults to 900, or 15 minutes., spec.config.namespace, spec.config.key

These three attributes allow you to set a custom AIDE configuration. When the name or namespace are unset, the File Integrity Operator generates a configuration suitable for FCOS systems. The name and namespace attributes point to the config map; the key points to a key inside that config map. Use the key attribute to specify a custom key that contains the actual config and defaults to aide.conf.

Examine the default configuration

The default File Integrity Operator configuration is stored in a config map with the same name as the FileIntegrity CR.

  1. To examine the default config, run:

    $ oc describe cm/worker-fileintegrity

Understanding the default File Integrity Operator configuration

Below is an excerpt from the aide.conf key of the config map:

@@define DBDIR /hostroot/etc/kubernetes
@@define LOGDIR /hostroot/etc/kubernetes
PERMS = p+u+g+acl+selinux+xattrs
CONTENT_EX = sha512+ftype+p+u+g+n+acl+selinux+xattrs

/hostroot/boot/    	CONTENT_EX
/hostroot/root/\..* PERMS
/hostroot/root/   CONTENT_EX

The default configuration for a FileIntegrity instance provides coverage for files under the following directories:

  • /root

  • /boot

  • /usr

  • /etc

The following directories are not covered:

  • /var

  • /opt

  • Some OpenShift-specific excludes under /etc/

Supplying a custom AIDE configuration

Any entries that configure AIDE internal behavior such as DBDIR, LOGDIR, database, and database_out are overwritten by the Operator. The Operator would add a prefix to /hostroot/ before all paths to be watched for integrity changes. This makes reusing existing AIDE configs that might often not be tailored for a containerized environment and start from the root directory easier.

/hostroot is the directory where the pods running AIDE mount the host’s filesystem. Changing the configuration triggers a reinitializing of the database.

Defining a custom File Integrity Operator configuration

This example focuses on defining a custom configuration for a scanner that runs on the master nodes based on the default configuration provided for the worker-fileintegrity CR. This workflow might be useful if you are planning to deploy a custom software running as a daemon set and storing its data under /opt/mydaemon on the master nodes.

  1. Make a copy of the default configuration.

  2. Edit the default configuration with the files that must be watched or excluded.

  3. Store the edited contents in a new config map.

  4. Point the FileIntegrity object to the new config map through the attributes in spec.config.

  5. Extract the default configuration:

    $ oc extract cm/worker-fileintegrity --keys=aide.conf

    This creates a file named aide.conf that you can edit. To illustrate how the Operator post-processes the paths, this example adds an exclude directory without the prefix:

    $ vim aide.conf
    Example output

    Exclude a path specific to master nodes:


    Store the other content in /etc:

    /hostroot/etc/	CONTENT_EX
  6. Create a config map based on this file:

    $ oc create cm master-aide-conf --from-file=aide.conf
  7. Define a FileIntegrity CR manifest that references the config map:

    kind: FileIntegrity
      name: master-fileintegrity
      namespace: openshift-file-integrity
          name: master-aide-conf
          namespace: openshift-file-integrity

    The Operator processes the provided config map file and stores the result in a config map with the same name as the FileIntegrity object:

    $ oc describe cm/master-fileintegrity | grep /opt/mydaemon
    Example output

Changing the custom File Integrity configuration

To change the File Integrity configuration, never change the generated config map. Instead, change the config map that is linked to the FileIntegrity object through the, namespace, and key attributes.

Currently, you must also annotate the FileIntegrity object in order to force reconciliation of the object and its config map. For example:

$ oc annotate fileintegrities/worker-fileintegrity

The value of the annotation or whether it is an annotation does not really matter; the purpose is of this operation is to force reconciliation of the FileIntegrity object and re-render the processed config map with the generated configuration.