In order to be able to execute a watch as the user, who stored the
watch, this commit stores certain headers of the thread context, that
was used when the watch was stored.
Upon loading the watch the headers are loaded and applied for the
following watcher execution features
* search transform
* search input
* index action
A special case is the execute watch API, which overrides the headers loaded
from the watch with the one of the current request, so that a user
cannot execute this watch with other privileges of the user who stored it.
Only the headers "es-security-runas-user", "_xpack_security_authentication" are
copied for now, as those are needed for our security features.
The headers are stored in watch status in the watch and are not returned by default,
when the GET Watch API is used. A search reveals those of course.
relates elastic/x-pack-elasticsearch#2201
Original commit: elastic/x-pack-elasticsearch@9803bd51c2
Fixes to the build system, particularly around BWC testing, and to make future
version bumps less painful.
Original commit: elastic/x-pack-elasticsearch@a1d456f30a
This change removes the InternalClient and the InternalSecurityClient. These are replaced with
usage of the ThreadContext and a transient value, `action.origin`, to indicate which component the
request came from. The security code has been updated to look for this value and ensure the
request is executed as the proper user. This work comes from elastic/x-pack-elasticsearch#2808 where @s1monw suggested
that we do this.
While working on this, I came across index template registries and rather than updating them to use
the new method, I replaced the ML one with the template upgrade framework so that we could
remove this template registry. The watcher template registry is still needed as the template must be
updated for rolling upgrades to work (see elastic/x-pack-elasticsearch#2950).
Original commit: elastic/x-pack-elasticsearch@7dbf2f263e
Room names in hipchat were not properly URL encoded, thus room names
with spaces would not work as expected. This fixes all the hipchat
accounts by properly using spaces.
Also the hipchat tests are reenabled, as the IT team gave me new access to hipchat,
allowing to create a fresh set of oauth tokens for the integration account type.
The HipchatServiceTests have also been converted to XPackSingleNodeTestCase
relates elastic/x-pack-elasticsearch#2371
relates elastic/x-pack-elasticsearch#2429
Original commit: elastic/x-pack-elasticsearch@9f8872f686
This commit changes the IndexLifecycleManager's handling of variables about an index to only update
all of the values at a single time. Previously, all of the index state variables were volatile
members of the IndexLifecycleManager, which meant we could get an inconsistent view of the index
state. Although rare, this is still incorrect so this change adds a single volatile variable that
holds the state as of the last processed cluster state update.
Additionally, the IndexLifecycleManagerIntegTests were updated to have more concurrency and further
stress this portion of the code and its checks.
relates elastic/x-pack-elasticsearch#2973
Original commit: elastic/x-pack-elasticsearch@5f1552b298
This commit adds the manage_index_templates permission to the kibana_system role that is used by
the kibana system user. This is needed due to an upcoming feature in kibana where a index template
will be used to create the saved objects index.
relates elastic/x-pack-elasticsearch#2937
Original commit: elastic/x-pack-elasticsearch@85a67c73aa
Some of our REST tests open many jobs, and assuming each will use 1GB of
RAM on a single node cluster could fail the test. The solution is to
explicitly say the test jobs will use very little RAM.
Original commit: elastic/x-pack-elasticsearch@a3fcfc4589
Currently, any errors that occur during the DeleteExpiredDataAction are logged and the deletion proceeds to the next job. The user will get no indication in the response that something went wrong although nothing should really go wrong unless the cluster is messed up.
This commit changes this so that errors are reported back to the action.
Original commit: elastic/x-pack-elasticsearch@489cf03c3e
This change modifies the way ML jobs are assigned to nodes to primarily
base the decision on the estimated memory footprint of the jobs. The
memory footprint comes from the model size stats if the job has been
running long enough, otherwise from the model memory limit. In addition,
an allowance for the program code and stack is added.
If insufficient information is available to base the allocation decision on
memory requirements then the decision falls back to using simple job
counts per node.
relates elastic/x-pack-elasticsearch#546
Original commit: elastic/x-pack-elasticsearch@b276aedf2f
tool. However, this is a forbidden API so this commit replaces it with URI#getPath. Additionally,
the tests fail with a security manager permission error due to the use of Mockito for exception
throwing. This commit still uses Mockito for throwing exceptions but does it differently in a way
that is acceptable by our test security policy.
Original commit: elastic/x-pack-elasticsearch@5e1d45acf8
Fixes bug when the url option had trailing slashes. The URL built
was invalid (consecutive fwd slashes) but the failure errors of
the subsequent requests were ignored.
URL is built correctly from the option spec.
True HTTP errors and Exceptions are logged and the cmd fails.
relates elastic/x-pack-elasticsearch#2778
Original commit: elastic/x-pack-elasticsearch@62b2d94ca0
Changes to further prepare for feature split with regards to watcher:
- CryptoService has been moved into watcher
- CryptoService.generateKey() has been moved into SystemKeyTools, only
used there
- The creation of the http client/notification classes have been moved
into watcher, no further dependencies on watcher in XPackPlugin
- Each subproject now registers it's own named writeables
Relates elastic/x-pack-elasticsearch#2925
Original commit: elastic/x-pack-elasticsearch@a60c98ba7e
This problem was introduced due to distributed watch execution.
When a node newer than the master node joins the cluster and gets a
.watches shard assigned it is supposed to start watcher. However
when a new version of the watch history template is part of that new
node (and we might increase that version anytime), this template does
not get installed, because only the master node is updating watcher
templates.
This commit checks if the local node version is higher than the master
node version and then also puts missing templates.
Currently this is done for all watcher templates, not only the watcher history.
relates elastic/x-pack-elasticsearch#2944
Original commit: elastic/x-pack-elasticsearch@4960231ea7
* Add "client-api-objects" dependency for xpack plugin and transport-client
This adds another gradle project, "client-api-objects" which is intended to be a
common dependency so that the xpack plugin and transport-client can share the
same Request and Response objects.
Relates to elastic/x-pack-elasticsearch#2925
Original commit: elastic/x-pack-elasticsearch@a6d83299d0
This is related to elastic/elasticsearch#elastic/x-pack-elasticsearch#27388. It modifies x-pack to
be compatible with the removal of the delegating transport channel.
Original commit: elastic/x-pack-elasticsearch@3bd7bf6773
When there were no accounts configured, watcher returned a cryptic
error message containing 'null' in the description. This fix returns
a more clear error message.
On top a dedicated NotificationServiceTests class was added to remove
redundant test cases in the hipchat/jira/slack unit tests, that all
basically tested NotificationService capabilties.
relates elastic/x-pack-elasticsearch#2666
Original commit: elastic/x-pack-elasticsearch@45d0d1df31
* Rename REST spec xpack.deprecation.info to xpack.migration.deprecations
* Fixed parameter-type naming in xpack.ml.get_model_snapshots
* Fixed QS multi-cluster search test to use cluster.remote_info
Original commit: elastic/x-pack-elasticsearch@ccd35b4a6c
Today persistent tasks is only usable from machine learning, but others like ccr will need to use it too.
With this change ccr and other will be able to make use of it too.
Original commit: elastic/x-pack-elasticsearch@c90f01d5f6
This commit adds checks to the TribeWithSecurityIT tests to ensure that the security index is
writeable before making modification operations. Otherwise, we hit errors in tests that are not
always reproducible.
relates elastic/x-pack-elasticsearch#2977
Original commit: elastic/x-pack-elasticsearch@c29bdff7ae
In elastic/x-pack-elasticsearch#2901, the dependency on the tribe module was removed but a few leftover references were missed
in the build.gradle file of the x-pack-elasticsearch plugin. This commit removes these leftover
references.
Original commit: elastic/x-pack-elasticsearch@03f1cae1f5
In order to prepare for separate source directories, this commit moves
a few packages back into the watcher namespaces. A few of them have been
moved out previously as we thought that it might make sense to have a
dedicated notification API. This wont be the case for watcher on ES
anymore, so we can safely move those back into the watcher space.
Packages affected by this move:
* org.elasticsearch.xpack.common.http
* org.elasticsearch.xpack.common.text
* org.elasticsearch.xpack.common.secret
* org.elasticsearch.xpack.common.stats
* org.elasticsearch.xpack.support
* org.elasticsearch.xpack.notification
Tests have been moved accordingly.
The class `XContentUtils` has been split into one implementation for
watcher and one for security as different methods were used.
Relates elastic/x-pack-elasticsearch#2925
Original commit: elastic/x-pack-elasticsearch@0aec64a7e2
Our tests currently rely on waiting for the security index to be available in some cases and in
CI, these checks have been timing out. This commit increases the amount of time that we will wait
for the index before failing to account for slow machines.
Original commit: elastic/x-pack-elasticsearch@639dccd5cb
This checks if `apm-*` indices exist in the cluster to try to determine if APM is in use on the Elasticsearch cluster.
Original commit: elastic/x-pack-elasticsearch@7f9a9a4eee
On Windows, log4cxx always writes to stderr in UTF-16, and we get the
logs from C++ to Java by redirecting stderr to our named pipe. Hence
the log handler in Java needs to tolerate the log stream it's reading
being either UTF-16 (for Windows) or UTF-8 (for other platforms).
Fixeselastic/machine-learning-cpp#385
Original commit: elastic/x-pack-elasticsearch@89237d7125
This kind of sucks, because we shouldn't have to wait that long for tests to run.
But they're failing CI with some regularity, and we rely on these integration tests.
Original commit: elastic/x-pack-elasticsearch@3f4acb2a32
This is a forward-port of elastic/x-pack-elasticsearch/pull/2921.
original commit message:
Before this commit, a cluster with security enabled and backed by
native-realm user permissions allowed rolled upgrades to clusters without
upgrading the `.security` index. This resulted in the newly established
6.0 cluster not able to register the native-realm users previously established
in the `.security` index. In order to fix this, one would have to rely on file-based
users to re-configure and upgrade the `.security` index. Since this state is easily
avoidable with an upgrade, this commit rejects the joining of upgraded nodes without
upgrading the security index beforehand.
modifications:
Test with 7.x vs 6.x nodes.
Original commit: elastic/x-pack-elasticsearch@56f81bfb20
This commit updates the logic for determining which branch to use to make it consistent with the
logic in elasticsearch. This change means that testing BWC within the same major picks the correct
branch.
Original commit: elastic/x-pack-elasticsearch@2d75d15c41
This adds a rolling upgrade test for X-Pack monitoring. It works by using the `_xpack/monitoring/_bulk` endpoint to send arbitrary data, then verify that it exists.
This forces a few things to happen, thereby testing the behavior:
1. The templates must exist.
2. The elected master node must be "ready" to work (hence the first
point).
3. The same "system_api_version" is accepted by every version of ES.
Original commit: elastic/x-pack-elasticsearch@012e5738bb
Improving logging for unexpected autodetect termination (crash, oom). Output to the log pipe not conforming to the json log output format are treated as fatal error and logged, so that the crash as well as a proper error message if available gets logged.
Original commit: elastic/x-pack-elasticsearch@ae5d792d3f
This change should have been made in elastic/x-pack-elasticsearch#2913. Now we hold the process
context lock throughout the job close procedure, the timeout for trying
to lock it should be the timeout used for job open/close rather than the
timeout for connecting named pipes.
Original commit: elastic/x-pack-elasticsearch@79672b0825
This change removes the xpack plugin's dependency on the tribe module, which is not a published
artifact. For the most part this just involves moving some test classes around, but for the
security and tribe integration the usage of constant settings was removed and replaced with the
string names. This is a bit unfortunate, but a test was added in a QA project that depends on tribe
that will alert us if a new setting is added that we need to be aware of.
relates elastic/x-pack-elasticsearch#2656
Original commit: elastic/x-pack-elasticsearch@649a8033e4
This change fixes the check for the version of the security template after the template updater was
changed to only run on the master node in elastic/elasticsearch#27294. Additionally, the wait time
for the cluster to have a yellow status has been increased to account for delayed shards and slower
machines.
Original commit: elastic/x-pack-elasticsearch@a2e72bed12
I imagine this needless indirection arose from accepting the wrong
IntelliJ suggestion for an import.
Original commit: elastic/x-pack-elasticsearch@54d7e854d3
The 5.6 Upgrade API will reindex .security to .security-6 and create a .security alias.
But the 6.0 default was to create a .security-v6 index and a .security alias if none existed (e.g. fresh x-pack install)
Having two different index names based on the method of install/upgrade complicates the code and testing, so we're unifying on the .security-6 index name that already exists in the wild.
Original commit: elastic/x-pack-elasticsearch@d78f569c5f
When simultaneous close requests were made for the same job it was possible
that one of the requests would inappropriately log error messages about the
job having failed. This change prevents that problem, whilst continuing to
adhere to the requirement that close requests for already closing jobs do not
return until the close request that is doing the work completes.
relates elastic/x-pack-elasticsearch#2912
Original commit: elastic/x-pack-elasticsearch@513b7fa1d6
The default internal XPack user no longer has access to the security index, but it should have read-only access to the audit log so that watches can be triggered based on audit events (but cannot write audit records)
Original commit: elastic/x-pack-elasticsearch@5c37720dad
This commit changes the handling of exceptions when retrieving roles from the native roles store.
Previously, exceptions would have caused the request to terminate and the exception would be
sent back to the user. This makes for a bad experience when a cluster hasn't been upgraded to the
latest index format and anonymous access is enabled with a native role as all requests without
preemptive basic authentication would result in an exception. The change here is to allow the
request to continue processing. Once the security index is up to date, the roles cache is cleared
so that the native roles can be picked up.
relates elastic/x-pack-elasticsearch#2686
Original commit: elastic/x-pack-elasticsearch@ef5149140f
Certgen was generating "other name" SANs without the explicit [0] tag that is required.
This was masked by the fact that the JRE X.509 classes always wrap the "other name" name-value in a [0] tag (even if it already has one)
Also switched to a UTF8 String from an IA5 string to match the configuration being used for testing in openssl.
Original commit: elastic/x-pack-elasticsearch@1b87964ec7
This is the X-Pack side of elastic/elasticsearch#27235. To force people
who construct an Environment object in production code to think about the
correct setting of configPath there is no longer a single argument
constructor in the Environment class. Instead there is a factory method
in the test framework to replace it. Having this in the test framework
ensures that there is no way to use it in production code.
Original commit: elastic/x-pack-elasticsearch@4860e92d90
We should not be constructing a temporary Environment object in production
code. This currently isn't causing any problems, but it might in the future
if elastic/elasticsearch#27144 or something similar is ever merged. Instead
the master Environment of the node should always be used.
Original commit: elastic/x-pack-elasticsearch@6276a54a45
This adds the data necessary to add a warning to the alerts UI representing each cluster when xpack.security.transport.tls.enabled is not set to true for a trial licensed cluster running with
xpack.security.enabled.
Original commit: elastic/x-pack-elasticsearch@28fe8bad76
This adds details about the shards and the health of the index. By adding these stats directly to the document, the UI can avoid many aggregations and enable better searching and sorting against indices.
Original commit: elastic/x-pack-elasticsearch@f38ae5ce69
This commit removes the FAILED state for the IndexAuditTrail so that we always try to keep starting
the service. Previously, on any exception during startup we moved to a failed state and never tried
to start again. The users only option was to restart the node. This was problematic in the case of
large clusters as there could be common timeouts of cluster state listeners that would cause the
startup of this service to fail.
Additionally, the logic in the IndexAuditTrail to update the template on the current cluster has
been removed and replaced with the use of the TemplateUpgradeService. However, we still need to
maintain the ability to determine if a template on a remote cluster should be PUT. To avoid always
PUTing the template, the version field has been added so it only needs to be PUT once on upgrade.
Finally, the default queue size has been increased as this is another common issue that users hit
with high traffic clusters.
relates elastic/x-pack-elasticsearch#2658
Original commit: elastic/x-pack-elasticsearch@27e2ce7223
Adding this field enables a very simple mechanism for detecting node changes in the cluster state via Watcher (and other mechanisms). The next step is to add the cluster alert that uses it.
Original commit: elastic/x-pack-elasticsearch@1eacc25cff
This commit adds a new `certutil` command and deprecates the `certgen` command.
The new certuil consists of sub commands that are (by default) are simpler to use than the old monolithic command, but still support all the previous behaviours.
Original commit: elastic/x-pack-elasticsearch@3f57687da9
The execution state of a watch did not differentiate between failures of
the execution like a broken painless script and a thread pool rejection.
This adds an own state, which allows to aggregate on such data in the
watch history, which should ease debugging issues a bit.
Original commit: elastic/x-pack-elasticsearch@351e64e14d
For the purpose of getting this API consumed by our UI, returning
overall buckets that match the job's largest `bucket_span` can
result in too much data. The UI only ever displays a few buckets
in the swimlane. Their span depends on the time range selected and
the screen resolution, but it will only ever be a relatively
low number.
This PR adds the ability to aggregate overall buckets in a user
specified `bucket_span`. That `bucket_span` may be equal or
greater to the largest job's `bucket_span`. The `overall_score`
of the result overall buckets is the max score of the
corresponding overall buckets with a span equal to the job's
largest `bucket_span`.
The implementation is now chunking the bucket requests
as otherwise the aggregation would fail when too many buckets
are matching.
Original commit: elastic/x-pack-elasticsearch@981f7a40e5
If a bulk update references aliases rather than concrete indices,
it is possible that a single shard level request could have multiple distinct "index names", potentially including "date math".
Those names will resolve to the same concrete index, but they might have different privileges.
Original commit: elastic/x-pack-elasticsearch@34cfd11df8