Auditd execution options in a container

This article outlines how to run a single instance of the Audit daemon (auditd) on a host in a privileged container.

Requirements for running auditd in containers

• Stop auditd on the host system because only one auditd can be running at a time. If auditd is already running, the system prevents another instance from starting up.

• Run container X in the initial-PID namespace and not in a child-PID namespace. Do not run systemd in the container to launch auditd because this containerized systemd expects to be PID 1. Run auditd directly in the container (or with a wrapper if needed) that does not require to be PID 1.

• Run container X in the initial-user namespace because it checks for the validity of CAP_AUDIT_CONTROL only in this namespace. Having CAP_AUDIT_CONTROL in a child-user namespace is not sufficient.

• Run auditd with the capability CAP_AUDIT_CONTROL because this is required to register the Audit daemon to receive log messages and to configure the Audit subsystem.

• Because auditd requires to access configuration and log files, run it with root privileges.

Additional requirements

• Once you start auditd in container X you cannot start any other auditd instances on the host or in any other container on that host.

• The Audit subsystem must be compiled into the host kernel.

• There must be sufficient disk space for logs. This is configurable.

• The kernel boot command line must not include the audit=0 option that disables the Audit subsystem until the next boot.

• Running another, localized, auditd in a user-namespaced container is not supported at this time.

RHEL container compatibility matrix

The described requirements are valid for RHEL 7 containers on RHEL 7 hosts and RHEL 8 containers on RHEL 8 hosts. See the RHEL Container Compatibility Matrix article for more information.