安全限制
edit安全限制
edit插件
editElasticsearch 的插件基础设施在可扩展性方面非常灵活。虽然它为 Elasticsearch 提供了广泛的（通常是定制的）附加功能，但在安全性方面，这种高扩展性水平是有代价的。我们无法控制第三方插件的代码（无论是开源与否），因此我们无法保证它们与 Elastic Stack 安全功能的兼容性。出于这个原因，第三方插件在启用了安全功能的集群上不受官方支持。
通配符行为的更改
edit启用了安全功能的Elasticsearch集群将_all和其他通配符应用于当前用户具有权限的数据流、索引和别名，而不是集群上的所有数据流、索引和别名。
多文档API
edit当用户尝试访问其无权访问的非现有索引时，多获取和多词向量 API 会抛出 IndexNotFoundException。通过这样做，它们泄露了关于数据流或索引不存在的事实信息，而用户无权了解这些数据流或索引的任何信息。
过滤索引别名
edit由于使用别名时可能会泄露索引和字段名称中描述的限制，包含过滤器的别名并不是限制对单个文档访问的安全方式。Elastic Stack 安全功能提供了一种通过文档级别安全性功能来限制对文档访问的安全方式。
字段和文档级别安全限制
edit当用户的角色启用了数据流或索引的文档或字段级安全时：
-
用户无法执行写操作：
- The update API isn’t supported.
- Update requests included in bulk requests aren’t supported.
-
用户不能执行实际上使内容在另一个名称下可访问的操作，包括以下API中的操作：
-
如果以下任一条件为真，搜索请求的请求缓存将被禁用：
- The role query that defines document level security is templated using a stored script.
- The target indices are a mix of local and remote indices.
当用户的角色为数据流或索引启用了文档级安全时：
- 文档级安全不影响相关性评分使用的全局索引统计信息。这意味着评分是基于不考虑角色查询的情况下计算的。不匹配角色查询的文档永远不会被返回。
-
has_child和has_parent查询不支持作为角色定义中的查询参数。has_child和has_parent查询可以在启用文档级安全性的情况下用于搜索API。 -
日期数学表达式不能包含
now在 日期字段的范围查询中。 -
任何包含远程调用来获取查询数据的查询都不被支持，包括以下查询：
-
terms查询与术语查找 -
geo_shape查询与索引形状 -
percolate查询
-
- 如果指定了建议器并且启用了文档级安全性，则指定的建议器将被忽略。
- 如果启用了文档级安全性，则无法分析搜索请求。
- 如果启用了文档级安全性，术语枚举API不会返回术语。
虽然文档级安全措施可以防止用户查看受限文档，但仍然可以编写返回整个索引聚合信息的搜索请求。一个访问权限仅限于索引中特定文档的用户，仍然可以了解仅存在于不可访问文档中的字段名称和术语，并统计包含给定术语的不可访问文档的数量。
使用别名时可能会泄露索引和字段名称
edit在别名上调用某些 Elasticsearch API 可能会潜在地泄露用户无权访问的索引信息。例如，当您使用 _mapping API 获取别名的映射时，响应会包含别名所应用的每个索引的索引名称和映射。
在此限制得到解决之前，请避免使用包含机密或敏感信息的索引和字段名称。
LDAP 领域
edit目前，LDAP Realm不支持嵌套LDAP组的发现。例如，如果一个用户是group_1的成员，而group_1是group_2的成员，则只会发现group_1。然而，Active Directory Realm 确实支持传递组成员身份。
用户和API密钥的资源共享检查
edit通过异步搜索和滚动请求的结果可以由提交初始请求的同一用户或API密钥稍后检索。验证过程涉及比较用户名、认证领域类型以及（对于文件或本地以外的领域）领域名称。如果您使用API密钥提交了请求，则只有该密钥可以检索结果。此逻辑也有一些限制：
- 两个不同的领域可以在不同的节点上拥有相同的名字。这不是一种推荐的领域配置方式，因此资源共享检查不会尝试检测这种不一致性。
- 领域可以被重命名。当你提交一个异步搜索或滚动搜索，然后重命名领域并尝试检索结果时，这可能会导致资源共享检查的不一致性。因此，更改领域名称时应谨慎处理，因为它可能会引起不仅仅是资源共享检查的复杂问题。
- 对于由某些外部认证提供者支持的领域，用户名是动态计算的。例如，用户名可以从LDAP领域中的DN部分派生。从理论上讲，外部系统中的两个不同用户可能会映射到相同的用户名。我们的建议是首先避免这种情况。因此，资源共享检查不会考虑这种潜在的不一致性。