---
title: OpenSearch (AWS OpenSearch Service) connector
description: Use the OpenSearch connector to manage Alerting monitors and alerts, Security Analytics detector alerts and findings, and search and index documents.
url: https://docs-v3-preview.elastic.dev/elastic/kibana/tree/main/reference/connectors-kibana/opensearch-aws-opensearch-service-action-type
products:
  - Kibana
applies_to:
  - Elastic Cloud Serverless: Preview
  - Elastic Stack: Planned
---

# OpenSearch (AWS OpenSearch Service) connector
The OpenSearch connector calls the [Alerting](https://docs.opensearch.org/latest/observing-your-data/alerting/api/) and [Security Analytics](https://docs.opensearch.org/latest/security-analytics/api-tools/alert-finding-api/) plugin APIs, plus core document search/index APIs, so a workflow or agent can triage alerts, manage monitors, and read or write cluster data. It works against both a managed [Amazon OpenSearch Service](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/what-is.html) domain and a self-managed OpenSearch (or Elasticsearch with a compatible security setup) cluster.

## Create connectors in Kibana

You can create connectors in **Stack Management > Connectors**.

### Connector configuration

OpenSearch connectors have the following configuration properties:
<definitions>
  <definition term="Endpoint URL">
    The domain or cluster endpoint URL. For AWS OpenSearch Service, use the auto-generated domain endpoint, for example `https://search-my-domain-abc123.us-east-1.es.amazonaws.com` — a custom CNAME endpoint cannot be used with AWS access key/secret auth, because request signing derives the AWS region from this hostname. For a self-managed cluster, use its full URL, for example `https://opensearch.example.com:9200`.
  </definition>
</definitions>


### Authentication

**AWS access key (Amazon OpenSearch Service)**
<definitions>
  <definition term="Access Key ID">
    An IAM access key with `es:ESHttpGet`, `es:ESHttpPost`, `es:ESHttpPut`, and `es:ESHttpDelete` permissions on the domain. Every request is signed with Signature Version 4 (SigV4).
  </definition>
  <definition term="Secret Access Key">
    The AWS IAM secret access key paired with the access key ID above.
  </definition>
</definitions>

**Username and password (self-managed cluster)**
<definitions>
  <definition term="Username">
    An OpenSearch internal user, or a user whose backend role is mapped to a role with the alerting and security-analytics cluster permissions this connector's actions use, plus read/write on the indices you search or index into.
  </definition>
  <definition term="Password">
    The password for that user.
  </definition>
</definitions>


## Test connectors

You can test connectors when you create or edit the connector in Kibana. The test calls `GET _cluster/health` to verify connectivity and that the credentials can authenticate against the cluster.

## Connector actions

The OpenSearch connector has the following actions:
<definitions>
  <definition term="acknowledgeAlert">
    Acknowledge one or more active alerts (`alertIds`) on a monitor (`monitorId`) so they stop re-notifying. Alerts already `COMPLETED`, `ERROR`, or `ACKNOWLEDGED` come back in the response's `failed` list.
  </definition>
  <definition term="getAlerts">
    List Alerting alerts across all monitors, or for one monitor (`monitorId`), optionally filtered by `alertState` or `severityLevel`.
  </definition>
  <definition term="executeMonitor">
    Run a monitor (`monitorId`) immediately instead of waiting for its schedule. Set `dryrun` to preview trigger results without sending notification actions.
  </definition>
  <definition term="getMonitor">
    Fetch a monitor's full definition (schedule, inputs, triggers) and enabled state by `monitorId`.
  </definition>
  <definition term="enableMonitor / disableMonitor">
    Resume or suspend scheduled evaluation of a monitor (`monitorId`) without deleting it — useful for silencing a known-noisy monitor during a maintenance window and restoring it afterward.
  </definition>
  <definition term="searchMonitors">
    Search for monitors by `name`, source `index`, or `enabled` state. Omit all filters to list monitors.
  </definition>
  <definition term="createMonitor">
    Create a new query-level, bucket-level, or doc-level monitor (`monitorType`) with a `schedule`, `inputs`, and `triggers`. The `inputs`/`triggers` shape follows the [OpenSearch monitor definition](https://docs.opensearch.org/latest/observing-your-data/alerting/api/#create-a-query-level-monitor) and varies by monitor type.
  </definition>
  <definition term="updateMonitor">
    Update an existing monitor's (`monitorId`) name, schedule, inputs, or triggers. Only the fields you provide are changed. Everything else on the monitor is preserved.
  </definition>
  <definition term="deleteMonitor">
    Permanently delete a monitor (`monitorId`). This does not delete alerts already raised by the monitor.
  </definition>
  <definition term="searchDetectors">
    Search for Security Analytics detectors by `name` or `detectorType`. Use this to find a detector ID before calling `getDetectorFindings` or `acknowledgeDetectorAlert`.
  </definition>
  <definition term="acknowledgeDetectorAlert">
    Acknowledge one or more active alerts (`alertIds`) raised by a Security Analytics detector (`detectorId`). This is a separate alert stream from the Alerting-plugin actions above.
  </definition>
  <definition term="getDetectorFindings">
    Retrieve Security Analytics findings (matched Sigma rules or threat-intelligence hits), filtered by `detectorId` or `detectorType`, and optionally by `severity` or `detectionType`.
  </definition>
  <definition term="listIndices">
    List indices and their health, status, and document/storage size, optionally filtered by name or `pattern`. Use this to discover which index to pass to `runQuery` or `indexDocument`.
  </definition>
  <definition term="runQuery">
    Run a search query DSL request body (`query`) against an `index`, returning the raw `_search` response.
  </definition>
  <definition term="indexDocument">
    Write a `document` to an `index`. Provide an explicit `id` to create or fully replace a specific document, or omit it to let OpenSearch generate one.
  </definition>
</definitions>

<note>
  The Alerting plugin's monitor update endpoint fully replaces a monitor's definition. `enableMonitor`, `disableMonitor`, and `updateMonitor` first read the current monitor and its `seq_no`/`primary_term`, then write back the full definition with only your requested change applied, using those values to avoid clobbering a concurrent change.
</note>


## Get API credentials

**Amazon OpenSearch Service (AWS access key)**
1. Sign in to the [AWS IAM console](https://console.aws.amazon.com/iam/).
2. Create (or choose) an IAM user or role dedicated to this connector.
3. Attach a policy granting `es:ESHttpGet`, `es:ESHttpPost`, `es:ESHttpPut`, and `es:ESHttpDelete` on the domain's ARN (or narrower actions if you only need a subset of the connector's actions).
4. Create an access key for that user (**Security credentials** > **Access keys** > **Create access key**), or use a role's temporary credentials.
5. Copy the domain's endpoint (**Amazon OpenSearch Service console** > your domain > **Domain endpoint**), the **Access key ID**, and the **Secret access key**, and enter them when configuring the connector in Kibana.

**Self-managed cluster (username and password)**
1. In OpenSearch Dashboards, go to **Security** > **Internal users** and create a user, or identify an existing one.
2. Go to **Security** > **Roles** and map that user (directly, or through a backend role) to a role granting the cluster permissions the actions you plan to use require (for example `cluster:admin/opendistro/alerting/*` and `cluster:admin/opensearch/securityanalytics/*`), plus read/write index permissions on the indices you search or index into.
3. Enter the cluster's endpoint URL, username, and password when configuring the connector in Kibana.