| mapped_pages | navigation_title | applies_to | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
Limitations |
|
Review the following {{es}} security limitations. Depending on your organization's security requirements, you might want to restrict, adjust, or find workaround or alternatives for some of these features and resources.
{{es}}'s plugin infrastructure is extremely flexible in terms of what can be extended. While it opens up {{es}} 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 {{stack-security-features}}. For this reason, third-party plugins are not officially supported on clusters with {{security-features}} enabled.
{{es}} clusters with the {{security-features}} enabled apply _all and other wildcards to data streams, indices, and aliases the current user has privileges for, not all data streams, indices, and aliases on the cluster.
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 data stream or index doesn’t exist, while the user is not authorized to know anything about those data streams or indices.
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. The {{stack-security-features}} provide a secure way to restrict access to documents through the document-level security feature.
::::{include} /deploy-manage/_snippets/field-doc-sec-limitations.md ::::
Calling certain {{es}} 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.
Until this limitation is addressed, avoid index and field names that contain confidential or sensitive information.
The 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 does support transitive group membership.
The result of async search and scroll requests can be retrieved later by the same user or API key that submitted the initial request. The verification process involves comparing the username, authentication realm type, and (for realms other than file or native) realm name. If you used an API key to submit the request, only that key can retrieve the results. This logic also has a few limitations:
- Two different realms can have the same name on different nodes. This is not a recommended way to configure realms, therefore the resource sharing check does not attempt to detect this inconsistency.
- Realms can be renamed. This can cause inconsistency for the resource sharing check when you submit an async search or scroll then rename the realm and try to retrieve the results. Hence, changing realm names should be handled with care since it can cause complications for more than just the resource sharing check.
- The username is dynamically computed for realms backed by certain external authentication providers. For example, the username can be derived from part of the DN in an LDAP realm. It is in theory possible that two distinct users from the external system get mapped to the same username. Our recommendation is to avoid this situation in the first place. Hence, the resource sharing check does not account for this potential discrepancy.