Audit¶

DRP records user-initiated operations as structured audit entries. Audit entries capture who performed an action, what object was affected, when it occurred, and what changed (as a JSON patch diff). This enables administrators to meet compliance requirements, investigate incidents, and trace configuration changes to specific users.

Auditor Plugin¶

The auditor plugin subscribes to the DRP event stream and records user-principal events as audit_entries objects. Each audit entry captures six fields:

The auditor captures all events where the principal matches a user account, excluding internal service accounts (docker-context, racks) and system event types (websocket, connections, audit_entries, activities). Audit entry IDs are formatted as <type>.<action>.<key>.<nanosecond-timestamp>.

Querying Audit Entries¶

Audit entries are stored as DRP audit_entries store objects and can be queried via drpcli:

# List all audit entries (may be large)
drpcli extended list audit_entries

# Show audit entries for a specific machine
drpcli extended list audit_entries | jq '[.[] | select(.Params["audit_entry/key"] == "<machine-uuid>")]'

# Show recent user actions (last 50 entries, sorted by time)
drpcli extended list audit_entries | jq 'sort_by(.Params["audit_entry/time"]) | reverse | .[0:50]'

# Show all delete actions
drpcli extended list audit_entries | jq '[.[] | select(.Params["audit_entry/action"] == "delete")]'

Event Router as Audit Replacement¶

The event-router plugin provides a superset of auditor functionality. Rather than storing audit entries as DRP objects, event-router can route events to external systems (syslog, webhooks, Slack, PagerDuty) for centralized audit storage. This is preferred for production deployments where audit data volume may be large or where integration with a SIEM is required.

For hardware-level auditing via Redfish, see Audit Framework.