Watcher can work alongside Shield and integrates with it. This integation is expected to be extended in future releases.
When the Watcher plugin is installed along side Shield, it will automatically register an internal
__watcher_user. All actions taken as part of a watch execution will be executed on behalf
of this user.
__watcher_user is internal to watcher. Sending executing API on behalf of that users
outside of watcher will fail (unless you specifically add such a user to any of the
In addition to that, Watcher also registers with Shield two additional cluster level privileges:
You can use the privileges above in Shield’s
file to grant roles access to the watcher APIs. The following snippet shows an example of such role
watcher_admin: cluster: manage_watcher
Once the relevant role was defined, adding the watcher administrator user requires the exact same
process as adding any other user to to Shield. For example, if you are using the
esusers realm, use the
command-line tool to add
bin/shield/esusers useradd john -r watcher_admin
Once added, this user will be able to call all the watcher APIs and by that manage all watches.
Watcher stores its data (watches and watch history records) in its own internal indices:
.watches- an index that stores all the added watches
.watch_history-<timestamp>- time based indices that store all the watch records
All write operations on these indices are performed internally by Watcher itself and external users should not write directly to them. It should be considered a best practice to not grant any write privileges on these indices to any of the Shield users.
Sometimes a watch may hold sensitive information. For example, the user password that is configured
as part of the basic authentication in the
http input. In
addition, some of watcher configuration may also hold sensitive data. When Shield is installed,
Watcher can utilize some of the security services it provides to better secure this type of
By default, Watcher simply stores this sensitive data as part of the watch document in the
.watches index. This means that the password can be retrieved in plain text by executing a
document GET or any search of the available operations in elasticsearch over that index.
The Get Watch API will automatically filter out this sensitive data from its response.
When Shield is installed, it is possible configure watcher to use shield and encrypt this sensitive data prior to indexing the watch. This can be done by:
- Ensuring Shield’s System Key is set up and used
Add the following settings in the
By default (when not set), the sensitive data will be index in plain text (same behaviour as when shield is not installed)
elasticsearch.yml file may also hold sensitive data. For example, the SMTP credentials that
are configured as part of the email accounts.
As for now, neither Watcher nor Shield provide a mechanism to encrypt settings in this file. It is a best practice to ensure that access to this file is limited to the user under which the elasticsearch instance is running.
In addition to that, When Shield is installed, these settings will be filtered out from the REST Nodes Info API.