Kibana audit events

Audit logging is a subscription feature that you can enable 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.

Refer to enabling and configuring audit logs for details on activation and tunning.

This section describes Kibana 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 or, for a workload that runs as a service account, from the same run.

Refer to audit schema for a table of fields logged with audit events.

A service_account_assume event marks the start of a workload run that executes as a service account. Use it to find everything that run did.

• Who acted: The service account is the actor. user.id and user.name are the account ID, and user.roles is omitted.

• What the run did: Every event the run causes shares this event's trace.id. Search on that value to list them. When the plugin supplies a run ID, it appears in kibana.workload.execution_id and in the message as [executionId=…].

• How to reduce volume: A workload that runs often writes one success event for each run. To drop them, add this filter to xpack.security.audit.ignore_filters:

  xpack.security.audit.ignore_filters:
    - actions: [service_account_assume]
      outcomes: [success]
  

A failure event means Kibana couldn't run the workload as its service account, or couldn't keep running it. Kibana doesn't log a temporary failure, such as an unavailable Elasticsearch cluster. It logs a permanent failure once for each run. A failure at the start is logged without a request, so its trace.id comes from the active tracing span instead of the run.

When the run starts, a failure means one of these:

• The binding failed integrity verification. The event omits the account, and the message reads failed to execute as its service account.
• The binding names a different account than expected.
• The account was deleted, or recreated after the workload was bound.
• The account's credential was refused.

While the run is in progress, a failure means one of these:

• The workload was bound to a different account, or unbound.
• The account was deleted, or recreated.
• The account's credential was refused.

A sandbox_rpc event describes one call from a plugin to the sandbox, not the command or file operation inside it. It records no command, environment variable value, file path or file content.

• Who issued the call: kibana.sandbox_caller names the plugin, the kind of caller (a tool, a workflow step, or the findings recorder), its ID, and the run it belongs to. Whether the event names who is behind the call depends on the request the caller holds: a request from a signed-in user names that user. A tool call usually runs in an Agent Builder execution on Task Manager, and a workflow step runs with a fake request. A fake request carries no authentication state and no socket, so the event names a service account in user.id and user.name only when the request is registered as one. Otherwise user.* is left out and client is empty, as it is for a workflow that runs as a user or a workflow without such a request. Either way the event carries kibana.space_id, and the tool call or workflow run in kibana.sandbox_caller.execution_id.
• Find the same call elsewhere: The proxy's request ID is in sandbox.proxy_request_id — not in http.request.id, which carries Kibana's own request ID — and the sandbox service logs it under the same name. sandbox.conversation_id identifies the conversation in the same way on both sides.

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

Serverless Preview Elastic Cloud Serverless projects are autoscaled environments, fully managed by Elastic and available on Elastic Cloud. Availability Preview This functionality is in technical preview and is ready for evaluation. Use with caution in production; it is not recommended for mission-critical workloads. Elastic will work to fix any issues, but features in technical preview are not subject to the support SLA of official GA features. Specific Support terms apply. Serverless interfaces and procedures might differ from classic Elastic Stack deployments. In Elastic Cloud Serverless, Kibana audit logs delivered through audit trail log delivery use OpenTelemetry field names. Refer to Serverless OpenTelemetry field names for more information.

In Elastic Cloud Serverless, Kibana audit logs are delivered through audit trail log delivery and use the following OpenTelemetry field names instead of the ECS fields in the audit schema. This mapping is specific to Elastic Cloud Serverless. On self-managed and Elastic Cloud Hosted deployments, the otel appender ships the ECS audit schema fields unchanged.

url.original is written when url.scheme, url.domain, and url.path are all non-empty strings. The value is scheme://domain/path, as in https://www.elastic.co/search. url.scheme, url.domain, url.path, url.port, and url.query are removed from the log record.

http.request.method uses uppercase values, such as GET, POST, PUT, and DELETE.

user.id is the user's login name, the same value as user.name. When the event has no login name, the log record omits user.id.

user.domain is the name of the Elasticsearch realm that authenticated the user. It is present on successful user_login events and on events logged for authenticated requests. Events that do not carry the realm, such as user_logout and session_cleanup, omit it even when user.name is set.

When the event has no event.type, the log record sets event.type to ["access"]. When the event has no log.type, the log record sets log.type to audit.

The log resource includes only service.name, set to serverless-kibana, and service.type, set to kibana, so detected attributes such as host.name stay off the resource. project.id is written on each log record rather than on the resource. service.version is removed from the log record.