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.

Finally, scripts used in scripted metrics aggregations can be restricted to a defined list of scripts, or forbidden altogether. This can prevent users from running particularly slow or resource intensive aggregation queries.

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

By default, all scripts are permitted in scripted metrics aggregations. To restrict the set of allowed scripts, set search.aggs.only_allowed_metric_scripts to true and provide the allowed scripts using search.aggs.allowed_inline_metric_scripts and/or search.aggs.allowed_stored_metric_scripts.

To disallow certain script types, omit the corresponding script list (search.aggs.allowed_inline_metric_scripts or search.aggs.allowed_stored_metric_scripts) or set it to an empty array. When both script lists are not empty, the given stored scripts and the given inline scripts will be allowed.

The following example permits only 4 specific stored scripts to be used, and no inline scripts:

search.aggs.only_allowed_metric_scripts: true
search.aggs.allowed_inline_metric_scripts: []
search.aggs.allowed_stored_metric_scripts:
   - script_id_1
   - script_id_2
   - script_id_3
   - script_id_4

Conversely, the next example allows specific inline scripts but no stored scripts:

search.aggs.only_allowed_metric_scripts: true
search.aggs.allowed_inline_metric_scripts:
   - 'state.transactions = []'
   - 'state.transactions.add(doc.some_field.value)'
   - 'long sum = 0; for (t in state.transactions) { sum += t } return sum'
   - 'long sum = 0; for (a in states) { sum += a } return sum'
search.aggs.allowed_stored_metric_scripts: []