Update scripts/security docs for sandboxed world (#23977)

Drops any mention of non-sandboxed scripting languages other than a
brief "we don't support them and we shouldn't because A and B"
statement.

Relates to #23930
This commit is contained in:
Nik Everett 2017-04-11 14:55:57 -04:00 committed by GitHub
parent 5cace8e48a
commit c17bee571f
1 changed files with 5 additions and 6 deletions

View File

@ -51,12 +51,11 @@ Bad:
[[modules-scripting-security-do-no-weaken]]
=== Do not weaken script security settings
By default Elasticsearch will run inline, stored, and filesystem scripts for
sandboxed languages, namely the scripting language Painless, the template
the builtin languages, namely the scripting language Painless, the template
language Mustache, and the expression language Expressions. These *ought* to be
safe to expose to trusted users and to your application servers because they
have strong security sandboxes. By default Elasticsearch will only run
filesystem scripts for non-sandboxed languages and enabling them is a poor
choice because:
have strong security sandboxes. The Elasticsearch committers do not support any
non-sandboxed scripting languages and using any would be a poor choice because:
1. This drops a layer of security, leaving only Elasticsearch's builtin
<<modules-scripting-other-layers, security layers>>.
2. Non-sandboxed scripts have unchecked access to Elasticsearch's internals and
@ -130,8 +129,8 @@ in the following form: `${pluginName}_${operation}`.
The following example disables scripting for `update` and `plugin` operations,
regardless of the script source or language. Scripts can still be executed
from sandboxed languages as part of `aggregations`, `search` and plugins
execution though, as the above defaults still get applied.
as part of `aggregations`, `search` and plugins execution though, as the above
defaults still get applied.
[source,yaml]
-----------------------------------