mirror of
https://github.com/honeymoose/OpenSearch.git
synced 2025-02-10 15:05:33 +00:00
00a6ad0e9e
Resolving wildcards in aliases expression is challenging as we may end up with no aliases to replace the original expression with, but if we replace with an empty array that means _all which is quite the opposite. Now that we support and serialize the original requested aliases, whenever aliases are replaced we will be able to know what was initially requested. `MetaData#findAliases` can then be updated to not return anything in case it gets empty aliases, but the original aliases were not empty. That means that empty aliases are interpreted as _all only if they were originally requested that way. Relates to #31516
88 lines
3.8 KiB
Plaintext
88 lines
3.8 KiB
Plaintext
[role="xpack"]
|
|
[[security-limitations]]
|
|
== Security 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 {security}.
|
|
For this reason, third-party plugins are not officially supported on clusters
|
|
with {security} enabled.
|
|
|
|
[float]
|
|
=== Changes in Index Wildcard Behavior
|
|
|
|
Elasticsearch clusters with {security} enabled 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.
|
|
|
|
[float]
|
|
=== Multi Document APIs
|
|
|
|
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 index doesn't exist, while the user is not
|
|
authorized to know anything about those indices.
|
|
|
|
[float]
|
|
=== Filtered Index Aliases
|
|
|
|
Aliases containing filters are not a secure way to restrict access to individual
|
|
documents, due to the limitations described in <<alias-limitations, Index and Field Names Can Be Leaked When Using Aliases>>.
|
|
{security} provides a secure way to restrict access to documents through the
|
|
<<field-and-document-access-control, document-level security>> feature.
|
|
|
|
[float]
|
|
=== Field and Document Level Security Limitations
|
|
|
|
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.
|
|
|
|
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 query in the
|
|
role definition. 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.
|
|
** The `percolate` query isn't supported.
|
|
* If suggesters are specified and document level security is enabled then
|
|
the specified suggesters are ignored.
|
|
* A search request cannot be profiled if document level security is enabled.
|
|
|
|
[float]
|
|
[[alias-limitations]]
|
|
=== Index and Field Names Can Be Leaked When Using Aliases
|
|
|
|
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.
|
|
|
|
Until this limitation is addressed, avoid index and field names that contain
|
|
confidential or sensitive information.
|
|
|
|
[float]
|
|
=== LDAP Realm
|
|
|
|
The <<ldap-realm, 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, Active Directory Realm>> *does* support transitive
|
|
group membership.
|