Connecting to Elasticsearch

An Elasticsearch connection is a profile like any other: a list of node URLs or an Elastic Cloud ID, a sign-in method, a TLS mode, and optionally an SSH tunnel or a proxy. At connect, Querybara reads GET / for the server’s version and distribution and turns on only the features that cluster has, so the same profile works from Elasticsearch 7.17 to 9.x.

Add a connection

1. Open the Connection actions menu at the top of the sidebar and choose New connection. The keys Ctrl + Shift + N do the same (on macOS, Cmd + Shift + N).
2. Under Choose a database, pick Elasticsearch and choose Next, or double-click it.
3. On the General tab, enter a Name. Under Connect with, pick Node URLs or Cloud ID (Elastic Cloud).
4. For node URLs, enter each node’s http:// or https:// address with its HTTP port. The first one starts as http://localhost:9200. Choose Add node URL to list more nodes; requests go to the nodes in turn.
5. For a Cloud ID, paste it into Cloud ID. It comes from the deployment page in Elastic Cloud, and Querybara connects to its Elasticsearch endpoint over TLS.
6. Pick the Authentication method, which starts at None, and fill in its fields (see below).
7. For an https:// URL, pick the mode on the TLS tab (see below).
8. Choose Test Connection, then Save.

You can also paste a URL such as https://[email protected]:9200 into Paste a URI to fill the form and choose Fill from URI. The box is on the first step, and the URI button brings it back on the form. A node URL must not hold a password: Querybara refuses it and asks you to enter the password in the password field instead.

A URL behind a reverse proxy can carry a path prefix, such as https://example.com/es.

Sign-in methods

Authentication	What you enter
None	Nothing. For clusters without security.
User and password (basic)	User and the password.
API key	The encoded key Elasticsearch shows when it creates one, or its id and key as id:api_key.
Bearer token	Token, sent as Authorization: Bearer, such as an OAuth2 or JWT access token.

The password, API key and token are secrets: they are kept the way the profile’s password storage says, and Querybara redacts them from error messages.

TLS

TLS is off for a new connection. A Cloud ID, or a pasted https:// URL, turns it on. The URL scheme decides whether TLS is used: https:// connects with TLS in the mode chosen under TLS mode on the TLS tab, and http:// needs Disable TLS. The four modes are the same as for other engines:

TLS mode	What it checks
Verify certificate and host name	The certificate chain and the node’s host name
Verify certificate only	The certificate chain
Require TLS, no verification	Nothing; the connection is encrypted
Disable TLS	No TLS (http:// URLs)

With TLS on, you can give a CA certificate, and a Client certificate and Client key.

Sniffing

Discover the other nodes of the cluster (sniffing) is off by default. When it is on, Querybara also sends requests to the addresses the nodes publish, which must be reachable from your computer. Sniffing is not used for a Cloud ID or through an SSH tunnel or proxy.

Through an SSH tunnel or proxy

Set up a tunnel on the SSH tab, or a proxy on the Proxy tab. Through either, Querybara reaches one node: list a single URL, or use a Cloud ID. It does not discover other nodes through a tunnel. Requests keep the node’s own name in the Host header and for TLS verification, so certificates issued for the node still verify.

Write rules

Every request is classified before it is sent. GET and HEAD requests read, and so do known read endpoints whatever their method (such as POST _search); everything else writes. The profile’s settings then apply, the same way they do for SQL:

• A profile with Read-only ticked on the Advanced tab refuses writes. Searches, SQL, ES|QL, allocation explanations and pipeline simulations still run.
• Destructive requests always ask first: deleting indices or documents, closing indices, delete by query, force merge, bulk requests with deletes, index blocks and snapshot deletes.
• A profile whose Environment is Production, or with Confirm every write ticked, asks before every write.

The confirmation shows the exact request. The connection host checks the rules again and refuses a write the page did not confirm.

From the command line

querybara test checks a connection step by step, and querybara query sends console requests to an http:// or https:// URL or a saved profile.

querybara test "https://[email protected]:9200"
querybara query "https://[email protected]:9200" -e 'GET _cluster/health'

The command line applies the same write rules; --yes confirms requests that ask.

Related

• Explorer
• Console