Elastic Cloud Integration
Version 0.1.2 (View all)
Subscription level
What's this?		 Platinum
Developed by
What's this?		 Elastic
Minimum Kibana version(s) 9.6.0
The Elastic Cloud integration v0.1.2 is in technical preview

To use pre-release integrations, go to the Integrations page in Kibana, scroll down, and toggle on the Display beta integrations option.

The Elastic Cloud integration installs Elasticsearch mappings, an ingest pipeline, and Kibana dashboards for logs that Elastic Cloud pushes into a destination project. The first data stream is serverless audit logs. This package does not collect data with Elastic Agent.

Use it to search and visualize audit activity from Elasticsearch and Kibana in your serverless projects, such as authentication, data access, security configuration changes, and saved object changes.

This integration requires Kibana 9.6.0 or later, or Elastic Cloud Serverless.

  1. You install this package's Elasticsearch and Kibana assets on the destination project.
  2. Elastic Cloud writes serverless audit events in OpenTelemetry format to the logs-elastic_cloud.serverless_audit.otel-* data stream.
  3. The package ingest pipeline copies the forwarded client IP to client.ip and enriches it with GeoIP.
  4. The package dashboards visualize the events.

There is no Elastic Agent input, poll interval, or webhook listener.

The Elastic Cloud integration processes the following logs:

  • Serverless audit — Elasticsearch and Kibana audit events from Elastic Cloud Serverless projects, in OpenTelemetry log format.
  • Monitor authentication successes and failures by user, API key, and realm
  • Investigate access to Elasticsearch indices, including system indices
  • Review security configuration changes and Kibana saved object changes
  • Reconstruct Kibana sessions and cross-space activity for an actor
  • Review client IP addresses and geography when GeoIP is available

These events contain restricted data such as user names, email addresses, and IP addresses. Limit Kibana and index access accordingly.

  • An Elastic Cloud Serverless project to receive the audit logs
  • This package installed on that destination project before the first audit document is written

This integration does not use Elastic Agent. Do not add it to an agent policy for collection. Install assets only.

In Kibana on the destination project:

  1. Go to Management → Integrations.
  2. Search for Elastic Cloud.
  3. Click Add Elastic Cloud.
  4. Click Install assets only (no agent policy needed).
  5. Confirm installation.

This installs:

  • Index templates for logs-elastic_cloud.serverless_audit.otel-*
  • Ingest pipeline for the elastic_cloud.serverless_audit data stream
  • Field mappings for the GeoIP enrichment of client.ip
  • The [Audit] dashboards, saved searches, and visualizations
  1. Generate audit activity in a serverless project, such as signing in to Kibana or editing a dashboard.
  2. In Discover, query FROM logs-elastic_cloud.serverless_audit.otel-*.
  3. Confirm documents have @timestamp, attributes.event.action, and data_stream.dataset: elastic_cloud.serverless_audit.otel.
  4. Open [Audit] 🎛️ Command Center and confirm panels populate.

For help with Elastic ingest tools, check Common problems.

No events in the dashboards

  • Confirm the assets were installed on the destination project before audit delivery was turned on.
  • Confirm documents are written to a logs-elastic_cloud.serverless_audit.otel-* data stream.

Missing GeoIP fields

Private or documentation-range IPs do not resolve. If the lookup fails, the error is stored in error.message.

For more information on architectures that can be used for scaling this integration, check the Ingest Architectures documentation.

Delivery is a control-plane push into your destination project. There is no customer collector to scale.

The serverless_audit data stream stores one OpenTelemetry log record per audit event. Audit fields are kept under attributes.* and resource.attributes.* and are mapped by the built-in OpenTelemetry templates.

Exported fields
Field Description Type
@timestamp Date/time when the event originated. This is the date/time extracted from the event, typically representing when the event was generated by the source. If the event source has no original timestamp, this value is typically populated by the first time the event was received by the pipeline. Required field for all events. date
client.geo.city_name City name. keyword
client.geo.continent_name Name of the continent. keyword
client.geo.country_iso_code Country ISO code. keyword
client.geo.country_name Country name. keyword
client.geo.location Longitude and latitude. geo_point
client.geo.region_iso_code Region ISO code. keyword
client.geo.region_name Region name. keyword
client.ip IP address of the client (IPv4 or IPv6). ip
data_stream.dataset The field can contain anything that makes sense to signify the source of the data. Examples include nginx.access, prometheus, endpoint etc. For data streams that otherwise fit, but that do not have dataset set we use the value "generic" for the dataset value. event.dataset should have the same value as data_stream.dataset. Beyond the Elasticsearch data stream naming criteria noted above, the dataset value has additional restrictions: * Must not contain - * No longer than 100 characters constant_keyword
data_stream.namespace A user defined namespace. Namespaces are useful to allow grouping of data. Many users already organize their indices this way, and the data stream naming scheme now provides this best practice as a default. Many users will populate this field with default. If no value is used, it falls back to default. Beyond the Elasticsearch index naming criteria noted above, namespace value has the additional restrictions: * Must not contain - * No longer than 100 characters constant_keyword
data_stream.type An overarching type for the data stream. Currently allowed values are "logs" and "metrics". We expect to also add "traces" and "synthetics" in the near future. constant_keyword
error.message Error message. match_only_text
event.kind This is one of four ECS Categorization Fields, and indicates the highest level in the ECS category hierarchy. event.kind gives high-level information about what type of information the event contains, without being specific to the contents of the event. For example, values of this field distinguish alert events from metric events. The value of this field can be used to inform how these kinds of events should be handled. They may warrant different retention, different access control, it may also help understand whether the data is coming in at a regular interval or not. keyword

This package has no Elastic Agent inputs.

Changelog
Version Details Minimum Kibana version
0.1.2 Enhancement (View pull request)
Nullify unmapped api_key fields in Kibana queries and replace the audit logs search with an unfiltered event list.		 9.6.0
0.1.1 Enhancement (View pull request)
Query Kibana assets with ECS field names and add an audit logs saved search.		 —
0.1.0 Enhancement (View pull request)
Initial release of the Elastic Cloud integration with an assets-only serverless audit data stream.		 —