The Mission Portal Audit log API records administrative actions (user, role, settings, host, group, Build project, and federated reporting changes) in the audit_log table of the cfsettings PostgreSQL database.

Default retention

There is no automatic retention or purging of audit log entries. Records are kept indefinitely until manually removed.

This is intentional for compliance use cases where a long, complete history is desirable, but it means the audit_log table will grow without bound on long-running hubs. Operators are expected to apply their own retention policy.

Inspecting current size

To see how many entries you have and how old they are:

sudo -u cfpostgres /var/cfengine/bin/psql cfsettings -c \
  "SELECT count(*) AS rows,
          min(time) AS oldest,
          max(time) AS newest,
          pg_size_pretty(pg_total_relation_size('audit_log')) AS size
   FROM audit_log;"

Manually pruning old entries

To delete entries older than a chosen number of days, run as the cfpostgres user on the hub:

sudo -u cfpostgres /var/cfengine/bin/psql cfsettings -c \
  "DELETE FROM audit_log WHERE time < NOW() - INTERVAL '180 days';"

The idx_audit_log_timestamp index ensures this is efficient even on large tables. Adjust the interval to match your retention policy (regulatory requirements often dictate 1, 3, or 7 years).

Scheduling pruning with CFEngine policy

A simple way to enforce retention is to add a commands promise to your policy that runs the cleanup once per day. For example, in a custom bundle on the hub:

bundle agent audit_log_retention
# @brief Prune Mission Portal audit_log entries older than $(days) days
{
  vars:
      "days" string => "365";

  commands:
    policy_server::
      "$(sys.bindir)/psql"
        args     => "cfsettings -c \"DELETE FROM audit_log WHERE time < NOW() - INTERVAL '$(days) day';\"",
        contain  => in_shell_and_silent,
        action   => if_elapsed_day,
        handle   => "audit_log_retention_prune",
        comment  => "Prune Mission Portal audit_log entries older than $(days) days";
}

Run this bundle from policy_server context (i.e. only on the hub) and only when your policy is comfortable issuing DELETE statements against the settings database.

RBAC

Viewing the Audit log in Mission Portal or via the API requires the audit-log.view RBAC permission, granted to the admin role by default.

See also