[DOCS] Moves troubleshooting and limitations to stack-docs
This commit is contained in:
lcawl
parent
c6c456e8cb
commit
cd4bdde328
|
|
@ -1,87 +0,0 @@
|
|||
[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.
|
||||
|
|
@ -1,490 +0,0 @@
|
|||
[role="xpack"]
|
||||
[[security-troubleshooting]]
|
||||
== {security} Troubleshooting
|
||||
++++
|
||||
<titleabbrev>{security}</titleabbrev>
|
||||
++++
|
||||
|
||||
Use the information in this section to troubleshoot common problems and find
|
||||
answers for frequently asked questions.
|
||||
|
||||
* <<security-trb-settings>>
|
||||
* <<security-trb-roles>>
|
||||
* <<security-trb-extraargs>>
|
||||
* <<trouble-shoot-active-directory>>
|
||||
* <<trb-security-maccurl>>
|
||||
* <<trb-security-sslhandshake>>
|
||||
* <<trb-security-ssl>>
|
||||
* <<trb-security-kerberos>>
|
||||
* <<trb-security-internalserver>>
|
||||
* <<trb-security-setup>>
|
||||
|
||||
|
||||
To get help, see <<help>>.
|
||||
|
||||
[[security-trb-settings]]
|
||||
=== Some settings are not returned via the nodes settings API
|
||||
|
||||
*Symptoms:*
|
||||
|
||||
* When you use the {ref}/cluster-nodes-info.html[nodes info API] to retrieve
|
||||
settings for a node, some information is missing.
|
||||
|
||||
*Resolution:*
|
||||
|
||||
This is intentional. Some of the settings are considered to be highly
|
||||
sensitive: all `ssl` settings, ldap `bind_dn`, and `bind_password`.
|
||||
For this reason, we filter these settings and do not expose them via
|
||||
the nodes info API rest endpoint. You can also define additional
|
||||
sensitive settings that should be hidden using the
|
||||
`xpack.security.hide_settings` setting. For example, this snippet
|
||||
hides the `url` settings of the `ldap1` realm and all settings of the
|
||||
`ad1` realm.
|
||||
|
||||
[source, yaml]
|
||||
------------------------------------------
|
||||
xpack.security.hide_settings: xpack.security.authc.realms.ldap1.url,
|
||||
xpack.security.authc.realms.ad1.*
|
||||
------------------------------------------
|
||||
|
||||
[[security-trb-roles]]
|
||||
=== Authorization exceptions
|
||||
|
||||
*Symptoms:*
|
||||
|
||||
* I configured the appropriate roles and the users, but I still get an
|
||||
authorization exception.
|
||||
* I can authenticate to LDAP, but I still get an authorization exception.
|
||||
|
||||
|
||||
*Resolution:*
|
||||
|
||||
. Verify that the role names associated with the users match the roles defined
|
||||
in the `roles.yml` file. You can use the `elasticsearch-users` tool to list all
|
||||
the users. Any unknown roles are marked with `*`.
|
||||
+
|
||||
--
|
||||
[source, shell]
|
||||
------------------------------------------
|
||||
bin/elasticsearch-users list
|
||||
rdeniro : admin
|
||||
alpacino : power_user
|
||||
jacknich : monitoring,unknown_role* <1>
|
||||
------------------------------------------
|
||||
<1> `unknown_role` was not found in `roles.yml`
|
||||
|
||||
For more information about this command, see the
|
||||
{ref}/users-command.html[`elasticsearch-users` command].
|
||||
--
|
||||
|
||||
. If you are authenticating to LDAP, a number of configuration options can cause
|
||||
this error.
|
||||
+
|
||||
--
|
||||
|======================
|
||||
|_group identification_ |
|
||||
|
||||
Groups are located by either an LDAP search or by the "memberOf" attribute on
|
||||
the user. Also, If subtree search is turned off, it will search only one
|
||||
level deep. See the <<ldap-settings, LDAP Settings>> for all the options.
|
||||
There are many options here and sticking to the defaults will not work for all
|
||||
scenarios.
|
||||
|
||||
| _group to role mapping_|
|
||||
|
||||
Either the `role_mapping.yml` file or the location for this file could be
|
||||
misconfigured. See <<security-files, Security Files>> for more.
|
||||
|
||||
|_role definition_|
|
||||
|
||||
The role definition might be missing or invalid.
|
||||
|
||||
|======================
|
||||
|
||||
To help track down these possibilities, add the following lines to the end of
|
||||
the `log4j2.properties` configuration file in the `ES_PATH_CONF`:
|
||||
|
||||
[source,properties]
|
||||
----------------
|
||||
logger.authc.name = org.elasticsearch.xpack.security.authc
|
||||
logger.authc.level = DEBUG
|
||||
----------------
|
||||
|
||||
A successful authentication should produce debug statements that list groups and
|
||||
role mappings.
|
||||
--
|
||||
|
||||
[[security-trb-extraargs]]
|
||||
=== Users command fails due to extra arguments
|
||||
|
||||
*Symptoms:*
|
||||
|
||||
* The `elasticsearch-users` command fails with the following message:
|
||||
`ERROR: extra arguments [...] were provided`.
|
||||
|
||||
*Resolution:*
|
||||
|
||||
This error occurs when the `elasticsearch-users` tool is parsing the input and
|
||||
finds unexpected arguments. This can happen when there are special characters
|
||||
used in some of the arguments. For example, on Windows systems the `,` character
|
||||
is considered a parameter separator; in other words `-r role1,role2` is
|
||||
translated to `-r role1 role2` and the `elasticsearch-users` tool only
|
||||
recognizes `role1` as an expected parameter. The solution here is to quote the
|
||||
parameter: `-r "role1,role2"`.
|
||||
|
||||
For more information about this command, see
|
||||
{ref}/users-command.html[`elasticsearch-users` command].
|
||||
|
||||
[[trouble-shoot-active-directory]]
|
||||
=== Users are frequently locked out of Active Directory
|
||||
|
||||
*Symptoms:*
|
||||
|
||||
* Certain users are being frequently locked out of Active Directory.
|
||||
|
||||
*Resolution:*
|
||||
|
||||
Check your realm configuration; realms are checked serially, one after another.
|
||||
If your Active Directory realm is being checked before other realms and there
|
||||
are usernames that appear in both Active Directory and another realm, a valid
|
||||
login for one realm might be causing failed login attempts in another realm.
|
||||
|
||||
For example, if `UserA` exists in both Active Directory and a file realm, and
|
||||
the Active Directory realm is checked first and file is checked second, an
|
||||
attempt to authenticate as `UserA` in the file realm would first attempt to
|
||||
authenticate against Active Directory and fail, before successfully
|
||||
authenticating against the `file` realm. Because authentication is verified on
|
||||
each request, the Active Directory realm would be checked - and fail - on each
|
||||
request for `UserA` in the `file` realm. In this case, while the authentication
|
||||
request completed successfully, the account on Active Directory would have
|
||||
received several failed login attempts, and that account might become
|
||||
temporarily locked out. Plan the order of your realms accordingly.
|
||||
|
||||
Also note that it is not typically necessary to define multiple Active Directory
|
||||
realms to handle domain controller failures. When using Microsoft DNS, the DNS
|
||||
entry for the domain should always point to an available domain controller.
|
||||
|
||||
|
||||
[[trb-security-maccurl]]
|
||||
=== Certificate verification fails for curl on Mac
|
||||
|
||||
*Symptoms:*
|
||||
|
||||
* `curl` on the Mac returns a certificate verification error even when the
|
||||
`--cacert` option is used.
|
||||
|
||||
|
||||
*Resolution:*
|
||||
|
||||
Apple's integration of `curl` with their keychain technology disables the
|
||||
`--cacert` option.
|
||||
See http://curl.haxx.se/mail/archive-2013-10/0036.html for more information.
|
||||
|
||||
You can use another tool, such as `wget`, to test certificates. Alternately, you
|
||||
can add the certificate for the signing certificate authority MacOS system
|
||||
keychain, using a procedure similar to the one detailed at the
|
||||
http://support.apple.com/kb/PH14003[Apple knowledge base]. Be sure to add the
|
||||
signing CA's certificate and not the server's certificate.
|
||||
|
||||
|
||||
[[trb-security-sslhandshake]]
|
||||
=== SSLHandshakeException causes connections to fail
|
||||
|
||||
*Symptoms:*
|
||||
|
||||
* A `SSLHandshakeException` causes a connection to a node to fail and indicates
|
||||
that there is a configuration issue. Some of the common exceptions are shown
|
||||
below with tips on how to resolve these issues.
|
||||
|
||||
|
||||
*Resolution:*
|
||||
|
||||
`java.security.cert.CertificateException: No name matching node01.example.com found`::
|
||||
+
|
||||
--
|
||||
Indicates that a client connection was made to `node01.example.com` but the
|
||||
certificate returned did not contain the name `node01.example.com`. In most
|
||||
cases, the issue can be resolved by ensuring the name is specified during
|
||||
certificate creation. For more information, see <<ssl-tls>>. Another scenario is
|
||||
when the environment does not wish to use DNS names in certificates at all. In
|
||||
this scenario, all settings in `elasticsearch.yml` should only use IP addresses
|
||||
including the `network.publish_host` setting.
|
||||
--
|
||||
|
||||
`java.security.cert.CertificateException: No subject alternative names present`::
|
||||
+
|
||||
--
|
||||
Indicates that a client connection was made to an IP address but the returned
|
||||
certificate did not contain any `SubjectAlternativeName` entries. IP addresses
|
||||
are only used for hostname verification if they are specified as a
|
||||
`SubjectAlternativeName` during certificate creation. If the intent was to use
|
||||
IP addresses for hostname verification, then the certificate will need to be
|
||||
regenerated with the appropriate IP address. See <<ssl-tls>>.
|
||||
--
|
||||
|
||||
`javax.net.ssl.SSLHandshakeException: null cert chain` and `javax.net.ssl.SSLException: Received fatal alert: bad_certificate`::
|
||||
+
|
||||
--
|
||||
The `SSLHandshakeException` indicates that a self-signed certificate was
|
||||
returned by the client that is not trusted as it cannot be found in the
|
||||
`truststore` or `keystore`. This `SSLException` is seen on the client side of
|
||||
the connection.
|
||||
--
|
||||
|
||||
`sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target` and `javax.net.ssl.SSLException: Received fatal alert: certificate_unknown`::
|
||||
+
|
||||
--
|
||||
This `SunCertPathBuilderException` indicates that a certificate was returned
|
||||
during the handshake that is not trusted. This message is seen on the client
|
||||
side of the connection. The `SSLException` is seen on the server side of the
|
||||
connection. The CA certificate that signed the returned certificate was not
|
||||
found in the `keystore` or `truststore` and needs to be added to trust this
|
||||
certificate.
|
||||
--
|
||||
|
||||
[[trb-security-ssl]]
|
||||
=== Common SSL/TLS exceptions
|
||||
|
||||
*Symptoms:*
|
||||
|
||||
* You might see some exceptions related to SSL/TLS in your logs. Some of the
|
||||
common exceptions are shown below with tips on how to resolve these issues. +
|
||||
|
||||
|
||||
|
||||
*Resolution:*
|
||||
|
||||
`WARN: received plaintext http traffic on a https channel, closing connection`::
|
||||
+
|
||||
--
|
||||
Indicates that there was an incoming plaintext http request. This typically
|
||||
occurs when an external applications attempts to make an unencrypted call to the
|
||||
REST interface. Please ensure that all applications are using `https` when
|
||||
calling the REST interface with SSL enabled.
|
||||
--
|
||||
|
||||
`org.elasticsearch.common.netty.handler.ssl.NotSslRecordException: not an SSL/TLS record:`::
|
||||
+
|
||||
--
|
||||
Indicates that there was incoming plaintext traffic on an SSL connection. This
|
||||
typically occurs when a node is not configured to use encrypted communication
|
||||
and tries to connect to nodes that are using encrypted communication. Please
|
||||
verify that all nodes are using the same setting for
|
||||
`xpack.security.transport.ssl.enabled`.
|
||||
|
||||
For more information about this setting, see
|
||||
{ref}/security-settings.html[Security Settings in {es}].
|
||||
--
|
||||
|
||||
`java.io.StreamCorruptedException: invalid internal transport message format, got`::
|
||||
+
|
||||
--
|
||||
Indicates an issue with data received on the transport interface in an unknown
|
||||
format. This can happen when a node with encrypted communication enabled
|
||||
connects to a node that has encrypted communication disabled. Please verify that
|
||||
all nodes are using the same setting for `xpack.security.transport.ssl.enabled`.
|
||||
|
||||
For more information about this setting, see
|
||||
{ref}/security-settings.html[Security Settings in {es}].
|
||||
--
|
||||
|
||||
`java.lang.IllegalArgumentException: empty text`::
|
||||
+
|
||||
--
|
||||
This exception is typically seen when a `https` request is made to a node that
|
||||
is not using `https`. If `https` is desired, please ensure the following setting
|
||||
is in `elasticsearch.yml`:
|
||||
|
||||
[source,yaml]
|
||||
----------------
|
||||
xpack.security.http.ssl.enabled: true
|
||||
----------------
|
||||
|
||||
For more information about this setting, see
|
||||
{ref}/security-settings.html[Security Settings in {es}].
|
||||
--
|
||||
|
||||
`ERROR: unsupported ciphers [...] were requested but cannot be used in this JVM`::
|
||||
+
|
||||
--
|
||||
This error occurs when a SSL/TLS cipher suite is specified that cannot supported
|
||||
by the JVM that {es} is running in. Security tries to use the specified cipher
|
||||
suites that are supported by this JVM. This error can occur when using the
|
||||
Security defaults as some distributions of OpenJDK do not enable the PKCS11
|
||||
provider by default. In this case, we recommend consulting your JVM
|
||||
documentation for details on how to enable the PKCS11 provider.
|
||||
|
||||
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 must install the
|
||||
<<ciphers, JCE Unlimited Strength Jurisdiction Policy Files>>.
|
||||
--
|
||||
|
||||
[[trb-security-kerberos]]
|
||||
=== Common Kerberos exceptions
|
||||
|
||||
*Symptoms:*
|
||||
|
||||
* User authentication fails due to either GSS negotiation failure
|
||||
or a service login failure (either on the server or in the {es} http client).
|
||||
Some of the common exceptions are listed below with some tips to help resolve
|
||||
them.
|
||||
|
||||
*Resolution:*
|
||||
|
||||
`Failure unspecified at GSS-API level (Mechanism level: Checksum failed)`::
|
||||
+
|
||||
--
|
||||
|
||||
When you see this error message on the HTTP client side, then it may be
|
||||
related to an incorrect password.
|
||||
|
||||
When you see this error message in the {es} server logs, then it may be
|
||||
related to the {es} service keytab. The keytab file is present but it failed
|
||||
to log in as the user. Please check the keytab expiry. Also check whether the
|
||||
keytab contain up-to-date credentials; if not, replace them.
|
||||
|
||||
You can use tools like `klist` or `ktab` to list principals inside
|
||||
the keytab and validate them. You can use `kinit` to see if you can acquire
|
||||
initial tickets using the keytab. Please check the tools and their documentation
|
||||
in your Kerberos environment.
|
||||
|
||||
Kerberos depends on proper hostname resolution, so please check your DNS infrastructure.
|
||||
Incorrect DNS setup, DNS SRV records or configuration for KDC servers in `krb5.conf`
|
||||
can cause problems with hostname resolution.
|
||||
|
||||
--
|
||||
|
||||
`Failure unspecified at GSS-API level (Mechanism level: Request is a replay (34))`::
|
||||
|
||||
`Failure unspecified at GSS-API level (Mechanism level: Clock skew too great (37))`::
|
||||
+
|
||||
--
|
||||
|
||||
To prevent replay attacks, Kerberos V5 sets a maximum tolerance for computer
|
||||
clock synchronization and it is typically 5 minutes. Please check whether
|
||||
the time on the machines within the domain is in sync.
|
||||
|
||||
--
|
||||
|
||||
As Kerberos logs are often cryptic in nature and many things can go wrong
|
||||
as it depends on external services like DNS and NTP. You might
|
||||
have to enable additional debug logs to determine the root cause of the issue.
|
||||
|
||||
{es} uses a JAAS (Java Authentication and Authorization Service) Kerberos login
|
||||
module to provide Kerberos support. To enable debug logs on {es} for the login
|
||||
module use following Kerberos realm setting:
|
||||
[source,yaml]
|
||||
----------------
|
||||
xpack.security.authc.realms.<realm-name>.krb.debug: true
|
||||
----------------
|
||||
|
||||
For detailed information, see {ref}/security-settings.html#ref-kerberos-settings[Kerberos realm settings].
|
||||
|
||||
Sometimes you may need to go deeper to understand the problem during SPNEGO
|
||||
GSS context negotiation or look at the Kerberos message exchange. To enable
|
||||
Kerberos/SPNEGO debug logging on JVM, add following JVM system properties:
|
||||
|
||||
`-Dsun.security.krb5.debug=true`
|
||||
|
||||
`-Dsun.security.spnego.debug=true`
|
||||
|
||||
For more information about JVM system properties, see {ref}/jvm-options.html[configuring JVM options].
|
||||
|
||||
[[trb-security-internalserver]]
|
||||
=== Internal Server Error in Kibana
|
||||
|
||||
*Symptoms:*
|
||||
|
||||
* In 5.1.1, an `UnhandledPromiseRejectionWarning` occurs and {kib} displays an
|
||||
Internal Server Error.
|
||||
//TBD: Is the same true for later releases?
|
||||
|
||||
*Resolution:*
|
||||
|
||||
If the Security plugin is enabled in {es} but disabled in {kib}, you must
|
||||
still set `elasticsearch.username` and `elasticsearch.password` in `kibana.yml`.
|
||||
Otherwise, {kib} cannot connect to {es}.
|
||||
|
||||
|
||||
[[trb-security-setup]]
|
||||
=== Setup-passwords command fails due to connection failure
|
||||
|
||||
The {ref}/setup-passwords.html[elasticsearch-setup-passwords command] sets
|
||||
passwords for the built-in users by sending user management API requests. If
|
||||
your cluster uses SSL/TLS for the HTTP (REST) interface, the command attempts to
|
||||
establish a connection with the HTTPS protocol. If the connection attempt fails,
|
||||
the command fails.
|
||||
|
||||
*Symptoms:*
|
||||
|
||||
. {es} is running HTTPS, but the command fails to detect it and returns the
|
||||
following errors:
|
||||
+
|
||||
--
|
||||
[source, shell]
|
||||
------------------------------------------
|
||||
Cannot connect to elasticsearch node.
|
||||
java.net.SocketException: Unexpected end of file from server
|
||||
...
|
||||
ERROR: Failed to connect to elasticsearch at
|
||||
http://127.0.0.1:9200/_xpack/security/_authenticate?pretty.
|
||||
Is the URL correct and elasticsearch running?
|
||||
------------------------------------------
|
||||
--
|
||||
|
||||
. SSL/TLS is configured, but trust cannot be established. The command returns
|
||||
the following errors:
|
||||
+
|
||||
--
|
||||
[source, shell]
|
||||
------------------------------------------
|
||||
SSL connection to
|
||||
https://127.0.0.1:9200/_xpack/security/_authenticate?pretty
|
||||
failed: sun.security.validator.ValidatorException:
|
||||
PKIX path building failed:
|
||||
sun.security.provider.certpath.SunCertPathBuilderException:
|
||||
unable to find valid certification path to requested target
|
||||
Please check the elasticsearch SSL settings under
|
||||
xpack.security.http.ssl.
|
||||
...
|
||||
ERROR: Failed to establish SSL connection to elasticsearch at
|
||||
https://127.0.0.1:9200/_xpack/security/_authenticate?pretty.
|
||||
------------------------------------------
|
||||
--
|
||||
|
||||
. The command fails because hostname verification fails, which results in the
|
||||
following errors:
|
||||
+
|
||||
--
|
||||
[source, shell]
|
||||
------------------------------------------
|
||||
SSL connection to
|
||||
https://idp.localhost.test:9200/_xpack/security/_authenticate?pretty
|
||||
failed: java.security.cert.CertificateException:
|
||||
No subject alternative DNS name matching
|
||||
elasticsearch.example.com found.
|
||||
Please check the elasticsearch SSL settings under
|
||||
xpack.security.http.ssl.
|
||||
...
|
||||
ERROR: Failed to establish SSL connection to elasticsearch at
|
||||
https://elasticsearch.example.com:9200/_xpack/security/_authenticate?pretty.
|
||||
------------------------------------------
|
||||
--
|
||||
|
||||
*Resolution:*
|
||||
|
||||
. If your cluster uses TLS/SSL for the HTTP interface but the
|
||||
`elasticsearch-setup-passwords` command attempts to establish a non-secure
|
||||
connection, use the `--url` command option to explicitly specify an HTTPS URL.
|
||||
Alternatively, set the `xpack.security.http.ssl.enabled` setting to `true`.
|
||||
|
||||
. If the command does not trust the {es} server, verify that you configured the
|
||||
`xpack.security.http.ssl.certificate_authorities` setting or the
|
||||
`xpack.security.http.ssl.truststore.path` setting.
|
||||
|
||||
. If hostname verification fails, you can disable this verification by setting
|
||||
`xpack.security.http.ssl.verification_mode` to `certificate`.
|
||||
|
||||
For more information about these settings, see
|
||||
{ref}/security-settings.html[Security Settings in {es}].
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 245 KiB |
|
|
@ -1,28 +0,0 @@
|
|||
[[watcher-limitations]]
|
||||
== Watcher Limitations
|
||||
|
||||
[float]
|
||||
=== Watches Are Not Updated When File Based Scripts Change
|
||||
|
||||
When you refer to a file script in a watch, the watch itself is not updated
|
||||
if you change the script on the filesystem.
|
||||
|
||||
Currently, the only way to reload a file script in a watch is to delete
|
||||
the watch and recreate it.
|
||||
|
||||
[float]
|
||||
=== Watcher UI
|
||||
|
||||
When you create a new watch or edit an existing watch, if you navigate away
|
||||
from the page without saving your changes they will be lost without warning.
|
||||
Make sure to save your changes before leaving the page.
|
||||
|
||||
image::watcher-ui-edit-watch.png[]
|
||||
|
||||
[float]
|
||||
=== Security Integration
|
||||
|
||||
When {security} is enabled, a watch stores information about what the user who
|
||||
stored the watch is allowed to execute **at that time**. This means, if those
|
||||
permissions change over time, the watch will still be able to execute with the
|
||||
permissions that existed when the watch was created.
|
||||
|
|
@ -1,63 +0,0 @@
|
|||
[[watcher-troubleshooting]]
|
||||
== {xpack} {watcher} Troubleshooting
|
||||
++++
|
||||
<titleabbrev>{xpack} {watcher}</titleabbrev>
|
||||
++++
|
||||
|
||||
[float]
|
||||
=== Dynamic Mapping Error When Trying to Add a Watch
|
||||
|
||||
If you get the _Dynamic Mapping is Disabled_ error when you try to add a watch,
|
||||
verify that the index mappings for the `.watches` index are available. You can
|
||||
do that by submitting the following request:
|
||||
|
||||
[source,js]
|
||||
--------------------------------------------------
|
||||
GET .watches/_mapping
|
||||
--------------------------------------------------
|
||||
// CONSOLE
|
||||
// TEST[setup:my_active_watch]
|
||||
|
||||
If the index mappings are missing, follow these steps to restore the correct
|
||||
mappings:
|
||||
|
||||
. Stop the Elasticsearch node.
|
||||
. Add `xpack.watcher.index.rest.direct_access : true` to `elasticsearch.yml`.
|
||||
. Restart the Elasticsearch node.
|
||||
. Delete the `.watches` index:
|
||||
+
|
||||
[source,js]
|
||||
--------------------------------------------------
|
||||
DELETE .watches
|
||||
--------------------------------------------------
|
||||
// CONSOLE
|
||||
// TEST[skip:index deletion]
|
||||
+
|
||||
. Disable direct access to the `.watches` index:
|
||||
.. Stop the Elasticsearch node.
|
||||
.. Remove `xpack.watcher.index.rest.direct_access : true` from `elasticsearch.yml`.
|
||||
.. Restart the Elasticsearch node.
|
||||
|
||||
[float]
|
||||
=== Unable to Send Email
|
||||
|
||||
If you get an authentication error indicating that you need to continue the
|
||||
sign-in process from a web browser when Watcher attempts to send email, you need
|
||||
to configure Gmail to
|
||||
https://support.google.com/accounts/answer/6010255?hl=en[Allow Less Secure Apps to access your account].
|
||||
|
||||
If you have two-step verification enabled for your email account, you must
|
||||
generate and use an App Specific password to send email from {watcher}. For more
|
||||
information, see:
|
||||
|
||||
- Gmail: https://support.google.com/accounts/answer/185833?hl=en[Sign in using App Passwords]
|
||||
- Outlook.com: http://windows.microsoft.com/en-us/windows/app-passwords-two-step-verification[App passwords and two-step verification]
|
||||
|
||||
[float]
|
||||
=== {watcher} Not Responsive
|
||||
|
||||
Keep in mind that there's no built-in validation of scripts that you add to a
|
||||
watch. Buggy or deliberately malicious scripts can negatively impact {watcher}
|
||||
performance. For example, if you add multiple watches with buggy script
|
||||
conditions in a short period of time, {watcher} might be temporarily unable to
|
||||
process watches until the bad watches time out.
|
||||
Loading…
Reference in New Issue