IMPORTANT: No additional bug fixes or documentation updates will be released for this version. For the latest information, see the current release documentation.

« Mutual TLS authentication between Kibana and Elasticsearch Access agreement »

› › ›

Audit logs

edit

Audit logs

edit

You can enable auditing to keep track of security-related events such as authorization success and failures. Logging these events enables you to monitor Kibana for suspicious activity and provides evidence in the event of an attack.

Use the Kibana audit logs in conjunction with Elasticsearch audit logging to get a holistic view of all security related events. Kibana defers to the Elasticsearch security model for authentication, data index authorization, and features that are driven by cluster-wide privileges. For more information on enabling audit logging in Elasticsearch, refer to Auditing security events.

Audit logs are disabled by default. To enable this functionality, you must set xpack.security.audit.enabled to true in kibana.yml.

The current version of the audit logger uses the standard Kibana logging output, which can be configured in kibana.yml. For more information, refer to Configure Kibana. The audit logger uses a separate logger and can be configured using the options in Audit logging settings.

Audit event types

edit

When you are auditing security events, each request can generate multiple audit events. The following is a list of the events that can be generated:

`saved_objects_authorization_success`	Logged when a user is authorized to access a saved objects when using a role with Kibana privileges
`saved_objects_authorization_failure`	Logged when a user isn’t authorized to access a saved objects when using a role with Kibana privileges

ECS audit events

edit

The following events are only logged if the ECS audit logger is enabled. For information on how to configure xpack.security.audit.appender, refer to ECS audit logging settings.

Refer to the table of events that can be logged for auditing purposes.

Each event is broken down into category, type, action and outcome fields to make it easy to filter, query and aggregate the resulting logs. The trace.id field can be used to correlate multiple events that originate from the same request.

Refer to ECS audit schema for a table of fields that get logged with audit event.

To ensure that a record of every operation is persisted even in case of an unexpected error, asynchronous write operations are logged immediately after all authorization checks have passed, but before the response from Elasticsearch is received. Refer to the corresponding Elasticsearch logs for potential write errors.

Category: authentication edit
Action	Outcome	Description
`user_login`	`success`	User has logged in successfully.
`user_login`	`failure`	Failed login attempt (e.g. due to invalid credentials).
Category: database edit Type: creation edit
Action	Outcome	Description
`saved_object_create`	`unknown`	User is creating a saved object.
`saved_object_create`	`failure`	User is not authorized to create a saved object.
`connector_create`	`unknown`	User is creating a connector.
`connector_create`	`failure`	User is not authorized to create a connector.
`alert_create`	`unknown`	User is creating an alert rule.
`alert_create`	`failure`	User is not authorized to create an alert rule.
Type: change edit
Action	Outcome	Description
`saved_object_update`	`unknown`	User is updating a saved object.
`saved_object_update`	`failure`	User is not authorized to update a saved object.
`saved_object_add_to_spaces`	`unknown`	User is adding a saved object to other spaces.
`saved_object_add_to_spaces`	`failure`	User is not authorized to add a saved object to other spaces.
`saved_object_delete_from_spaces`	`unknown`	User is removing a saved object from other spaces.
`saved_object_delete_from_spaces`	`failure`	User is not authorized to remove a saved object from other spaces.
`saved_object_remove_references`	`unknown`	User is removing references to a saved object.
`saved_object_remove_references`	`failure`	User is not authorized to remove references to a saved object.
`connector_update`	`unknown`	User is updating a connector.
`connector_update`	`failure`	User is not authorized to update a connector.
`alert_update`	`unknown`	User is updating an alert rule.
`alert_update`	`failure`	User is not authorized to update an alert rule.
`alert_update_api_key`	`unknown`	User is updating the API key of an alert rule.
`alert_update_api_key`	`failure`	User is not authorized to update the API key of an alert rule.
`alert_enable`	`unknown`	User is enabling an alert rule.
`alert_enable`	`failure`	User is not authorized to enable an alert rule.
`alert_disable`	`unknown`	User is disabling an alert rule.
`alert_disable`	`failure`	User is not authorized to disable an alert rule.
`alert_mute`	`unknown`	User is muting an alert rule.
`alert_mute`	`failure`	User is not authorized to mute an alert rule.
`alert_unmute`	`unknown`	User is unmuting an alert rule.
`alert_unmute`	`failure`	User is not authorized to unmute an alert rule.
`alert_instance_mute`	`unknown`	User is muting an alert instance.
`alert_instance_mute`	`failure`	User is not authorized to mute an alert instance.
`alert_instance_unmute`	`unknown`	User is unmuting an alert instance.
`alert_instance_unmute`	`failure`	User is not authorized to unmute an alert instance.
Type: deletion edit
Action	Outcome	Description
`saved_object_delete`	`unknown`	User is deleting a saved object.
`saved_object_delete`	`failure`	User is not authorized to delete a saved object.
`connector_delete`	`unknown`	User is deleting a connector.
`connector_delete`	`failure`	User is not authorized to delete a connector.
`alert_delete`	`unknown`	User is deleting an alert rule.
`alert_delete`	`failure`	User is not authorized to delete an alert rule.
Type: access edit
Action	Outcome	Description
`saved_object_get`	`success`	User has accessed a saved object.
`saved_object_get`	`failure`	User is not authorized to access a saved object.
`saved_object_find`	`success`	User has accessed a saved object as part of a search operation.
`saved_object_find`	`failure`	User is not authorized to search for saved objects.
`connector_get`	`success`	User has accessed a connector.
`connector_get`	`failure`	User is not authorized to access a connector.
`connector_find`	`success`	User has accessed a connector as part of a search operation.
`connector_find`	`failure`	User is not authorized to search for connectors.
`alert_get`	`success`	User has accessed an alert rule.
`alert_get`	`failure`	User is not authorized to access an alert rule.
`alert_find`	`success`	User has accessed an alert rule as part of a search operation.
`alert_find`	`failure`	User is not authorized to search for alert rules.
Category: web edit
Action	Outcome	Description
`http_request`	`unknown`	User is making an HTTP request.

