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:
parent
5cace8e48a
commit
c17bee571f
|
@ -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]
|
||||
-----------------------------------
|
||||
|
|
Loading…
Reference in New Issue