Shield Docs: Fixed messed up xrefs & removed obsolete troubleshooting & limitation info.
Original commit: elastic/x-pack-elasticsearch@a376a24ea1
This commit is contained in:
debadair
parent
388f8cec6b
commit
ca2aaa1567
|
|
@ -3,8 +3,11 @@
|
|||
= Shield Reference
|
||||
|
||||
:ref: http://www.elastic.co/guide/en/elasticsearch/reference/current
|
||||
:ref-17: http://www.elastic.co/guide/en/elasticsearch/reference/1.7
|
||||
|
||||
:version: 2.1.0
|
||||
|
||||
|
||||
include::introduction.asciidoc[]
|
||||
|
||||
include::getting-started.asciidoc[]
|
||||
|
|
|
|||
|
|
@ -29,68 +29,6 @@ indices, while Elasticsearch with Shield returns exceptions. Note that this beha
|
|||
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.
|
||||
|
||||
[[limitations-filtered-aliases]]
|
||||
[float]
|
||||
=== Filtered Index Aliases
|
||||
|
||||
You can combine a secured index alias with a {ref}/query-dsl-filters.html[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.
|
||||
|
||||
WARNING: Filtering secured index aliases does not provide security for documents retrieved through the
|
||||
{ref}/docs-get.html[get api]. Read
|
||||
https://github.com/elasticsearch/elasticsearch/issues/3861[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
|
||||
{ref}/search-search.html[search api] instead. Restrict get operations when you use this approach by granting the `search`
|
||||
privilege and disallowing `get`.
|
||||
|
||||
WARNING: 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
|
||||
https://github.com/elasticsearch/elasticsearch/issues/2318[Elasticsearch issue #2318] to learn more about this limitation.
|
||||
|
||||
WARNING: A filtered index alias will not provide document-level security for the {ref}/search-suggesters.html[suggesters apis]
|
||||
as they do not take into account the filters placed on aliases.
|
||||
|
||||
WARNING: A filtered index alias will not provide document-level security when using a
|
||||
{ref}/search-aggregations-bucket-children-aggregation.html[Children Aggregation] as the filter from the alias is not used
|
||||
when computing the aggregation results.
|
||||
|
||||
[float]
|
||||
=== Queries and Filters
|
||||
|
||||
[[limitations-disable-cache]]
|
||||
[float]
|
||||
==== Elasticsearch 1.6+
|
||||
Elasticsearch 1.6 removes all of the limitations below with queries and filters with the exception of the {ref}/query-dsl-mlt-query.html[More Like This Query].
|
||||
*But* there is the possibility of authorization being bypassed when using a terms filter with the
|
||||
{ref}/query-dsl-terms-filter.html#_terms_lookup_mechanism[terms lookup mechanism]. The authorization that could be
|
||||
bypassed is for the index containing the terms when using Shield 1.2.0 and 1.2.1. If using Shield 1.2.0 or 1.2.1,
|
||||
add the following setting to your `elasticsearch.yml` file to ensure that requests are properly authorized:
|
||||
|
||||
[source,yaml]
|
||||
--------------------------------------------------
|
||||
indices.cache.filter.terms.size: 0
|
||||
--------------------------------------------------
|
||||
|
||||
Shield 1.2.2+ does not require this setting to be specified.
|
||||
|
||||
Elasticsearch 1.6.2+ and 1.7.1+ remove the limitations on the {ref}/query-dsl-mlt-query.html[More Like This Query].
|
||||
|
||||
[float]
|
||||
==== Elasticsearch pre-1.6.0
|
||||
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:
|
||||
|
||||
* {ref}/query-dsl-mlt-query.html[More Like This Query]
|
||||
* {ref}/query-dsl-geo-shape-query.html[GeoShape Query] and {ref}/query-dsl-geo-shape-filter.html[GeoShape Filter] when
|
||||
used with an {ref}/query-dsl-geo-shape-filter.html#_pre_indexed_shape[indexed shape]
|
||||
* {ref}/query-dsl-terms-filter.html[Terms Filter] when using the {ref}/query-dsl-terms-filter.html#_terms_lookup_mechanism[terms lookup mechanism]
|
||||
* {ref}/search-suggesters-phrase.html[Phrase Suggester] when specifying the `collate` field
|
||||
* Any query using {ref}/modules-scripting.html#_indexed_scripts[indexed scripts]
|
||||
* Queries using a {ref}/search-template.html[search template]
|
||||
|
||||
[float]
|
||||
=== Document Expiration (_ttl)
|
||||
|
||||
|
|
@ -101,5 +39,4 @@ does not work with Shield. The document deletions will fail and the documents co
|
|||
=== LDAP Realm
|
||||
|
||||
The <<ldap, 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, Active Directory Realm>> _does_
|
||||
support transitive group membership.
|
||||
of GroupA and GroupA is a member of GroupB, only GroupA will be discovered. However, the <<active-directory, Active Directory Realm>> _does_ support transitive group membership.
|
||||
|
|
|
|||
|
|
@ -22,8 +22,8 @@ bin/plugin remove shield
|
|||
bin/plugin install shield
|
||||
---------------------------------------------------
|
||||
|
||||
Then start the node. Larger sites should follow the steps in the {ref}/setup-upgrade.html#_1_0_and_later[rolling upgrade section]
|
||||
in order to ensure recovery is as quick as possible.
|
||||
Then start the node. Larger sites should follow the steps in the {ref}/rolling-upgrades.html[rolling upgrade section]
|
||||
to ensure recovery is as quick as possible.
|
||||
|
||||
On upgrade, your current configuration files will remain untouched. The configuration files provided by the new version
|
||||
of Shield will be added with a `.new` extension.
|
||||
|
|
@ -94,7 +94,7 @@ the correct user to index the audit events.
|
|||
|
||||
.bug fixes
|
||||
* Fixes <<enable-message-authentication,message authentication>> serialization to work with Shield 1.2.1 and earlier.
|
||||
** NOTE: if you are upgrading from Shield 1.3.0 or Shield 1.2.2 a {ref}/setup-upgrade.html#restart-upgrade[cluster restart upgrade]
|
||||
** NOTE: if you are upgrading from Shield 1.3.0 or Shield 1.2.2 a {ref-17}/setup-upgrade.html#restart-upgrade[cluster restart upgrade]
|
||||
will be necessary. When upgrading from other versions of Shield, follow the normal <<upgrade-instructions,upgrade procedure>>.
|
||||
|
||||
[float]
|
||||
|
|
@ -128,7 +128,7 @@ will be necessary. When upgrading from other versions of Shield, follow the norm
|
|||
|
||||
.bug fixes
|
||||
* Fixes <<enable-message-authentication,message authentication>> serialization to work with Shield 1.2.1 and earlier.
|
||||
** NOTE: if you are upgrading from Shield 1.2.2 a {ref}/setup-upgrade.html#restart-upgrade[cluster restart upgrade]
|
||||
** NOTE: if you are upgrading from Shield 1.2.2 a {ref-17}/setup-upgrade.html#restart-upgrade[cluster restart upgrade]
|
||||
will be necessary. When upgrading from other versions of Shield, follow the normal <<upgrade-instructions,upgrade procedure>>.
|
||||
|
||||
[float]
|
||||
|
|
@ -137,7 +137,7 @@ will be necessary. When upgrading from other versions of Shield, follow the norm
|
|||
.bug fixes
|
||||
* The `esusers` tool no longer warns about missing roles that are properly defined in the `roles.yml` file.
|
||||
* The period character, `.`, is now allowed in usernames and role names.
|
||||
* The {ref}/query-dsl-terms-filter.html#_caching_19[terms filter lookup cache] has been disabled to ensure all requests
|
||||
* The {ref-17}/query-dsl-terms-filter.html#_caching_19[terms filter lookup cache] has been disabled to ensure all requests
|
||||
are properly authorized. This removes the need to <<limitations-disable-cache,manually disable>> the terms filter
|
||||
cache.
|
||||
* For LDAP client connections, only the protocols and ciphers specified in the `shield.ssl.supported_protocols` and
|
||||
|
|
@ -148,7 +148,7 @@ will be necessary. When upgrading from other versions of Shield, follow the norm
|
|||
==== 1.2.1
|
||||
|
||||
.bug fixes
|
||||
* Several bug fixes including a fix to ensure that {ref}/disk.html[Disk-based Shard Allocation]
|
||||
* Several bug fixes including a fix to ensure that {ref-17}/disk.html[Disk-based Shard Allocation]
|
||||
works properly with Shield
|
||||
|
||||
[float]
|
||||
|
|
|
|||
|
|
@ -215,22 +215,4 @@ recommend consulting your JVM documentation for details on how to enable the PKC
|
|||
|
||||
Another common source of this error is requesting cipher suites that use encrypting with a key length greater than 128 bits
|
||||
when running on an Oracle JDK. In this case, you will need to install the <<ciphers, JCE Unlimited Strength Jurisdiction Policy Files>>.
|
||||
--
|
||||
|
||||
[float]
|
||||
=== Exceptions when unlicensed
|
||||
|
||||
WARN: Failed to execute IndicesStatsAction for ClusterInfoUpdateJob::
|
||||
+
|
||||
--
|
||||
This warning occurs in the logs every 30 seconds when the Shield license is expired or invalid. It is caused by a periodic
|
||||
internal request to gather disk usage information from the nodes and indices, to enable {ref}/disk.html[disk-based shard allocation].
|
||||
Disk-based shard allocation is not required, though it is enabled by default.
|
||||
|
||||
If you are using Elasticsearch 1.4.3 or higher with disk-based shard allocation enabled, it will be automatically disabled when the Shield
|
||||
license is expired or invalid, and will be automatically re-enabled when a valid Shield license is installed.
|
||||
|
||||
If you are using Elasticsearch 1.4.2 with disk-based shard allocation enabled, we recommend manually disabling disk-based shard
|
||||
allocation while your Shield license is expired, and re-enabling it after installing a valid Shield license. Instructions for
|
||||
disabling disk-based shard allocation are {ref}/disk.html[here].
|
||||
--
|
||||
Loading…
Reference in New Issue