logfile audit output is the default output for auditing. It writes data to
<clustername>_access.log file in the logs directory.
Log entry formatedit
The format of a log entry is:
[<timestamp>] [<local_node_info>] [<layer>] [<entry_type>] <attribute_list>
- When the event occurred. You can configure the
timestamp format in
- Information about the local node that generated the log entry. You can control what node information is included by configuring the local node info settings.
- The layer from which this event originated:
- The type of event that occurred:
- A comma-separated list of key-value pairs that contain
data pertaining to the event. Formatted as
attr1=[val1], attr2=[val2]. See Audit Entry Attributes for the attributes that can be included for each type of event.
Logfile output settingsedit
No filtering is performed when auditing, so sensitive data may be audited in plain text when including the request body in audit events.
You can also configure how the logfile is written in the
file located in
ES_PATH_CONF. By default, audit information is appended to the
<clustername>_access.log file located in the standard Elasticsearch
(typically located at
$ES_HOME/logs). The file rolls over on a daily basis.
Logfile audit events ignore policiesedit
The comprehensive audit trail is necessary to ensure accountability. It offers tremendous value during incident response and can even be required for demonstrating compliance.
The drawback of an audited system is represented by the inevitable performance penalty incurred.
In all truth, the audit trail spends I/O ops that are not available anymore for the user’s queries.
Sometimes the verbosity of the audit trail may become a problem that the event type restrictions,
exclude, will not alleviate.
Audit events ignore policies are a finer way to tune the verbosity of the audit trail. These policies define rules that match audit events which will be ignored (read as: not printed). Rules match on the values of attributes of audit events and complement the include/exclude method. Imagine the corpus of audit events and the policies chopping off unwanted events.
When utilizing audit events ignore policies you are acknowledging potential accountability gaps that could render illegitimate actions undetectable. Please take time to review these policies whenever your system architecture changes.
A policy is a named set of filter rules. Each filter rule applies to a single event attribute,
one of the
indices attributes. The filter rule defines
a list of Lucene regexp, any of which has to match the value of the audit
event attribute for the rule to match.
A policy matches an event if all the rules comprising it match the event.
An audit event is ignored, therefore not printed, if it matches any policy. All other
non-matching events are printed as usual.
All policies are defined under the
settings namespace. For example, the following policy named example1 matches
events from the kibana or admin_user principals and operating over indices of the
wildcard form app-logs*:
xpack.security.audit.logfile.events.ignore_filters: example1: users: ["kibana", "admin_user"] indices: ["app-logs*"]
An audit event generated by the kibana user and operating over multiple indices , some of which do not match the indices wildcard, will not match. As expected, operations generated by all other users (even operating only on indices that match the indices filter) will not match this policy either.
Audit events of different types may have different attributes.
If an event does not contain an attribute for which some policy defines filters, the
event will not match the policy.
For example, the following policy named example2, will never match
authentication_failed events, irrespective of the user’s roles, because these
event schemas do not contain the
xpack.security.audit.logfile.events.ignore_filters: example2: roles: ["admin", "ops_admin_*"]
Likewise, any events of users with multiple roles, some of which do not match the regexps will not match this policy.
For completeness, although practical use cases should be sparse, a filter can match
a missing attribute of an event, using the empty string ("") or the empty list ().
For example, the following policy will match events that do not have the
authentication_success and other types) as well
as events over the next index.
xpack.security.audit.logfile.events.ignore_filters: example3: indices: ["next", ""]