In order to fix various issues with the SSL service, the following cleanups have been done
* Removed SSLServiceProvider and all the lazy loading magic
* Do not try to create an SSLContext in the constructor. According to Guice docs the constructor
should only be used ever for variable declarations but not business logic. This also fixes a nasty
OOM, in case an exception was thrown in the constructor, because Guice tried to recreate that class
in an endless loop
* Get responsibilities right (which resulted in this nasty lazy loading provider design).
The SSLService allows to create a SSLEngine at the time you need it, but you need to supply
specific configuration if you want it to instead of using the default configuration
and creating a SSLContext on startup like we did before.
All changes are internal.
Closeselastic/elasticsearch#454Closeselastic/elasticsearch#453
Original commit: elastic/x-pack-elasticsearch@7ca49f781c
The shield test infra already verifies that the plugin is loaded before each test, it makes little sense to check again in this specific test. Left the second part that tests the shield info endpoint and renamed the test method
Closeselastic/elasticsearch#423
Original commit: elastic/x-pack-elasticsearch@ac2d566c42
Build number maven plugin requires this info to retrieve the build number and make it available as a variable, which is then published through RestShieldInfoAction, which is currently null. This commit makes sure the build number gets currently published.
Closeselastic/elasticsearch#428
Original commit: elastic/x-pack-elasticsearch@0a2bc7646b
- where the licenses were enabled on any cluster event. Instead they should only be enabled either explicitly by the test or at start up.
- also modified `ShieldActionModule` to for `ShieldActionFilter` to be bound as an eager singleton (es core doesn't define the scope for the registered action filters)
Original commit: elastic/x-pack-elasticsearch@47ac0d2e6f
- Added a `LicenseService` to handle license feature enable/disable events
- LicenseEventNotifier is responsible for notifying the license events to whatever registered listeners that are interested in them
- In Shield, when a license is disabled for `shield` feature, we block all read operations (done in the `ShieldActionFilter`)
- Added initial documentation around licensing
Closeselastic/elasticsearch#347
Original commit: elastic/x-pack-elasticsearch@6ba7a10cd4
This is a little cleanup to only iterate IP filter rules for each
profile instead of iterating all of them and check for the profile
inside of the rule.
Original commit: elastic/x-pack-elasticsearch@6774f1f165
The locale is being randomized but never printed out for now (fixed upstream but we still depend on 1.4.0). We need to temporarily log it out manually to debug some test failures that might be related to the locale randomization (in combination with build machines settings).
Original commit: elastic/x-pack-elasticsearch@6f7e9625d1
Every random call should happen all the time on all platforms (unless randomized!), otherwise tests won't reproduce on different platforms.
Original commit: elastic/x-pack-elasticsearch@d5b2d2079c
This PR allows to configure different ServerTransportFilters per profile.
By default there is a `server` transport filter, that does authentication
and a `client` on that rejects internal actions and shard actions.
Closeselastic/elasticsearch#312
Original commit: elastic/x-pack-elasticsearch@1ce66495a5
In order to fixelastic/elasticsearch#378 a problem was revealed, that the ip filter for HTTP was
always the one for the default profile, which lead to failed tests (along
with wrong socket connections, which made the test go green irregularly).
This commit fixes the tests and allow to configure own HTTP ip filters, adding
the following settings
* shield.http.filter.enabled
* shield.http.filter.allow
* shield.http.filter.deny
If not specific settings are configured, the one of the default profile are used.
Closeselastic/elasticsearch#378
Original commit: elastic/x-pack-elasticsearch@89dbaefe9a
N2NAuthenticator was not really used. Only the ip filtering authenticator was used, and was used directory (no use for a generic interface). `IPFilteringN2NAuthenticator` is now `IPFilter` and all relevant classes were moved to `shield.transport.filter` package.
Original commit: elastic/x-pack-elasticsearch@43f6faeb4b
In order to not require client side SSL certs for transport clients
another option was added in the profile configuration to enable
or disable client side certs. The same option has also been added
for HTTP.
Original commit: elastic/x-pack-elasticsearch@9658598bdc
Force validation of eusers username & password, and the role names.
role names and usernames follow the following validation rule:
```
A valid name must be at least 1 characher and no longer than 30 characters. It must begin with a letter (`a-z` or `A-Z`)
or an underscore (`_`). Subsequent characters can be letters, underscores (`_`), digits (`0-9`) or any of the following
symbols `@`, `-` or `$`
```
passwords must be at least 6 characters long.
Closeselastic/elasticsearch#399
Original commit: elastic/x-pack-elasticsearch@e6be51b357
Local gateway has been removed in core, but it's a master only change. If we don't set it to local in our settings, we end up using the none gateway and KnownActionsTests fails because the local gateway endpoint are not registered to core.
Original commit: elastic/x-pack-elasticsearch@9bb550329f
Local gateway has been removed in core, but it's a master only change. If we don't set it to local in our settings, we end up using the none gateway and KnownActionsTests fails because the local gateway endpoint are not registered to core.
Original commit: elastic/x-pack-elasticsearch@c3bc37df4b
This class will be deleted when we'll depend on the next version, for now we forked it and we have to keep it up-to-date
Original commit: elastic/x-pack-elasticsearch@0d7cfdfe3d
We currently run with ssl always on on the transport layer, which means that we never test with ssl off. We found bugs in the past caused by the ssl classes being loaded even when ssl was disabled, those should be caught by this new randomization.
Added method to override whether ssl is enabled or not for SUITE and TEST tests, called sslTransportEnabled(). A couple of tests do require ssl always on, thus they enable it through that method, which means that both nodes and transport client will have the keystore configured and ssl enabled on the transport.
Note that ssl on http is not touched here, that stays off by default unless enabled specifically in SUITE or TEST tests.
Closeselastic/elasticsearch#396
Original commit: elastic/x-pack-elasticsearch@63061b97ff
This replaces the use of the logger in the IPFilteringN2NAuthenticator with the
AuditTrail, so that the connection granted or denied messages will now be seen
with the rest of the audit output.
Closeselastic/elasticsearch#101
Original commit: elastic/x-pack-elasticsearch@10218a45a9
- 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
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
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
@NotThreadSafe is not a valid standard java annotation. Removed unused method and empty @param javadoc annotation
Original commit: elastic/x-pack-elasticsearch@3583bcfa66
The goal of TESTING.asciidoc is not to repeat what's already in the elasticsearch core test cheatsheet, but only add what is different in shield.
Original commit: elastic/x-pack-elasticsearch@51ad3894d2
javanna
c-a-m
Alexander Reelsen
jaymode
uboness
Paul Echeverri