Integrating Watcher with Shield
editIntegrating Watcher with Shield
editWatcher can work alongside Shield and integrates with it. This integation is expected to be extended in future releases.
When the Watcher plugin is installed alongside Shield, Watcher registers an
internal user, __watcher_user
. All actions Watcher performs when executing
watches are performed as this user.
The __watcher_user
is internal to Watcher. You cannot submit requests
as this user.
Watcher actions fall under Shield’s cluster level privileges:
To grant a user access to the Watcher APIs, assign these privileges to a role and assign the role to the user.
POST /_shield/role/watcher_admin { "cluster": ["monitor", "manage"] } POST /_shield/user/watcher_admin_user { "password" : "changeme", "roles" : [ "watcher_admin"], }
For more information about creating and assigning roles, see Managing Roles and Managing Native Users.
Privileges On Watcher Internal Indices
editWatcher 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.
Handling Sensitive Information
editSometimes 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
sensitive information.
Watch Data Encryption
editBy 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
elasticsearch.yml
file:watcher.shield.encrypt_sensitive_data: true
By default (when not set), the sensitive data will be index in plain text (same behaviour as when shield is not installed)
Sensitive Data in Configuration Files
editThe elasticsearch.yml
file can contain sensitive data such as the SMTP credentials that
are used by Watcher to send email.
Currently, neither Watcher nor Shield provide a mechanism to encrypt settings
in elasticsearch.yml
. Because it can contain sensitive data,
you should limit access to elasticsearch.yml
to the user that you use to run Elasticsearch.
When Shield is installed, these sensitive settings are omitted from the output of the Nodes Info API.