Tracking configuration changes with audit logs

Track and customize audit logs for configuration changes in Splunk Cloud Platform by configuring the audit.conf file.

In the Splunk platform, you can use audit logs to track configuration changes. Changes made through the Splunk Web, CLI, or REST API, generate audit events for create, read, update, and delete (CRUD) operations on knowledge objects and system configuration resources. These audit events provide visibility into who made a configuration change, what changed, and when.

The audit logs do not record changes made directly to configuration files on disk.

Tracking of configuration changes is activated by default in the server.conf file under [config_api_audit] stanza.

Benefits of tracking configuration changes

Tracking configuration changes through audit logs provides the following benefits:

Operational visibility
Provides a chronological record of configuration changes across the Splunk platform.
Improved audit coverage
Maintains detailed records of configuration modifications, including who made the change, what changed, and when.
Faster troubleshooting
Helps admins quickly identify configuration changes that may have caused incidents or unexpected behavior.
Operational transparency
Ensures configuration changes are traceable and auditable across the environment.

Tracking configuration changes in clustered environments

Note: Configuration change tracking does not replicate audit data across cluster nodes.

Tracking of configuration changes must be activated on each node individually in clustered environments. Activating it on one node does not provide visibility into configuration changes made on other nodes.

Data logged for configuration changes

View the list of fields included in audit logs for configuration changes.

Audit logs for configuration changes include the following fields:

Field name Description
action

Performed operation, such as create, edit, delete, or move.

actor.name

Name of the user who performed the action.

actor.role

Role assigned to the user who initiated the change.

config_path

Logical path to the changed configuration resource.

name

Stanza name associated with the configuration entry.

src_file_path

Relative path to the source configuration .conf file.

dst_file_path

Relative path to the destination configuration .conf file.

metadata_src_path

Relative path to the source .meta file. These files define permissions for knowledge objects within an app.

metadata_dst_path

Relative path to the destination .meta file.

result

Indicates whether the operation succeeded or failed.

timestamp

Time when the change occurred.

url

URI or endpoint where the request originated. This indicates whether the change was initiated through the Splunk Web or a REST API call.

Configure tracking of configuration changes

Verify that tracking of configuration changes is activated and customize audit logging in the Splunk platform.

To track configuration changes, use one of the following:

  • Splunk Cloud Platform version 10.3.2512 or higher
  • Splunk Enterprise version 10.6 or higher
Follow these steps to configure tracking of configuration changes with audit logs:
  1. Verify that the [config_api_audit] stanza in the server.conf file is set to disabled = false.
    This is the default setting. The value of false means that tracking is turned on.
  2. Verify that the [auditTrail] stanza in the audit.conf file is set to logging_format = both or logging_format = v2.
    The default settings is logging_format = both. Configuration change tracking is supported only in the structured audit trail format, also known as Audit Trail Log v2. See About structured audit trail logs .
  3. (Optional) To customize audit logging for specific REST resource paths you want to monitor, use the [auditconfig:/path] stanza in the audit.conf file.

    Use this stanza to configure the following:

    • Log or skip operations for specific resources

    • Specify operation types to log

    • Set sampling rates for audit events

  4. (Optional) Specify properties that you want to redact using the redact_fields setting in the [auditTrail] stanza of the audit.conf file.
    Note: You must either reload the audit subsystem or the audit.conf configuration file directly through the REST API for changes to this setting to take affect.
Tracking of configuration changes with audit logs is configured.

Search audit logs for configuration changes

Search audit logs to identify configuration changes by user, action type, and configuration path.

To view configuration change events grouped by user and configuration path, use the following example search:
CODE
index=_audit sourcetype=audittrailv2 action!="" | stats count by actor.name action data.config_path
This search returns a summary of configuration changes organized by:
  • User who made the change
  • Type of performed operation
  • Changed configuration path