NOTE: You are looking at documentation for an older release. For the latest information, see the current release documentation.
Index audit outputedit
Deprecated in 6.7.0.
The index output type is deprecated and will be removed in 7.0. The sole output for the audit trail will be the logfile type.
In addition to logging to a file, you can store audit logs in Elasticsearch
rolling indices. These indices can be either on the same cluster, or on a
remote cluster. You configure the following settings in
elasticsearch.yml to control how audit entries are indexed. To enable
this output, you need to configure the setting xpack.security.audit.outputs
in the elasticsearch.yml file:
xpack.security.audit.outputs: [ index, logfile ]
For more configuration options, see Audit log indexing configuration settings.
No filtering is performed when auditing, so sensitive data may be audited in plain text when including the request body in audit events.
Audit index settingsedit
You can also configure settings for the indices that the events are stored in.
These settings are configured in the xpack.security.audit.index.settings namespace
in elasticsearch.yml. For example, the following configuration sets the
number of shards and replicas to 1 for the audit indices:
xpack.security.audit.index.settings:
index:
number_of_shards: 1
number_of_replicas: 1
These settings apply to the local audit indices, as well as to the remote audit indices, but only if the remote cluster does not have security features enabled or the Elasticsearch versions are different. If the remote cluster has security features enabled and the versions coincide, the settings for the audit indices there will take precedence, even if they are unspecified (i.e. left to defaults).
Audit events are batched for indexing so there is a lag before
events appear in the index. You can control how frequently batches of
events are pushed to the index by setting
xpack.security.audit.index.flush_interval in elasticsearch.yml.