News

Shield and Watcher 2.0.0-beta2 released

By
Uri Boness

Today, we are happy to announce the releases of Shield and Watcher 2.0.0-beta2. These are the last planned beta releases before the 2.0.0 release candidates.

IMPORTANT: These are beta releases and are intended for testing purposes only. There is no guarantee that either Shield or Watcher 2.0.0-beta2 will be compatible with their respective 2.0.0 GA.

DO NOT DEPLOY IN PRODUCTION

Shield

This release comes with some exciting new features in Shield.

When it comes to securing your data in Elasticsearch, one of the more commonly requested features is the ability to define access control on documents and fields. With Shield 1.x, you could simulate document level security using a combination of filtered aliases and index level permissions per role. While this approach works for some cases, there are certainly cases where this becomes unmanageable (due to the number of aliases and roles one needs to define). Furthermore, it is not a bulletproof solution as it doesn’t work for some of the APIs (e.g. parent/child searches), and it doesn’t provide any form of field level security.

We are delighted to announce that Document and Field Level Access Control will be a first class feature in Shield 2.0 and is introduced in this beta2 release. What does being a “first class feature” mean? Well… it is no longer bound to index aliases. Instead, you can define what documents and fields are accessible by role as part of the role definition. For field level access control you can now specify a list of accessible fields per index. For document level access control you can specify a query per index. These two together effectively create a filtered view of the index prior to any search executed by users with the relevant roles.

The following snippet shows what the configuration may look like as part of the role definition: 

us_customer_care:
  indices:
    'help_desk':
      privileges: read
      query:
        term:
          country_code: us
      fields:
        - issue_id
        - description
        - customer_email
        - customer_address
        - customer_phone

With the above role definition, users with the us_customer_care role will only have read access to help desk issues for customers in the US, and this read access is limited to a 4 fields - issue_id, description, customer_email, customer_address and customer_phone. All other fields will be treated as non-existent for this user and attempting to search on those will yield no results.

You can read more about Document and Field level security here.

Another feature we’ve added in this release is support for User Impersonation. With this support, it is now possible to enable a user to impersonate other users and by that execute requests on their behalf. User impersonation comes in handy when authentication is applied on the application level (outside of Elasticsearch/Shield), but the authorization should still be applied in Elasticsearch to ensure sensitive data is not compromised. Setting this “run_as” privilege is configured per role definition. As such, a best practice would be to create dedicated “run_as” roles for a set of impersonated users and assign this role to the relevant power users. The following snippet shows an example of such role: 

run_as_company_users: 
    run_as: *@company.com

The example above uses wildcards to defines a new role that enables users to impersonate any other user with a principal with @company.com suffix.

You can read more about user impersonation here.

Last but certainly not least, we’re excited to announce that we’ve opened up Shield for extensions. More specifically, you can now write a custom implementation of an authentication realm and plug it into Shield. If for any reason, you’re forced to use an authentication mechanism that is not supported out-of-the-box by Shield, you can now write your own plugin just for the authentication part and still use all the other goodness Shield has to offer, including the extensive role-based access control over indices, document and fields, secured communication using SSL and IP filtering and of course the tightly integrated audit logging.

To read more about extending Shield realms, please read the documentation. We’ve also created an example custom realm project to serve as a reference.

Watcher

One of the more common requests for watcher was the ability to disable watches. Often users define watches to monitor different systems. But there comes a time when you want to consciously bring a system down for maintenance. The problem then is that the monitoring watches continue to execute periodically triggering notification about the monitored system being down. One way to work around this issue is to modify the watch schedule to some remote date in the future, such that it won’t trigger for the duration of the system maintenance. But this is a wrong way to go about it. For this reason, we’ve introduced a new in/active state to the watches, and with that, the ability to de/activate a watch. An inactive watch is a watch that is still stored/registered with watcher, but is never triggered. You can now proactively deactivate the monitoring watches and keep them inactive as long as you need. Once you’re ready to continue monitoring your system, simply activate the monitoring watches. Read here for more information about the in/active state of a watch.

In addition to the above we’ve also added two new actions - hipchat and slack. If you or your organization uses either for internal communication, you can now send notifications to teams/rooms or to other users directly from watcher. In the spirit of watcher, all messages are templated, enabling sending detailed and rich messages. To read more about about these new actions please refer to HipChat Action and Slack Action.

Closing Note

2.0.0-beta2 introduces a wide range of new features in both Shield and Watcher. It also includes bug fixes and infrastructure enhancements in both products. Please refer to the release notes of Shield and Watcher for a complete change list.

If you have any questions or want to share your experience with us and the community, don't by shy and use our dedicated forums:

If you haven't tried either of these products yet, don't worry, it's not too late to start. You're welcome to visit the Shield and Watcher download pages where you'll be presented with a simple and quick getting started guide.