Index audit output

edit

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 settings

edit

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.