mirror of
https://github.com/elastic/elasticsearch.git
synced 2025-04-24 23:27:25 -04:00
b9ad9860af
* [DOCS] Add ES security principles * Incorporating review feedback * More changes from review feedback * Fix cross-link to Painless guide * Clarify callout text * Add information about elasticsearch user * Minor wording edits * Consolidate Java Security Manager description, plus other edits * Clarify not running as root Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
63 lines
2.6 KiB
Text
63 lines
2.6 KiB
Text
[[modules-scripting-security]]
|
|
== Scripting and security
|
|
Painless and {es} 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 https://www.oracle.com/java/technologies/javase/seccodeguide.html[Java Security Manager]. As part of its startup
|
|
sequence, {es} enables the Java Security Manager to limit the actions that
|
|
portions of the code can take. <<modules-scripting-painless,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.
|
|
|
|
{es} uses
|
|
{wikipedia}/Seccomp[seccomp] in Linux,
|
|
https://www.chromium.org/developers/design-documents/sandbox/osx-sandboxing-design[Seatbelt]
|
|
in macOS, and
|
|
https://msdn.microsoft.com/en-us/library/windows/desktop/ms684147[ActiveProcessLimit]
|
|
on Windows as additional security layers to prevent {es} 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
|
|
{painless}/painless-contexts.html[contexts] that scripts can run in. To
|
|
implement additional layers in your defense in depth strategy, follow the
|
|
<<es-security-principles,{es} security principles>>.
|
|
|
|
[[allowed-script-types-setting]]
|
|
[discrete]
|
|
=== Allowed script types setting
|
|
|
|
{es} supports two script types: `inline` and `stored`. By default, {es} 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`.
|
|
|
|
IMPORTANT: If you use {kib}, set `script.allowed_types` to `both` or `inline`.
|
|
Some {kib} features rely on inline scripts and do not function as expected
|
|
if {es} does not allow inline scripts.
|
|
|
|
For example, to run `inline` scripts but not `stored` scripts:
|
|
|
|
[source,yaml]
|
|
----
|
|
script.allowed_types: inline
|
|
----
|
|
|
|
[[allowed-script-contexts-setting]]
|
|
[discrete]
|
|
=== Allowed script contexts setting
|
|
|
|
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:
|
|
|
|
[source,yaml]
|
|
----
|
|
script.allowed_contexts: score, update
|
|
----
|