This functionality is experimental and may be changed or removed completely in a future release. Elastic will take a best effort approach to fix any issues, but experimental features are not subject to the support SLA of official GA features.
Elasticsearch SQL integrates with security, if this is enabled on your cluster. In such a scenario, Elasticsearch SQL supports both security at the transport layer (by encrypting the communication between the consumer and the server) and authentication (for the access layer).
In case of an encrypted transport, the SSL/TLS support needs to be enabled in Elasticsearch SQL to properly establish communication with Elasticsearch. This is done by setting the
ssl property to
true or by using the
https prefix in the URL.
Depending on your SSL configuration (whether the certificates are signed by a CA or not, whether they are global at JVM level or just local to one application), might require setting up the
truststore, that is where the credentials are stored (
keystore - which typically stores private keys and certificates) and how to verify them (
truststore - which typically stores certificates from third party also known as CA - certificate authorities).
Typically (and again, do note that your environment might differ significantly), if the SSL setup for Elasticsearch SQL is not already done at the JVM level, one needs to setup the keystore if the Elasticsearch SQL security requires client authentication (PKI - Public Key Infrastructure), and setup
truststore if SSL is enabled.
The authentication support in Elasticsearch SQL is of two types:
- Set these through
- Use X.509 certificates to authenticate Elasticsearch SQL to Elasticsearch. For this, one would need to setup the
keystorecontaining the private key and certificate to the appropriate user (configured in Elasticsearch) and the
truststorewith the CA certificate used to sign the SSL/TLS certificates in the Elasticsearch cluster. That is, one should setup the key to authenticate Elasticsearch SQL and also to verify that is the right one. To do so, one should set the
ssl.truststore.locationproperties to indicate the
truststoreto use. It is recommended to have these secured through a password in which case
ssl.truststore.passproperties are required.
Lastly, one the server one need to add a few permissions to
users so they can run SQL. To run SQL a user needs
indices:admin/get permissions at minimum while some parts of
the API require
The following example configures a role that can run SQL in JDBC querying the
cli_or_drivers_minimal: cluster: - "cluster:monitor/main" indices: - names: test privileges: [read, "indices:admin/get"] - names: bort privileges: [read, "indices:admin/get"]