Configuring the Custom File Integrity Operator

    1. $ oc explain fileintegrity.spec.config

    Important attributes

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

    Procedure

    • To examine the default config, run:

      1. $ oc describe cm/worker-fileintegrity

    Understanding the default File Integrity Operator configuration

    1. @@define DBDIR /hostroot/etc/kubernetes
    2. @@define LOGDIR /hostroot/etc/kubernetes
    3. database=file:@@{DBDIR}/aide.db.gz
    4. database_out=file:@@{DBDIR}/aide.db.gz
    5. gzip_dbout=yes
    6. verbose=5
    7. report_url=file:@@{LOGDIR}/aide.log
    8. PERMS = p+u+g+acl+selinux+xattrs
    9. /hostroot/boot/ CONTENT_EX
    10. /hostroot/root/\..* PERMS
    11. /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 OKD-specific excludes under /etc/

    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 file system. 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 control plane nodes (also known as 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 control plane nodes.

    Procedure

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

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

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

    4. Extract the default configuration:

      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:

      Example output

      1. /hostroot/etc/kubernetes/static-pod-resources
      2. !/hostroot/etc/kubernetes/aide.*
      3. !/hostroot/etc/docker/certs.d
      4. !/hostroot/etc/selinux/targeted
      5. !/hostroot/etc/openvswitch/conf.db

      Exclude a path specific to control plane nodes:

      1. !/opt/mydaemon/

      Store the other content in /etc:

    5. Create a config map based on this file:

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

      1. apiVersion: fileintegrity.openshift.io/v1alpha1
      2. kind: FileIntegrity
      3. metadata:
      4. name: master-fileintegrity
      5. namespace: openshift-file-integrity
      6. spec:
      7. nodeSelector:
      8. node-role.kubernetes.io/master: ""
      9. config:
      10. name: master-aide-conf
      11. 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:

      1. $ oc describe cm/master-fileintegrity | grep /opt/mydaemon

      Example output

    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 spec.name, , and key attributes.