There are a few ways to do this.

This assumes that you are running elasticsearch on a different server than you are running the fusionauth instances. If they are on the same server, you should be fine, as that is the default configuration.

The first is at the network level, using a firewall or something like security groups on AWS. If you are doing this, you can configure the server that elasticsearch is installed on to accept requests only from the server that FusionAuth is installed on.

The second is to use basic authentication. That is, set fusionauth-search.servers in the fusionauth.properties file, or the FUSIONAUTH_SEARCH_SERVERS environment variable to include the basic username and password. https://user:password@example.com. And make sure to set up elastic to use basic auth, using whatever authentication source you'd like. (You could even go meta and have elasticsearch auth the user against the fusionauth instance 🙂 ).

Further discussion here.

It depends on the issue, but there are two things you can do. Note that FusionAuth typically sends the query you post to the /api/user/search endpoint with the query parameter straight through to Elasticsearch

First, ensure you are running elasticsearch and not the database search engine.

Then, for some queries you can see the generate ElasticSearch query strings by clicking on the 'advanced' option in the user search area of the admin UI. This can be helpful.

Finally, try running the query directly against elasticsearch and seeing if it works. Here are examples which will pull back all the data in your elasticsearch cluster (beware!).

curl -XPOST -H 'Content-type: application/json' "http://localhost:9021/_search" -d' { "query": { "match_all": {} } }'

or, if you have the query stored in query.json

curl -XPOST -H 'Content-type: application/json' "http://localhost:9021/_search" -d@query.json

Turns out that I didn't have much disk space.

Saw this in the FA search logs:

{"type": "server", "timestamp": "2020-06-10T14:34:28,378Z", "level": "WARN", "component": "o.e.c.r.a.DiskThresholdMonitor", "cluster.name": "FusionAuth", "node.name": "ubuntu-xenial", "message": "flood stage disk watermark [95%] exceeded on [NE_DhFssRru-H5oIiLwBjA][ubuntu-xenial][/usr/local/fusionauth/data/search/esv6/nodes/0] free: 887.9mb[4.4%], all indices on this node will be marked read-only", "cluster.uuid": "LGdaij30RrS4FZbgsT_6KA", "node.id": "NE_DhFssRru-H5oIiLwBjA" }

Deleting some things from my hard drive lowered my disk usage below 95% and I no longer saw the message.

If you are using https://aws.amazon.com/elasticsearch-service/ for your Elasticsearch server, you can access it via AWS APIs and use IAM to control access: https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-ac.html

However, FusionAuth doesn't currently support the AWS signature for Elasticsearch requests.

The recommended way of securing such clusters is to place it in a private subnet and restricting traffic to it using a security group. More information: https://fusionauth.io/docs/v1/tech/installation-guide/securing#fusionauth-search

If you have to make it public to make it accessible to resources outside if AWS you could use a source IP lock, a VPN, basic auth if AWS supports it, or you could proxy the request perhaps to another endpoint that can build the AWS sig v4 header.

Here's a doc about how to switch search engines: https://fusionauth.io/docs/v1/tech/tutorials/switch-search-engines

Note that with version 1.16.x, elastic search is no longer required to run FusionAuth. More here about how you might make the choice: https://fusionauth.io/community/forum/topic/67/what-is-the-advantage-of-using-elasticsearch-as-the-search-engine