- core-shaded - has CryptUtils (used by core and can be shared with consumer plugins)
- core - License data structures & verifier
- licensor - License Signer along with key-pair and license generation, verification
- plugin - Enforce licensing on a deployment
Original commit: elastic/x-pack-elasticsearch@041ef3a9f1
This gives us more control over interrupting and joining this thread during stopping, so we have a good moment in time to clear the queue.
Original commit: elastic/x-pack-elasticsearch@ed3f85fa75
tests.timezone and tests.locale are values that gets randomized all the time (even without configuring them). They don't get printed yet out with shield failures as this was only recently added to es core, but it makes sense to get ready and allow to configure them for better test repeatability.
Also removed support for es.node.mode and es.node.local as we always use network since we test with unicast discovery only.
Original commit: elastic/x-pack-elasticsearch@d03fa0c162
This commit makes the alert history index a time based index.
The alert history now is a timebased index prefixed with .alert_history_
with the time fomat YYYY-MM-dd.
This commit makes the alert history index a time based index.
Original commit: elastic/x-pack-elasticsearch@df6d6dee29
Today it is possible to configure 3 realms in shield - `esusers`, `ldap` and `active_directory`. These realms are created once based on the configuration. There are several problems with this approach:
- Taking `ldap` as an example, it is currently not possible to have multiple `ldap` realms configured (where one serving as a fallback for the other). While the `ldap` realm itself enables defining multiple ldap URLs, it has the limitation that the fallback LDAP must have the exact same configuration as the primary LDAP (+ there's the limitation that all URLs must either us SSL or not... there cannot be a mix of SSL URL and a normal URL)
- The realms are created and bound internally by guice. This will limit the configurability at runtime of the realms which we might want to introduce in shield 2.0.
This commit changes the way realms are managed & configured. Instead of having guice bind the realms themselves. A new realm factory construct will be introduced. The realm factory will represent a realm type and guice will bind these factories. At load time, we'll read the configuration and based on the types of the configured realms, the relevant factories will create the realms based on the settings. This means that potentially we can expose the realms as a dynamic configuration and rebuild the realm chain at runtime.
A nice side effect of this approach is that the multiple URLs feature that is currently supported by both `ldap` and `active_directory` can be dropped. Instead, the users will just need to configure multiple `ldap`/`active_directory` realms.
Closes: elastic/elasticsearch#370
Original commit: elastic/x-pack-elasticsearch@3232f153bb
Every test class was previously running against its own SUITE cluster composed of a single node due to misconfiguration.
Also there were some repetitions and bugs in the settings: first of all unicast wasn't properly configured, also the plugin wasn't registered properly in the transport client, thus the "shield.user" settings wasn't properly converted into the basic auth header. For the very same reason the settings used for authc wasn't randomized for transport client.
Extracted out all the needed configuration to the `ShieldSettingsSource` class, that takes care of the unicast configuration, loading of the plugin and all of the configuration files and parameters.
Used the global cluster whenever possible, that has the following characteristics:
- unicast discovery
- ssl configured and enabled at the transport level
- ssl configured but disabled at the http level (REST tests use the same cluster and don't support SSL at this time)
- single user configured with an allow_all role
- auditing enabled or not is randomized
- the setting used to do basic auth is randomized between reuest.headers.Authorization and our own shield.user for both node and transport client
Test classes that need to override defaults settings can do so by declaring scope=SUITE and overriding the nodeSettings method. Also roles, users and users_roles have specialized methods to be overridden that just return the content of the whole file if it differs from the default. Note that given that ssl is properly configured although disabled for http, tests that need it on can just enable it without any additional configuration.
Closeselastic/elasticsearch#31
Original commit: elastic/x-pack-elasticsearch@fa6f162497
Although it is nice to be alerted through assert as soon as we upgrade the es core dependency, this can be done only in test code, in production code it prevents us from supporting any future version once the code gets released.
Replaced the assert with a TODO.
Original commit: elastic/x-pack-elasticsearch@b0d59c2fd3
javanna
Areek Zillur
Martijn van Groningen
Brian Murphy
Paul Echeverri
uboness