94 lines
3.9 KiB
Plaintext
94 lines
3.9 KiB
Plaintext
|
[role="xpack"]
|
||
|
|
[[security-limitations]]
|
||
|
|
== Security limitations
|
||
|
|
[subs="attributes"]
|
||
|
|
++++
|
||
|
|
<titleabbrev>Limitations</titleabbrev>
|
||
|
|
++++
|
||
|
|
|
||
|
|
[float]
|
||
|
|
=== Plugins
|
||
|
|
|
||
|
|
Elasticsearch's plugin infrastructure is extremely flexible in terms of what can
|
||
|
|
be extended. While it opens up Elasticsearch to a wide variety of (often custom)
|
||
|
|
additional functionality, when it comes to security, this high extensibility level
|
||
|
|
comes at a cost. We have no control over the third-party plugins' code (open
|
||
|
|
source or not) and therefore we cannot guarantee their compliance with
|
||
|
|
{stack-security-features}. For this reason, third-party plugins are not
|
||
|
|
officially supported on clusters with {security-features} enabled.
|
||
|
|
|
||
|
|
[float]
|
||
|
|
=== Changes in index wildcard behavior
|
||
|
|
|
||
|
|
Elasticsearch clusters with the {security-features} enabled apply the `/_all`
|
||
|
|
wildcard, and all other wildcards, to the indices that the current user has
|
||
|
|
privileges for, not the set of all indices on the cluster.
|
||
|
|
|
||
|
|
[float]
|
||
|
|
=== Multi document APIs
|
||
|
|
|
||
|
|
Multi get and multi term vectors API throw IndexNotFoundException when trying to access non existing indices that the user is
|
||
|
|
not authorized for. By doing that they leak information regarding the fact that the index doesn't exist, while the user is not
|
||
|
|
authorized to know anything about those indices.
|
||
|
|
|
||
|
|
[float]
|
||
|
|
=== Filtered index aliases
|
||
|
|
|
||
|
|
Aliases containing filters are not a secure way to restrict access to individual
|
||
|
|
documents, due to the limitations described in
|
||
|
|
<<alias-limitations, Index and field names can be leaked when using aliases>>.
|
||
|
|
The {stack-security-features} provide a secure way to restrict access to
|
||
|
|
documents through the
|
||
|
|
<<field-and-document-access-control, document-level security>> feature.
|
||
|
|
|
||
|
|
[float]
|
||
|
|
=== Field and document level security limitations
|
||
|
|
|
||
|
|
When a user's role enables document or field level security for an index:
|
||
|
|
|
||
|
|
* The user cannot perform write operations:
|
||
|
|
** The update API isn't supported.
|
||
|
|
** Update requests included in bulk requests aren't supported.
|
||
|
|
* The request cache is disabled for search requests.
|
||
|
|
|
||
|
|
When a user's role enables document level security for an index:
|
||
|
|
|
||
|
|
* Document level security isn't applied for APIs that aren't document based.
|
||
|
|
An example is the field stats API.
|
||
|
|
* Document level security doesn't affect global index statistics that relevancy
|
||
|
|
scoring uses. So this means that scores are computed without taking the role
|
||
|
|
query into account. Note that documents not matching with the role query are
|
||
|
|
never returned.
|
||
|
|
* The `has_child` and `has_parent` queries aren't supported as query in the
|
||
|
|
role definition. The `has_child` and `has_parent` queries can be used in the
|
||
|
|
search API with document level security enabled.
|
||
|
|
* Any query that makes remote calls to fetch data to query by isn't supported.
|
||
|
|
The following queries aren't supported:
|
||
|
|
** The `terms` query with terms lookup isn't supported.
|
||
|
|
** The `geo_shape` query with indexed shapes isn't supported.
|
||
|
|
** The `percolate` query isn't supported.
|
||
|
|
* If suggesters are specified and document level security is enabled then
|
||
|
|
the specified suggesters are ignored.
|
||
|
|
* A search request cannot be profiled if document level security is enabled.
|
||
|
|
|
||
|
|
[float]
|
||
|
|
[[alias-limitations]]
|
||
|
|
=== Index and field names can be leaked when using aliases
|
||
|
|
|
||
|
|
Calling certain Elasticsearch APIs on an alias can potentially leak information
|
||
|
|
about indices that the user isn't authorized to access. For example, when you get
|
||
|
|
the mappings for an alias with the `_mapping` API, the response includes the
|
||
|
|
index name and mappings for each index that the alias applies to.
|
||
|
|
|
||
|
|
Until this limitation is addressed, avoid index and field names that contain
|
||
|
|
confidential or sensitive information.
|
||
|
|
|
||
|
|
[float]
|
||
|
|
=== LDAP realm
|
||
|
|
|
||
|
|
The <<ldap-realm, LDAP Realm>> does not currently support the discovery of nested
|
||
|
|
LDAP Groups. For example, if a user is a member of `group_1` and `group_1` is a
|
||
|
|
member of `group_2`, only `group_1` will be discovered. However, the
|
||
|
|
<<active-directory-realm, Active Directory Realm>> *does* support transitive
|
||
|
|
group membership.
|