- SSLService needs to be lazy loaded (only loaded when required). Guice provider doesn't seem to work as all singleton bindings are forced to be loaded eagerly. For this reason, a new `SSLServiceProvider` is introduced and is injected wherever the SSLService might be needed (SSLService is never injected directly)
- `IPFilteringN2NAuthenticator` is now always injected and used. enabling/disabling the filtering is handled within the `IPFilteringN2NAuthenticator` and the `SecuredMessageChannelHandler` on the transport is always set. Although we add another handler to netty's event chain (even while having ip filtering disabled), the overhead of this handler is negligible and this will also enabled enabling/disabling filtering at runtime (if we choose to support it) via API later on.
Original commit: elastic/x-pack-elasticsearch@cd44ecd6ac
- 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
