From version 5.0 onward, Shield is part of X-Pack. For more information, see Securing the Elastic Stack.
« REST API Troubleshooting »
Elastic Docs ›Shield [2.4]

Limitations

edit

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

Aliases containing filters are not a secure way to restrict access to individual documents, due to the limitations described in Index and Field Names Can Be Leaked When Using Aliases. Shield provides a secure way to restrict access to documents through the document-level security feature.

Field and Document Level Security Limitations

edit

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.
  • 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.

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 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.

  • 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.

When a user’s role enables field level security for an index:

  • The query cache is disabled for search requests.

Index and Field Names Can Be Leaked When Using Aliases

edit

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.

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

The 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.

Accessing the .security index

edit

The .security index is a privileged index where the native users and roles are stored. This index contains sensitive data and needs to be protected from inadvertent access. In order to accomplish this, the .security index is excluded from wildcard resolution for all users except users with the cluster manage or manage_security privilege. It is important to note that the cluster privilege is not enough to access the .security index as the user must also have the appropriate index privileges that map to the .security index.

« REST API Troubleshooting »