Merge pull request elastic/elasticsearch#827 from jaymode/docs_alias_dls

update the wording around filtered aliases and document level security

Original commit: elastic/x-pack-elasticsearch@86958f1404
This commit is contained in:
Jay Modi 2015-10-19 10:10:42 -04:00
commit 5f3ba2cd43
2 changed files with 5 additions and 4 deletions

View File

@ -97,5 +97,5 @@ curl -XPOST 'http://localhost:9200/_aliases' -d '
==== Filtered aliases
Aliases can hold a filter, which allows to select a subset of documents that can be accessed out of all the documents that
the physical index contains. Filtered aliases allow to mimic document level security, but have limitations. Please read
the <<limitations-filtered-aliases,limitations>> section to know more.
the physical index contains. These filters are <<limitations-filtered-aliases,not always applied>> and should not be used
in place of <<document-level-security, document level security>>.

View File

@ -1,5 +1,5 @@
[[setting-up-field-and-document-level-security]]
=== Setting Up Field and Document Level Security.
=== Setting Up Field and Document Level Security
You can control access to data within an index by adding field and document level security permissions to a role.
Field level security permissions restrict access to particular fields within a document.
@ -111,6 +111,7 @@ When field level security is enabled for an index:
* The query cache and the request cache are disabled for search requests.
* The update API is blocked. An update request needs to be executed via a role that doesn't have field level security enabled.
[[document-level-security]]
==== Document Level Security
Enabling document level security restricts which documents can be accessed from any document based API.
@ -165,6 +166,6 @@ 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 oriented. For example this is the case for 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.
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.