---
title: Elastic Cloud Integration
description: The Elastic Cloud integration installs Elasticsearch mappings, an ingest pipeline, and Kibana dashboards for logs that Elastic Cloud pushes into a destination...
url: https://docs-v3-preview.elastic.dev/elastic/integration-docs/tree/main/reference/elastic_cloud
products:
- Elastic integrations
applies_to:
- Serverless Observability projects: Preview
- Serverless Security projects: Preview
- Elastic Stack: Planned
---
# Elastic Cloud Integration
| | |
|-------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------|
| **Version** | 0.1.2 : Preview ([View all](#changelog)) |
| **Subscription level**[What's this?](https://www.elastic.co/subscriptions) | Platinum |
| **Developed by**[What's this?](https://docs-v3-preview.elastic.dev/elastic/integration-docs/tree/main/reference/developed-by) | Elastic |
| **Minimum Kibana version(s)** | 9.6.0 |
To use pre-release integrations, go to the **Integrations** page in Kibana, scroll down, and toggle on the _Display beta integrations_ option.
## Overview
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.
### Compatibility
This integration requires Kibana 9.6.0 or later, or Elastic Cloud Serverless.
### How it works
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.
## What data does this integration collect?
The Elastic Cloud integration processes the following logs:
- **Serverless audit** — Elasticsearch and Kibana audit events from Elastic Cloud Serverless projects, in OpenTelemetry log format.
### Supported use cases
- 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.
## What do I need to use this integration?
- An Elastic Cloud Serverless project to receive the audit logs
- This package installed on that destination project **before** the first audit document is written
## How do I deploy this integration?
### Agent-based deployment
This integration does not use Elastic Agent. Do not add it to an agent policy for collection. Install assets only.
### Onboard / configure
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
### Validation
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.
## Troubleshooting
For help with Elastic ingest tools, check [Common problems](https://www.elastic.co/docs/troubleshoot/ingest/fleet/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`.
## Scaling
For more information on architectures that can be used for scaling this integration, check the [Ingest Architectures](https://www.elastic.co/docs/manage-data/ingest/ingest-reference-architectures) documentation.
Delivery is a control-plane push into your destination project. There is no customer collector to scale.
## Reference
### Serverless audit
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 |
### Inputs used
This package has no Elastic Agent inputs.
## Changelog
| Version | Details | Minimum Kibana version |
|-----------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------|
| **0.1.2** | **Enhancement** ([View pull request](https://github.com/elastic/integrations/pull/22081))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](https://github.com/elastic/integrations/pull/22081))Query Kibana assets with ECS field names and add an audit logs saved search. | |
| **0.1.0** | **Enhancement** ([View pull request](https://github.com/elastic/integrations/pull/22081))Initial release of the Elastic Cloud integration with an assets-only serverless audit data stream. | |