We only need it to be so fast when starting up. We can slow it
down once it has started so shutdown isn't problematic.
Original commit: elastic/x-pack-elasticsearch@052d64402f
* [Monitoring] Use Suffix with Marvel Index alias
Using a suffix allows a non-aliased Monitoring index get created for _today_. Otherwise the time-based index for today cannot be created.
Original commit: elastic/x-pack-elasticsearch@92e7695a2c
These tests were failing for me locally with this reproduction
line about 80% of the time:
```
gradle :x-plugins:elasticsearch:integTest -Dtests.seed=660D249EDCC648E5 -Dtests.class=org.elasticsearch.xpack.monitoring.OldMonitoringIndicesBackwardsCompatibilityIT -Dtests.method="testOldIndexes" -Dtests.security.manager=true -Dtests.jvms=12 -Dtests.locale=vi-VN -Dtests.timezone=Arctic/Longyearbyen
```
This was due to the ten second collection interval lining up with the
10 second sleep in `assertBusy`. Eventually the collection interval
lines up in such a way that it take more than ten seconds total to
create the alias for the monitoring index. 😢
This fixes that by dropping the interval to 100ms, making the test
no longer fail with that seed and succeed much more quickly. 😄
Relates to elastic/elasticsearch#3951
Original commit: elastic/x-pack-elasticsearch@b5dfa6ef7d
Those tests ran 35 seconds on my local notebook. By not using a sleep based
scripting engine and some other tweaks the time is down to 13 seconds.
Also renamed the class to remove the `Slow` prefix.
Original commit: elastic/x-pack-elasticsearch@5289fe8dab
Moves the tests for aliases starting with `-` into the backwards
compatibility tests because we can no longer create such aliases.
Original commit: elastic/x-pack-elasticsearch@3639fe4d46
* [Monitoring UI] Show Replica Count not Replication Factor in Overview
This changes it to only show the replica count as `total - primaries` rather than showing the replication factor, which is particularly unhelpful when different indices have different replica counts.
Original commit: elastic/x-pack-elasticsearch@552f94bf8f
`action.destructive_requires_name` setting was ignored by the security plugin as wildcards got expanded and resolved in the plugin before es core could actually check if the operation was supposed to be allowed or not. We are discussing how we could perform the check earlier in es core, but anyways it is good to perform the same check in the security plugin just to make sure.
Closeselastic/elasticsearch#3689
Original commit: elastic/x-pack-elasticsearch@3414cb3471
The old handling was not thread safe, as it used to replace volatile
objects in the code. This implementation uses a concurrent hashmap
to easily allow adding/removing schedules without having to replace
whole objects
Original commit: elastic/x-pack-elasticsearch@0aa618b372
When parsing chain inputs there were possibilities to write invalid
JSON that resulting in losing the order of the inputs without any
exception being thrown.
This commit makes the parsing more strict.
Closeselastic/elasticsearch#3736
Original commit: elastic/x-pack-elasticsearch@963641ee2b
Currently security always parses the permissions filters with a shard id equal
to `0` even if the query is executed on a different shard. Also it does not
protect against queries that may rely on the current timestamp even though we
don`t currently have ways to make sure that all shards use a consistent
timestamp.
Sibling of elastic/elasticsearchelastic/elasticsearch#21196.
Original commit: elastic/x-pack-elasticsearch@cab47f2ed2
The execution time of the trigger tests was extremely slow, because it
really waited until executions happened. This uses the mock clock to
advance in time manually.
This also allows to remove the bad apples annotation and make sure that
the schedule engine tests for both implementations are run all the time.
Relates elastic/elasticsearch#1007
Original commit: elastic/x-pack-elasticsearch@f9436f506f
Refactored ScriptType to clean up some of the variable and method names. Added more documentation. Deprecated the 'in' ParseField in favor of 'stored' to match the indexed scripts being replaced by stored scripts.
Original commit: elastic/x-pack-elasticsearch@d7c7bd7362
My current assumption is, that creating the templates is not
yet finished (as this is async), so that we need to add
another check that the templates have been added before
continuing.
Relates elastic/elasticsearch#3892
Original commit: elastic/x-pack-elasticsearch@3880d200a1
Today we have the same madness in two places and no dedicated test. This
change moves the real madness into a single place and adds a test for it
to make sure it actually works and isn't just crazy.
Original commit: elastic/x-pack-elasticsearch@dabf5fdd63
We used to be very lenient with all kinds of exceptions related to the
`.security` index. Yet, sometimes in tests the index is not yet there but
transport clients already pinging the node this causes issues and transport
clients disconnect. Now if the index is not present we simply return no role.
Original commit: elastic/x-pack-elasticsearch@60948d0c2a
TransportGetRolesAction optimizes for single role case while this
optimization can be simply inside the NativeRoleStore and being
way more contained.
Original commit: elastic/x-pack-elasticsearch@c43d8ba341
`TransportGetUsersAction` does some funky blocking calls even though
it's specifying `SAME` as the thread-pool indicating that it's fast or
forking off quickly. Both might not be true today. This change adds
async support to the methods it calls without breaking the existing
Realm interface. Yet, we might need to do this down the road.
Original commit: elastic/x-pack-elasticsearch@d0959f87f3
This changes adds a special value for negative role lookups so that we can avoid scenarios
where we overload the cluster due to continually trying to load non-existing roles as is often
the case when `unmapped_groups_as_roles` is used with the active directory realm.
Relates elastic/elasticsearch#3530
Original commit: elastic/x-pack-elasticsearch@62567b4c22
* security: restore the correct user when switching to the system user
For internal actions where we need to switch to the SystemUser, we should always restore the proper
context after execution. We were restoring an empty context for actions executed by the SystemUser
in the SecurityServerTransportInterceptor.
In order to accomplish this, a few changes have been made. Both the SecurityServerTransportInterceptor
and the SecurityActionFilter delegate to `SecurityContext#executeAsUser` when a user switch is necessary.
Tests were added for this method to ensure that the consumer is executed as the correct user and the proper
user is restored.
While working on this, a few other cleanups were made:
* SecurityContext can never have a null CryptoService, so a null check was removed
* We no longer replace the user with the system user when the system user is already associated with the request
* The security transport interceptor checks the license state and if auth is not allowed, delegate and return
* The security transport interceptor sendWithUser method now requires authentication to be present or a hard
exception is thrown.
* The TransportFilters integration test has been deleted. This was integration test that relied on the ability to
get instances from a node and trace the execution. This has been replaced by additional unit tests in
ServerTransportFilterTests
Closeselastic/elasticsearch#3845
Original commit: elastic/x-pack-elasticsearch@d8bcb59cb7
This change removes the blocking notion from fetching the roles
from a remote index. This also removes the blocking client calls
that can potentially deadlock a request if executed on the transport
thread.
Relates to elastic/elasticsearch#3790
Original commit: elastic/x-pack-elasticsearch@c2eda39043
This change now installs a signed license that has been generated at runtime so the
BWC tests can run without hitting licensing issues. The x-pack BWC tests pull in the
full cluster state, which contains the trial license from when the indices and state
was generated. After the trial license period and grace period issues arise with the
tests.
Closeselastic/elasticsearch#3858
Original commit: elastic/x-pack-elasticsearch@1c79e874e5
Today when a request is executed with InternalClient the thread context might
be lost if another component like security exchanges it by executing an async call
or an internal action. This can be a serious security problem since if the async
call executes as the system user all subsequent calls made by the response
thread will also execute as the system user instead.
Original commit: elastic/x-pack-elasticsearch@80682f338d
Nik Everett
Chris Earle
Areek Zillur
Ryan Ernst
Alexander Reelsen
Jay Modi
Clinton Gormley
Luca Cavanna
Boaz Leskes
Adrien Grand
Jack Conradson
Yannick Welsch
Simon Willnauer
Jason Tedor
Simon Willnauer
Spencer
spalger
Tim Sullivan
CJ Cenizal