ECS audit schema

edit

Audit logs are written in JSON using Elastic Common Schema (ECS) specification.

Base Fields edit
Field	Description
`@timestamp`	Time when the event was generated. Example: `2016-05-23T08:05:34.853Z`
`message`	Human readable description of the event.
Event Fields edit
Field	Description
`event.action`	The action captured by the event. Refer to ECS audit events for a table of possible actions.
`event.category`	High level category associated with the event. This field is closely related to `event.type`, which is used as a subcategory. Possible values: `database`, `web`, `authentication`
`event.type`	Subcategory associated with the event. This field can be used along with the `event.category` field to enable filtering events down to a level appropriate for single visualization. Possible values: `creation`, `access`, `change`, `deletion`
`event.outcome`	Denotes whether the event represents a success or failure. Possible values: `success`, `failure`, `unknown`
User Fields edit
Field	Description
`user.name`	Login name of the user. Example: `jdoe`
`user.roles[]`	Set of user roles at the time of the event. Example: `[kibana_admin, reporting_user]`
Kibana Fields edit
Field	Description
`kibana.space_id`	ID of the space associated with the event. Example: `default`
`kibana.session_id`	ID of the user session associated with the event. Each login attempt results in a unique session id.
`kibana.saved_object.type`	Type of saved object associated with the event. Example: `dashboard`
`kibana.saved_object.id`	ID of the saved object associated with the event.
`kibana.authentication_provider`	Name of the authentication provider associated with the event. Example: `my-saml-provider`
`kibana.authentication_type`	Type of the authentication provider associated with the event. Example: `saml`
`kibana.authentication_realm`	Name of the Elasticsearch realm that has authenticated the user. Example: `native`
`kibana.lookup_realm`	Name of the Elasticsearch realm where the user details were retrieved from. Example: `native`
`kibana.add_to_spaces[]`	Set of space IDs that a saved object is being shared to as part of the event. Example: `[default, marketing]`
`kibana.delete_from_spaces[]`	Set of space IDs that a saved object is being removed from as part of the event. Example: `[marketing]`
Error Fields edit
Field	Description
`error.code`	Error code describing the error.
`error.message`	Error message.
HTTP and URL Fields edit
Field	Description
`http.request.method`	HTTP request method. Example: `get`, `post`, `put`, `delete`
`url.domain`	Domain of the url. Example: `www.elastic.co`
`url.path`	Path of the request. Example: `/search`
`url.port`	Port of the request. Example: `443`
`url.query`	The query field describes the query string of the request. Example: `q=elasticsearch`
`url.scheme`	Scheme of the request. Example: `https`
Tracing Fields edit
Field	Description
`trace.id`	Unique identifier allowing events of the same transaction from Kibana and Elasticsearch to be be correlated.

Correlating ECS audit events

edit

Audit events can be correlated in two ways:

Multiple Kibana audit events that resulted from the same request can be correlated together.
If Elasticsearch audit logging is enabled, Kibana audit events from one request can be correlated with backend calls that create Elasticsearch audit events.

The examples below are simplified, many fields have been omitted and values have been shortened for clarity.

Example 1: correlating multiple Kibana audit events

edit

When "thom" creates a new alerting rule, five audit events are written:

