Understand an index before querying it
Discover available indices and aliases, inspect a mapping, then build a query that uses the actual field types.
Databases · MCP Firewall integration
Separate OpenSearch reads from changes that need your approval.
Put your OpenSearch connection behind GateRook’s MCP Firewall. Let AI discover indices, inspect mappings and search documents through recognized read APIs. Keep writes, bulk operations and administration in Approval mode to review the exact request before execution; server permissions still determine its allowed targets.
Connection in GateRook
stage-opensearch
OpenSearch
stage / QA- Connector type
- OpenSearch
- Name / environment
- stage-opensearch / stage
- Server URL
- https://search.stage.example.test:9200
- Authentication
- Username and password
The security boundary
Your AI requests a tool. GateRook checks its mode and policy, requires approval when configured, and resolves credentials locally before an allowed call runs.
Understand the request flowAsk your AI
Count the pending orders in our stage OpenSearch cluster. Use orders-stage and do not change any documents.
opensearch_query · arguments
{
"connection": "stage-opensearch",
"method": "POST",
"path": "/orders-stage/_count",
"body": {
"query": {
"term": {
"status": "pending"
}
}
}
}Example result
{
"status": 200,
"contentType": "application/json",
"body": {
"count": 7,
"_shards": {
"total": 1,
"successful": 1,
"failed": 0
}
},
"truncated": false
}Sample configuration and output, not a live connection. Replace example values with your environment. Tool names here are connector names; the endpoint may expose a connection-specific name.
Useful access. Explicit control.
What you can do with OpenSearch and AI
Investigate application state
Search documents or run aggregations to compare indexed orders with API or database state. Read tools also support recognized cluster diagnostics.
Review a deliberate cluster change
Propose a document update, bulk request or index setting through opensearch_request. In Approval mode, inspect its method, target, parameters and body before allowing it.
From service to MCP Firewall
How to connect OpenSearch
GateRook must be running on a computer that can reach your service. Open Connections, choose Add connection, and select OpenSearch. Give the connection a name and environment.
New to GateRook? Start with the full setup guide.Prepare the server identity
Grant a dedicated user or key only the index and cluster permissions needed for the task. The OpenSearch database connector uses the server's REST API; it does not add a local index allowlist.
Add the OpenSearch database connection
Open Connections, choose Add connection, then OpenSearch under Databases. Set the connection name, environment and server URL.
Configure authentication and TLS
Enter credentials in GateRook, outside the AI conversation. For AWS signing, select the region, service and credential source. Add a private CA certificate when required by the cluster.
Test access before exposing tools
Run Test connection to check cluster information and available index discovery. This check does not execute writes or prove every API permission. Start with the two read tools and leave the request tool Off unless you need reviewed operations.
Choose the endpoint and tool modes
Add the tested connection to an endpoint. In Tools & policies, enable only the tools needed for the task. Start with Read only where supported; use Approval for any selected mutation and leave other tools Off. A connection alone does not grant an AI client access.
Connect your AI and verify the first call
In Clients, choose your AI app and endpoint, review the connection details, and connect. Try this guide’s example in Playground before asking your AI. Open Activity to inspect the tool, target, decision and returned result. The getting started guide covers this shared flow.
Connection settings
Configure OpenSearch in GateRook
These are example values for the connection form. Enter credentials into GateRook’s secret fields, not into an AI prompt. Requirements and alternatives are noted per field.
| Setting | Example | How to use it |
|---|---|---|
Connector type | OpenSearch | Choose the dedicated OpenSearch connector under Databases in Add connection. |
Name / environment | stage-opensearch / stage | Keep this cluster connection separate from production and choose the endpoints that may use it. |
Server URL | https://search.stage.example.test:9200 | Use the server origin including its port. Do not enter a Dashboards URL, API path, credentials or query string. |
Authentication | Username and password | Other supported modes are API key, Bearer token, AWS request signing and No authentication. Choose a mode supported by your deployment. |
Username / password | ai_reader / Your secret | Use a server identity limited to the indices and operations you intend to expose. Enter the password in GateRook's protected field. |
CA certificate (PEM) | Your private CA certificate, if needed | For a server using a private certificate authority, supply its PEM CA certificate. TLS hostname verification remains enabled. |
AWS request signing | eu-central-1 / OpenSearch Service / AWS profile | For an AWS-hosted deployment, select its region, OpenSearch Service (es) or OpenSearch Serverless (aoss), and an authorized local AWS profile or access key. Optional AssumeRole settings are available. |
Know what you expose
OpenSearch tools and access boundaries
The connector defines available operations. GateRook’s MCP Firewall enforces endpoint modes and connection policies before an AI client can use them.
| Tool | Purpose | Access behavior |
|---|---|---|
opensearch_indices | Resolve the indices, aliases and data streams visible to the server identity. An optional index expression narrows the discovery request. | Read only by default |
opensearch_query | Use recognized read APIs for JSON Query DSL, aggregations, multi-search, document retrieval, mappings, settings and cluster diagnostics. | Read only by default |
opensearch_request | Submit an exact REST request, including document writes, bulk operations, index or cluster settings, snapshots, SQL, PPL and plugin APIs. Supports JSON and NDJSON bodies. | Approval by default, including GET |
Before you enable access
- Server permissions constrain all REST targets, including indices named inside a request body. The dedicated database connector does not apply the legacy Logs connector's index patterns, time range or fixed Lucene filter.
- opensearch_query only accepts recognized read routes. SQL, PPL, plugin routes and other unverified APIs use opensearch_request, even when their HTTP method is GET.
- opensearch_request defaults to Approval. Explicitly choosing endpoint Bypass permits requests without a prompt; keep Approval or Off when human review is required.
- Requests stay on the configured server; absolute URLs, path traversal and fragments are rejected. The REST transport does not follow redirects or automatically retry requests.
- Request-size, response-size and execution limits apply. Check truncated results and shard failures before drawing conclusions.
GateRook stores local connection secrets encrypted and resolves them for connectors. Allowed tool results are returned to your AI client and may be processed by its provider. Scope the data you expose as well as the actions you allow.
Practical answers
OpenSearch connection questions
Use Test connection to isolate service access problems. Use Playground and Activity to inspect endpoint permissions and tool calls.
Is OpenSearch only a log-search integration?
No. The dedicated OpenSearch connector is in Databases and exposes index discovery, recognized read APIs and reviewed REST requests. You can query log documents as ordinary indexed data, as well as other application documents.
Can AI create or delete an index?
The request tool can call those APIs if the server identity has permission. It defaults to Approval, so you review the exact operation. Leave the tool Off or use a server identity without those permissions when such changes must be unavailable.
Can I use SQL, PPL or a plugin API?
Use opensearch_request. Those routes are not treated as verified reads, so they require approval by default. Availability and authorization depend on the APIs installed and permitted on your server.
What happened to logs_search and logs_tail?
Existing connections created with the legacy Logs connector can retain scoped OpenSearch log search and tail tools. The dedicated OpenSearch database connector exposes opensearch_indices, opensearch_query and opensearch_request instead; its REST access is governed by server permissions.
Does a successful connection test prove write access?
No. The full REST test checks cluster information and attempts index discovery without testing writes. Each later API request remains subject to server permissions.
Keep exploring
Extend control across your stack
Elasticsearch
Protect Elasticsearch access with GateRook. Keep credentials local, expose recognized read APIs and require review for writes and administrative requests.
PostgreSQL
Put PostgreSQL behind GateRook’s MCP Firewall. Follow the illustrated setup, scope AI queries, approve an UPDATE and inspect its Activity audit trail.
AWS CloudWatch Logs
Control CloudWatch Logs access through GateRook. Restrict regions and log groups, keep AWS credentials local and bound queries and returned results.
Your MCP Firewall. Your access rules.
Control AI access to OpenSearch.
Start with read-only access. Approve changes. Inspect the audit trail.