102 lines
5.7 KiB
Plaintext
102 lines
5.7 KiB
Plaintext
[[limitations]]
|
|
== 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 Shield. For this reason, third-party plugins are not officially supported on clusters
|
|
with the Shield security plugin installed.
|
|
|
|
[float]
|
|
=== Changes in Index Wildcard Behavior
|
|
|
|
Elasticsearch clusters with the Shield security plugin installed 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. There are two
|
|
notable results of this behavior:
|
|
|
|
* Elasticsearch clusters with the Shield security plugin installed do not honor the `ignore_unavailable` option.
|
|
This behavior means that requests involving indices that the current user lacks authorization for throw an
|
|
`AuthorizationException` error, regardless of the option's setting.
|
|
|
|
* The `allow_no_indices` option is ignored, resulting in the following behavior: when the final set of indices after
|
|
wildcard expansion and replacement is empty, the request throws a `IndexMissingException` error.
|
|
|
|
As a general principle, core Elasticsearch will return empty results in scenarios where wildcard expansion returns no
|
|
indices, while Elasticsearch with Shield returns exceptions. Note that this behavior means that operations with
|
|
multiple items will fail the entire set of operations if any one operation throws an exception due to wildcard
|
|
expansion resulting in an empty set of authorized indices.
|
|
|
|
[[limitations-filtered-aliases]]
|
|
[float]
|
|
=== Filtered Index Aliases
|
|
|
|
You can combine a secured index alias with a {ref}/query-dsl-filters.html[filter]
|
|
to approximate document-level security. By manipulating the specific filtering, you can control the set of documents
|
|
that users with privileges on that index alias can access.
|
|
|
|
WARNING: Filtering secured index aliases does not provide security for documents retrieved through the
|
|
{ref}/docs-get.html[get api]. Read
|
|
https://github.com/elasticsearch/elasticsearch/issues/3861[Elasticsearch issue #3861] to learn more about this limitation.
|
|
Users can obtain secure near-real-time get under this restriction with searches by document ID, using the
|
|
{ref}/search-search.html[search api] instead. Restrict get operations when you use this approach by granting the `search`
|
|
privilege and disallowing `get`.
|
|
|
|
WARNING: In Elasticsearch, issuing a delete operation on an alias also deletes all of the indices that the alias
|
|
points to, regardless of the filter that the alias might hold. Keep this behavior in mind when granting users
|
|
administrative privileges to filtered index aliases. Read
|
|
https://github.com/elasticsearch/elasticsearch/issues/2318[Elasticsearch issue #2318] to learn more about this limitation.
|
|
|
|
WARNING: A filtered index alias will not provide document-level security for the {ref}/search-suggesters.html[suggesters apis]
|
|
as they do not take into account the filters placed on aliases.
|
|
|
|
WARNING: A filtered index alias will not provide document-level security when using a
|
|
{ref}/search-aggregations-bucket-children-aggregation.html[Children Aggregation] as the filter from the alias is not used
|
|
when computing the aggregation results.
|
|
|
|
[float]
|
|
=== Queries and Filters
|
|
|
|
[[limitations-disable-cache]]
|
|
[float]
|
|
==== Elasticsearch 1.6+
|
|
Elasticsearch 1.6 removes all of the limitations below with queries and filters, *but* there is the possibility of
|
|
authorization being bypassed when using a terms filter with the
|
|
{ref}/query-dsl-terms-filter.html#_terms_lookup_mechanism[terms lookup mechanism]. The authorization that could be
|
|
bypassed is for the index containing the terms. In order to ensure that all requests are properly authorized when using
|
|
Shield 1.2.0 and 1.2.1, add the following setting to your `elasticsearch.yml` file:
|
|
|
|
[source,yaml]
|
|
--------------------------------------------------
|
|
indices.cache.filter.terms.size: 0
|
|
--------------------------------------------------
|
|
|
|
[float]
|
|
==== Elasticsearch pre-1.6.0
|
|
Certain Elasticsearch requests execute other requests as part of their implementation. Some of these requests do not
|
|
maintain the security context that the original request was made with. This causes an `AuthorizationException` even when
|
|
the user has authorization to make the subsequent requests. The following requests have this behavior:
|
|
|
|
* {ref}/query-dsl-mlt-query.html[More Like This Query]
|
|
* {ref}/query-dsl-geo-shape-query.html[GeoShape Query] and {ref}/query-dsl-geo-shape-filter.html[GeoShape Filter] when
|
|
used with an {ref}/query-dsl-geo-shape-filter.html#_pre_indexed_shape[indexed shape]
|
|
* {ref}/query-dsl-terms-filter.html[Terms Filter] when using the {ref}/query-dsl-terms-filter.html#_terms_lookup_mechanism[terms lookup mechanism]
|
|
* {ref}/search-suggesters-phrase.html[Phrase Suggester] when specifying the `collate` field
|
|
* Any query using {ref}/modules-scripting.html#_indexed_scripts[indexed scripts]
|
|
* Queries using a {ref}/search-template.html[search template]
|
|
|
|
[float]
|
|
=== Document Expiration (_ttl)
|
|
|
|
Document expiration handled using the built-in {ref}/mapping-ttl-field.html#mapping-ttl-field[`_ttl` (time to live) mechanism]
|
|
does not work with Shield. The document deletions will fail and the documents continue to live past their expiration.
|
|
|
|
[float]
|
|
=== LDAP Realm
|
|
|
|
The <<ldap, LDAP Realm>> does not currently support the discovery of nested LDAP Groups. For example, if a user is a member
|
|
of GroupA and GroupA is a member of GroupB, only GroupA will be discovered. However, the <<active-directory, Active Directory Realm>> _does_
|
|
support transitive group membership.
|