{"event":{"action":"http_request","category":["web"],"outcome":"unknown"},"http":{"request":{"method":"post"}},"url":{"domain":"localhost","path":"/api/alerting/rule","port":5601,"scheme":"https"},"user":{"name":"thom","roles":["superuser"]},"kibana":{"space_id":"default","session_id":"3dHCZRB..."},"@timestamp":"2022-01-25T13:05:34.449-05:00","message":"User is requesting [/api/alerting/rule] endpoint","trace":{"id":"e300e06..."}}
{"event":{"action":"space_get","category":["database"],"type":["access"],"outcome":"success"},"kibana":{"space_id":"default","session_id":"3dHCZRB...","saved_object":{"type":"space","id":"default"}},"user":{"name":"thom","roles":["superuser"]},"@timestamp":"2022-01-25T13:05:34.454-05:00","message":"User has accessed space [id=default]","trace":{"id":"e300e06..."}}
{"event":{"action":"connector_get","category":["database"],"type":["access"],"outcome":"success"},"kibana":{"space_id":"default","session_id":"3dHCZRB...","saved_object":{"type":"action","id":"5e3b1ae..."}},"user":{"name":"thom","roles":["superuser"]},"@timestamp":"2022-01-25T13:05:34.948-05:00","message":"User has accessed connector [id=5e3b1ae...]","trace":{"id":"e300e06..."}}
{"event":{"action":"connector_get","category":["database"],"type":["access"],"outcome":"success"},"kibana":{"space_id":"default","session_id":"3dHCZRB...","saved_object":{"type":"action","id":"5e3b1ae..."}},"user":{"name":"thom","roles":["superuser"]},"@timestamp":"2022-01-25T13:05:34.956-05:00","message":"User has accessed connector [id=5e3b1ae...]","trace":{"id":"e300e06..."}}
{"event":{"action":"rule_create","category":["database"],"type":["creation"],"outcome":"unknown"},"kibana":{"space_id":"default","session_id":"3dHCZRB...","saved_object":{"type":"alert","id":"64517c3..."}},"user":{"name":"thom","roles":["superuser"]},"@timestamp":"2022-01-25T13:05:34.956-05:00","message":"User is creating rule [id=64517c3...]","trace":{"id":"e300e06..."}}

All of these audit events can be correlated together by the same trace.id value "e300e06...". The first event is the HTTP API call, the next audit events are checks to validate the space and the connectors, and the last audit event is the actual rule creation.

Example 2: correlating a Kibana audit event with Elasticsearch audit events

edit

When "thom" logs in, a "user_login" Kibana audit event is written:

{"event":{"action":"user_login","category":["authentication"],"outcome":"success"},"user":{"name":"thom","roles":["superuser"]},"@timestamp":"2022-01-25T09:40:39.267-05:00","message":"User [thom] has logged in using basic provider [name=basic]","trace":{"id":"818cbf3..."}}

The trace.id value "818cbf3..." in the Kibana audit event can be correlated with the opaque_id value in these six Elasticsearch audit events:

{"type":"audit", "timestamp":"2022-01-25T09:40:38,604-0500", "event.action":"access_granted", "user.name":"thom", "user.roles":["superuser"], "request.id":"YCx8wxs...", "action":"cluster:admin/xpack/security/user/authenticate", "request.name":"AuthenticateRequest", "opaque_id":"818cbf3..."}
{"type":"audit", "timestamp":"2022-01-25T09:40:38,613-0500", "event.action":"access_granted", "user.name":"kibana_system", "user.roles":["kibana_system"], "request.id":"Ksx73Ad...", "action":"indices:data/write/index", "request.name":"IndexRequest", "indices":[".kibana_security_session_1"], "opaque_id":"818cbf3..."}
{"type":"audit", "timestamp":"2022-01-25T09:40:38,613-0500", "event.action":"access_granted", "user.name":"kibana_system", "user.roles":["kibana_system"], "request.id":"Ksx73Ad...", "action":"indices:data/write/bulk", "request.name":"BulkRequest", "opaque_id":"818cbf3..."}
{"type":"audit", "timestamp":"2022-01-25T09:40:38,613-0500", "event.action":"access_granted", "user.name":"kibana_system", "user.roles":["kibana_system"], "request.id":"Ksx73Ad...", "action":"indices:data/write/bulk[s]", "request.name":"BulkShardRequest", "indices":[".kibana_security_session_1"], "opaque_id":"818cbf3..."}
{"type":"audit", "timestamp":"2022-01-25T09:40:38,613-0500", "event.action":"access_granted", "user.name":"kibana_system", "user.roles":["kibana_system"], "request.id":"Ksx73Ad...", "action":"indices:data/write/index:op_type/create", "request.name":"BulkItemRequest", "indices":[".kibana_security_session_1"], "opaque_id":"818cbf3..."}
{"type":"audit", "timestamp":"2022-01-25T09:40:38,613-0500", "event.action":"access_granted", "user.name":"kibana_system", "user.roles":["kibana_system"], "request.id":"Ksx73Ad...", "action":"indices:data/write/bulk[s][p]", "request.name":"BulkShardRequest", "indices":[".kibana_security_session_1"], "opaque_id":"818cbf3..."}

The Elasticsearch audit events show that "thom" authenticated, then subsequently "kibana_system" created a session for that user.

« Mutual TLS authentication between Kibana and Elasticsearch Access agreement »

Audit logs

Audit logs

Audit event types

ECS audit events

Category: authentication

Category: database

Type: creation

Type: change

Type: deletion

Type: access

Category: web

ECS audit schema

Base Fields

Event Fields

User Fields

Kibana Fields

Error Fields

HTTP and URL Fields

Tracing Fields

Correlating ECS audit events

Example 1: correlating multiple Kibana audit events

Example 2: correlating a Kibana audit event with Elasticsearch audit events