Configuring the Custom File Integrity Operator

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:

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

Important attributes

Table 1. Important spec and spec.config attributes
AttributeDescription

spec.nodeSelector

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 node-role.kubernetes.io/worker: “” schedules AIDE on all worker nodes, node.openshift.io/os_id: “rhcos” schedules on all Fedora CoreOS (FCOS) nodes.

spec.debug

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

spec.tolerations

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

spec.config.gracePeriod

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.name, 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.

Procedure

  • To examine the default config, run:

    1. $ 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:

  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. report_url=stdout
  9. PERMS = p+u+g+acl+selinux+xattrs
  10. CONTENT_EX = sha512+ftype+p+u+g+n+acl+selinux+xattrs
  12. /hostroot/boot/        CONTENT_EX
  13. /hostroot/root/\..* PERMS
  14. /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/

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 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 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. 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:

    1. $ 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:

    1. $ vim aide.conf

    Example output

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

    Exclude a path specific to control plane nodes:

    1. !/opt/mydaemon/

    Store the other content in /etc:

    1. /hostroot/etc/    CONTENT_EX

  6. Create a config map based on this file:

    1. $ oc create cm master-aide-conf --from-file=aide.conf

  7. 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

    1. !/hostroot/opt/mydaemon

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