We now moved from the logic of checking `indices:` and `cluster:` prefixes to determine whether an action is an indices or a cluster action... instead we use the index/cluster privielge `all` privilege to determine that (which is more accurate in the context of shield, as it enables us to move actions between the two categories while keeping their logical name intact)
Also updated the docs to reflect that template related actions are infact cluster actions.
Original commit: elastic/x-pack-elasticsearch@8027334105
Added `shield.user` setting so that the clients won't need to go through the unnatural and tedious process of configuring the `Authorization` header directly (that also requires the user to applicat the base64(username:password) logic.
Now, the user can just set the following settings to bind a user to the client:
```yaml
shield.user: 'username:password'
```
Original commit: elastic/x-pack-elasticsearch@94be3abd92
- nuked TrailLicense
- Move license expiry enforcement logic to LicensesService
- clean up ESLicenseManager
- make notification scheduling logic as lazy as possible
- make sure to notify from cluster changed only if needed
- added tests for notification
Original commit: elastic/x-pack-elasticsearch@e31b682f41
* Using cluster state listener to clear alerts when .alerts index is removed. (when running on multiple nodes the .alerts index is scattered so indices listener doesn't work).
* Remove the starting / loading thread and move the initial loading to cluster state listener.
Original commit: elastic/x-pack-elasticsearch@b8f41db2ea
Enforcing means that cluster actions will not be evaluated (as a fallback) by Index permissions. This enables us to move what typically would be considered indices actions and put them under the cluster privileges (a good example for this are all the template management APIs... we want to enforce cluster admin privileges over them).
Original commit: elastic/x-pack-elasticsearch@ee870954f2
* Made use of IndicesLifecycle, to catch when the .alerts index gets deleted, so we can clear the alerts
* Moved to concurrent hashmap in favour over normal hashmap with synchronized blocks
Original commit: elastic/x-pack-elasticsearch@5599d01c78
This commit renames the alerting package to alerts and will create the
alerts index on addAlert if needed.
Original commit: elastic/x-pack-elasticsearch@7cd691bd9b
Also added a logstash configuration for simple performance
testing (useful for comparing different hash functions)
Original commit: elastic/x-pack-elasticsearch@c9f08fbb12
Now the passwords are hashed in-memory using SHA2 by default (instead of original bcrypt). Also, it's now possible to configure the in-memory hashing algorithm.
Original commit: elastic/x-pack-elasticsearch@e2d1b3116b
Now, there are two types of supported patters:
- wildcards (default) - simple wildcard match where `*` indicates zero or more characters and `?` indicates a single character (`\` can be used as an escape charachter)
- regular expressions - can be "enabled" by wrapping the pattern in `/` (e.g. `/foo.*/`). The regex syntax is based on lucene's regex syntax (not Java's Pattern).
Closeselastic/elasticsearch#253
Original commit: elastic/x-pack-elasticsearch@edd912122d
Areek Zillur
Igor Motov
Paul Echeverri
uboness
Martijn van Groningen
Bill Hwang
Alexander Reelsen
Brian Murphy