Integrating Watcher with Shield

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 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:

monitor - grants access to Watcher stats and get APIs in addition to all monitoring APIs.
manage - grants access to all Watcher APIs and cluster management APIs.

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

edit

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.

Handling Sensitive Information

edit

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 sensitive information.

Watch Data Encryption

edit

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 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

edit

The 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.

« Configuring Watcher to Send PagerDuty Events Integrating Watcher with Logstash »