This commit adds a test to ensure that all request handlers are wrapped
by ProfileSecuredRequestHandler.
Original commit: elastic/x-pack-elasticsearch@26473d0ddc
Currently we copy the authorization header from every rest request to the action request. This is not
necessary because the user associated with each request is copied into the context and then if the
request leaves the node, the user will be serialized into a string and attached as a header.
This commit removes the copying of the authorization header as it is not necessary and by not copying
it, we limit the amount of copies we make of this sensitive information.
Original commit: elastic/x-pack-elasticsearch@4e5ba4b4aa
This commit adds document and field level security to Shield.
Field level security can be enabled by adding the `fields` option to a role in the `role.yml` file.
For example:
```yaml
customer_care:
indices:
'*':
privileges: read
fields:
- issue_id
- description
- customer_handle
- customer_email
- customer_address
- customer_phone
```
The `fields` list is an inclusive list of fields that controls what fields should be accessible for that role. By default all meta fields (_uid, _type, _source, _ttl etc) are also included, otherwise ES or specific features stop working. The `_all` field if configured, isn't included by default, since that actually contains data from all the other fields. If the `_all` field is required then this needs to be added to the `fields` list in a role. In the case of the content of the `_source` field and `_field_names` there is special filtering in place so that only the content relevant for the role are being returned.
If no `fields` is specified then field level security is disabled for that role and all fields in an index are accessible.
Field level security can be setup per index group.
Field level security is implemented at the Lucene level by wrapping a directory index reader and hides fields away that aren't in the `field` list defined with the role of the current user. It as if the other fields never existed.
* Any `realtime` read operation from the translog is disabled. Instead this operations fall back to the Lucene index, which makes these operations compatible with field level security, but there aren't realtime.
* If user with role A executes first and the result gets cached and then a user with role B executes the same query results from the query executed with role A would be returned. This is bad and therefore the query cache is disabled.
* For the same reason the request cache is also disabled.
* The update API is blocked. An update request needs to be executed via a role that doesn't have field level security enabled.
Document level security can be enabled by adding the `query` option to a role in the `role.yml` file:
```yaml
customer_care:
indices:
'*':
privileges: read
query:
term:
department_id: 12
```
Document level security is implemented as a filter that filters out documents there don't match with the query. This is like index aliases, but better, because the role query is embedded on the lowest level possible in ES (Engine level) and on all places the acquire an IndexSearcher the role query will always be included. While alias filters are applied at a higher level (after the searcher has been acquired)
Document level security can be setup per index group.
Right now like alias filters the document level security isn't applied on all APIs. Like for example the get api, term vector api, which ignore the alias filter. These apis do acquire an IndexSearcher, but don't use the IndexSearcher itself and directly use the index reader to access the inverted index and there for bypassing the role query. If it is required to these apis need document level security too the the implementation for document level security needs to change.
Closeselastic/elasticsearch#341
Original commit: elastic/x-pack-elasticsearch@fac085dca6
We have different types of templates in watcher - http request template, email template, hipchat message template, and simple text template... to avoid confusion, and clean up the codebase, this commit renames the `Template` class to `TextTemplate` to better convey what this template is about.
Original commit: elastic/x-pack-elasticsearch@8e5202019c
An action capable of sending notifications to rooms and users on hipchat. This actions support three types of HipChat APIs:
- `v1` - The (now deprecated) legacy API where a token can be registered at the group level, and the `v1` version of the API can be used. This API only supports room notification (users cannot be notified). multi-room notification is supported.
- `integration` - The basic integration that one can create in HipChat (it is using the `v2` API version), where notifications can be sent to a single room. User notification is unsupported by this API
- `user` - this API uses an API token of a specific user. An admin user can create an API token and configure it to have access to room notification and user private messaging. This API supports multi-room and multi-user notifications.
The settings for `hipchat` are very similar to the `email` infrastructure in nature. It is possible to configure multiple/different hipchat account, each is associated with the api type (a.k.a profile) - can be `v1`, `integration` or `user`, and the respective `auth_token`. When configuring the action in the watch, one can specify what hipchat account they would like to use (when not specifying an account, the `default_account` will be used). Each account can also specify its own unique `host`/`port` for the hipchat server - for full flexibility.
Closeselastic/elasticsearch#462
Original commit: elastic/x-pack-elasticsearch@9d9ee13542
In order to adhere to our elasticsearch core release script,
this script allows you to use a staging release to build x-plugins
against it, and then upload the created artifacts to the same
s3 bucket, so people can actually test the whole package of core
plus x-plugins.
Please read the documentation in the RELEASE.md document to understand
when to run which script!
Original commit: elastic/x-pack-elasticsearch@a43ce25b6f
PreProcessModule was an alternate way to customize another module's
behavior inside plugins. The preferred (and only in the future) way to
do this is with onModule in the plugin itself. This change moves the
only two remaining users of PreProcessModule to do so in their
respective plugins. The use case was adding roles for shield
authorization, but these roles were really static, so there was no
reason they could not be configured up front.
Original commit: elastic/x-pack-elasticsearch@e67ac2dcb6
Martijn van Groningen
jaymode
Jason Tedor
David Pilato
Boaz Leskes
Tanguy Leroux
debadair
Areek Zillur
uboness
Alexander Reelsen
Simon Willnauer
Robert Muir
Ryan Ernst