While Elasticsearch contributors make every effort to prevent scripts from
running amok, security is something best done in
layers because
all software has bugs and it is important to minimize the risk of failure in
any security layer. Find below rules of thumb for how to keep Elasticsearch
from being a vulnerability.

First and foremost, never run Elasticsearch as the root user as this would
allow any successful effort to circumvent the other security layers to do
anything on your server. Elasticsearch will refuse to start if it detects
that it is running as root but this is so important that it is worth double
and triple checking.

Do not expose Elasticsearch directly to users, instead have an application
make requests on behalf of users. If this is not possible, have an application
to sanitize requests from users. If that is not possible then have some
mechanism to track which users did what. Understand that it is quite possible
to write a _search that overwhelms Elasticsearch and brings down
the cluster. All such searches should be considered bugs and the Elasticsearch
contributors make an effort to prevent this but they are still possible.

Do not expose Elasticsearch to the Internet, instead have an application
make requests on behalf of the Internet. Do not entertain the thought of having
an application "sanitize" requests to Elasticsearch. Understand that it is
possible for a sufficiently determined malicious user to write searches that
overwhelm the Elasticsearch cluster and bring it down. For example:

In addition to user privileges and script sandboxing Elasticsearch uses the
Java Security Manager
and native security tools as additional layers of security.

As part of its startup sequence Elasticsearch enables the Java Security Manager
which limits the actions that can be taken by portions of the code. Painless
uses this to limit the actions that generated Painless scripts can take,
preventing them from being able to do things like write files and listen to
sockets.

Below this we describe the security settings for scripts and how you can
change from the defaults described above. You should be very, very careful
when allowing more than the defaults. Any extra permissions weakens the total
security of the Elasticsearch deployment.

By default all script types are allowed to be executed. This can be modified using the
setting script.allowed_types. Only the types specified as part of the setting will be
allowed to be executed. To specify no types are allowed, set script.allowed_types to
be none.

script.allowed_types: inline

This will allow only inline scripts to be executed but not stored scripts
(or any other types).

By default all script contexts are allowed to be executed. This can be modified using the
setting script.allowed_contexts. Only the contexts specified as part of the setting will
be allowed to be executed. To specify no contexts are allowed, set script.allowed_contexts
to be none.

script.allowed_contexts: search, update

This will allow only search and update scripts to be executed but not
aggs or plugin scripts (or any other contexts).