From version 5.0 onward, Shield is part of X-Pack. For more information, see Securing the Elastic Stack.
« Appendix 2. License Management Appendix 4. Securing Indices & Aliases »
Elastic Docs ›Shield - Elasticsearch Security Plugin [1.0]

Appendix 3. Limitations

edit

Appendix 3. Limitations

edit

Plugins

edit

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.

Changes in Index Wildcard Behavior

edit

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.

Filtered Index Aliases

edit

You can combine a secured index alias with a 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.

Filtering secured index aliases does not provide security for documents retrieved through the get api. Read 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 search api instead. Restrict get operations when you use this approach by granting the search privilege and disallowing get.

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 elasticsearch issue #2318 to learn more about this limitation.

A filtered index alias will not provide document-level security for the suggesters apis as they do not take into account the filters placed on aliases.

A filtered index alias will not provide document-level security when using a Children Aggregation as the filter from the alias is not used when computing the aggregation results.

Queries and Filters

edit

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:

Document Expiration (_ttl)

edit

Document expiration handled using the built-in _ttl (time to live) mechanism does not work with Shield. The document deletions will fail and the documents continue to live past their expiration.

LDAP Realm

edit

Some known limitations with the LDAP Realm are that it doesn’t support transitive group membership, and only supports authentication with usernames that match naming attributes.

Transitive Group MembershipThe 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 Realm does support transitive group membership.

Naming Attributes for LoginThe LDAP Realm uses DN templates for authentication. While this eliminates the need to search for the user, it also prevents the authentication with user attributes that are not naming attributes. A naming attribute is an attribute that can make up a DN. For example, CN and DC are naming attributes in this DN: CN=John Doe,DC=example,DC=com. If a directory is setup to use CN (common name) as the only naming attribute for a user, then other attributes like uid, or mail can’t be used.

« Appendix 2. License Management Appendix 4. Securing Indices & Aliases »