Scripting and security

Painless and Elasticsearch implement layers of security to build a defense in depth strategy for running scripts safely.

Painless uses a fine-grained allowlist. Anything that is not part of the allowlist results in a compilation error. This capability is the first layer of security in a defense in depth strategy for scripting.

The second layer of security is the Java Security Manager. As part of its startup sequence, Elasticsearch enables the Java Security Manager to limit the actions that portions of the code can take. Painless uses the Java Security Manager as an additional layer of defense to prevent scripts from doing things like writing files and listening to sockets.

Elasticsearch uses seccomp in Linux, Seatbelt in macOS, and ActiveProcessLimit on Windows as additional security layers to prevent Elasticsearch from forking or running other processes.

You can modify the following script settings to restrict the type of scripts that are allowed to run, and control the available contexts that scripts can run in. To implement additional layers in your defense in depth strategy, follow the Elasticsearch security principles.

Elasticsearch supports two script types: inline and stored. By default, Elasticsearch is configured to run both types of scripts. To limit what type of scripts are run, set script.allowed_types to inline or stored. To prevent any scripts from running, set script.allowed_types to none.

For example, to run inline scripts but not stored scripts:

script.allowed_types: inline

By default, all script contexts are permitted. Use the script.allowed_contexts setting to specify the contexts that are allowed. To specify that no contexts are allowed, set script.allowed_contexts to none.

For example, to allow scripts to run only in scoring and update contexts:

script.allowed_contexts: score, update