88 lines
3.9 KiB
Plaintext
88 lines
3.9 KiB
Plaintext
|
[[security-limitations]]
|
||
|
|
== Security Limitations
|
||
|
|
|
||
|
|
[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 {security}.
|
||
|
|
For this reason, third-party plugins are not officially supported on clusters
|
||
|
|
with {security} enabled.
|
||
|
|
|
||
|
|
[float]
|
||
|
|
=== Changes in Index Wildcard Behavior
|
||
|
|
|
||
|
|
Elasticsearch clusters with {security} 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.
|
||
|
|
While creating or retrieving aliases by providing wildcard expressions for alias names, if there are no existing authorized aliases
|
||
|
|
that match the wildcard expression provided an IndexNotFoundException is returned.
|
||
|
|
|
||
|
|
[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>>.
|
||
|
|
{security} provides 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.
|
||
|
|
|
||
|
|
[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. Similarly, the
|
||
|
|
response to a `_field_stats` request includes the name of the underlying index,
|
||
|
|
rather than the alias name.
|
||
|
|
|
||
|
|
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.
|