本地英文版地址: ../en/modules-scripting-security.html
虽然Elasticsearch的贡献者尽一切努力防止脚本失控，但安全是最好在layers中完成的事情，因为所有软件都有漏洞，最大限度地降低任何安全层中的失败风险是很重要的。 下面是一些避免Elasticsearch成为漏洞的经验法则。
不要以root身份运行
首先，也最重要的是，永远不要以root用户的身份运行Elasticsearch，因为这将允许任何成功绕过其他安全层的尝试在服务器上执行任何操作。
如果Elasticsearch检测到它以root用户身份运行，就会拒绝启动，但这非常重要，值得再三检查。
不要直接向用户公开Elasticsearch
不要直接向用户公开Elasticsearch，而是让一个应用程序代表用户发出请求。
如果这是不可能的，请使用一个应用程序来净化来自用户的请求。
如果这是不可能的，那么就需要一些机制来跟踪哪些用户做了什么。
要明白，编写一个_search来压垮Elasticsearch并关闭集群是很有可能的。
所有这样的搜索都应该被认为是缺陷，Elasticsearch的贡献者努力阻止这种情况，但它们仍然是可能的。
不要将Elasticsearch直接暴露在互联网上
不要将Elasticsearch暴露给互联网，而是让一个应用程序代表互联网发出请求。 不要考虑让应用程序“净化”对Elasticsearch的请求。 要知道，一个非常有决心的恶意用户可能会编写搜索，使Elasticsearch集群不堪重负，并使其崩溃。 例如：
好的做法：
- 用户在搜索框中键入文本，文本将被直接发送到匹配(match)、匹配短语(match phrase)、简单查询字符串或任何suggesters。
- 运行包含上述任何查询的脚本，该脚本是作为应用程序开发过程的一部分编写的。
-
使用用户提供的
params运行脚本。 - 用户操作使文档具有固定的结构。
坏的做法：
-
用户可以编写任意脚本、查询和
_search请求。 - 用户操作使文档具有用户定义的结构。
其他安全层
除了用户权限和脚本沙箱，Elasticsearch使用Java安全管理器和本地安全工具作为额外的安全层。
作为启动序列的一部分，Elasticsearch启用了Java安全管理器，它限制了部分代码可以采取的动作。 painless 使用这个来限制生成的 painless 脚本可以采取的动作，防止它们能够做像写文件和监听套接字这样的事情。
Elasticsearch在Linux中使用seccomp、在macOS中使用Seatbelt、在Windows中使用ActiveProcessLimit来防止 Elasticsearch fork或执行其他进程。
下面将会描述脚本的安全设置，以及如何改变上述的默认设置。 当允许超过默认值时，你应该非常非常小心。 任何额外的权限都会削弱Elasticsearch部署的整体安全性。
允许的脚本类型设置
默认情况下允许执行所有脚本类型。
这可以使用设置script.allowed_types来修改。
只允许执行设置中指定的类型。
若要指定不允许任何类型，请将script.allowed_types设置为none。
允许的脚本上下文设置
默认情况下，允许执行所有脚本上下文。
这可以使用设置script.allowed_contexts来修改。
只允许执行设置中指定的上下文。
要指定不允许任何上下文，请将script.allowed_contexts设置为none。