58 lines
3.4 KiB
Plaintext
58 lines
3.4 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.
|
|
|
|
[float]
|
|
=== Field and Document Level Security Limitations
|
|
|
|
Bulk updates do not work when document and field level security is enabled. If you are not using document and field level
|
|
security, bulk updates can be enabled by setting `shield.dls_fls.enabled` to `false`.
|
|
|
|
When document level security is enabled for an index:
|
|
|
|
* The get, multi get, termsvector and multi termsvector APIs aren't executed in real time. The realtime option for these APIs is forcefully set to false.
|
|
* 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 role query in the `roles.yml` file.
|
|
The `has_child` and `has_parent` queries can be used in the search API with document level security enabled.
|
|
|
|
[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.
|