# Backport
This will backport the following commits from `main` to `8.14`:
- [[CI] Display command on failure page
(#186999)](https://github.com/elastic/kibana/pull/186999)
<!--- Backport version: 8.9.8 -->
### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)
<!--BACKPORT [{"author":{"name":"Alex
Szabo","email":"alex.szabo@elastic.co"},"sourceCommit":{"committedDate":"2024-07-02T09:45:46Z","message":"[CI]
Display command on failure page (#186999)\n\n## Summary\r\nThis PR adds
the executed command line to the failures page.\r\nWe tweak the
reporters to export the executed command to the junit xmls,\r\nthen we
read those attributes after parsing the results.\r\n\r\nThe tests needed
some adjustment, because they're very brittle, and\r\ndon't seem to be
very accurate anymore.\r\n\r\n\r\nCloses:
https://github.com/elastic/kibana-operations/issues/127\r\n\r\nCheck out
the `[logs]` for the failed tests
here\r\n(ftr/jest/jest_integration):\r\nhttps://buildkite.com/elastic/kibana-pull-request/builds/218457","sha":"afec9eb0e2699ce24a3fa4d341433cda18372466","branchLabelMapping":{"^v8.15.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Team:Operations","release_note:skip","backport:prev-minor","v8.15.0"],"number":186999,"url":"https://github.com/elastic/kibana/pull/186999","mergeCommit":{"message":"[CI]
Display command on failure page (#186999)\n\n## Summary\r\nThis PR adds
the executed command line to the failures page.\r\nWe tweak the
reporters to export the executed command to the junit xmls,\r\nthen we
read those attributes after parsing the results.\r\n\r\nThe tests needed
some adjustment, because they're very brittle, and\r\ndon't seem to be
very accurate anymore.\r\n\r\n\r\nCloses:
https://github.com/elastic/kibana-operations/issues/127\r\n\r\nCheck out
the `[logs]` for the failed tests
here\r\n(ftr/jest/jest_integration):\r\nhttps://buildkite.com/elastic/kibana-pull-request/builds/218457","sha":"afec9eb0e2699ce24a3fa4d341433cda18372466"}},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"main","label":"v8.15.0","labelRegex":"^v8.15.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/186999","number":186999,"mergeCommit":{"message":"[CI]
Display command on failure page (#186999)\n\n## Summary\r\nThis PR adds
the executed command line to the failures page.\r\nWe tweak the
reporters to export the executed command to the junit xmls,\r\nthen we
read those attributes after parsing the results.\r\n\r\nThe tests needed
some adjustment, because they're very brittle, and\r\ndon't seem to be
very accurate anymore.\r\n\r\n\r\nCloses:
https://github.com/elastic/kibana-operations/issues/127\r\n\r\nCheck out
the `[logs]` for the failed tests
here\r\n(ftr/jest/jest_integration):\r\nhttps://buildkite.com/elastic/kibana-pull-request/builds/218457","sha":"afec9eb0e2699ce24a3fa4d341433cda18372466"}}]}]
BACKPORT-->
## Summary
Part of https://github.com/elastic/kibana/issues/169547
View docs at [Changed
pages](https://kibana_169928.docs-preview.app.elstc.co/diff)
Add monitor api public api
### Testing
Make sure you have some monitors populated before testing this PR and
before switching to the branch
- [ ] Try editing already added monitors via API
- [ ] Test adding monitors via API, and then edit those via and
subsqeuently try editing via API the same monitor
- [ ] Test editing monitors via API
- [ ] Test deleting monitors via API
- [ ] Test getting monitors via API
- [ ] Testing private as well public locations
Basic workflow that i am interesting in testing is to make sure, you can
add/edit via both API and UI without any issues
Test each of HTTP/TCP/ICMP browser examples
<img width="1728" alt="image"
src="3575d93a-5f04-4c80-ac62-038643f466f8">
---------
Co-authored-by: Justin Kambic <jk@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Dominique Clarke <dominique.clarke@elastic.co>
## Summary
Since ms-104 was released, we no longer need to support both deprecated
and new cloud auth route.
How to test: run any FTR test with SAML auth against MKI project
## Summary
When running serverless FTR locally, the data store is the same as for
local development. This data pollution can cause unintended results in
tests. This PR forces FTR to run in a clean data store every time in
`.es/stateless-cluster-ftr/*` and retains development data at
`.es/stateless/*`.
## Summary
This PR refactors `run_performance` script logic that we use to run
single user performance journeys:
- simplify script by keeping only 2 functions: `startES` &
`runFunctionalTest`
- write ES and Kibana logs (for warmup phase) to files instead of
console output;
- upload files with server log as build artifacts
- do not retry journey TEST phase run on failure, it doubles EBT metrics
and does not provide much value: journey should be simple and stable.
- do not retry step running journeys, most of the failures are due to
journey flakiness and we just skip them
Testing performance pipeline
https://buildkite.com/elastic/kibana-single-user-performance/builds/12552
Before:
<img width="1243" alt="image"
src="c4635986-6552-4842-abf9-640f09630674">
After
<img width="1243" alt="Screenshot 2024-02-02 at 13 56 23"
src="47ff6a76-d8dd-44dd-93a5-2c49ef87e808">
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
~This PR still needs work (tests, mainly), so keeping it in draft for
now, but feel free to take it for a spin.~
Implements Bedrock support, specifically for the Claude models.
Architecturally, this introduces LLM adapters: one for OpenAI (which is
what we already have), and one for Bedrock/Claude. The Bedrock/Claude
adapter does the following things:
- parses data from a SerDe (an AWS concept IIUC) stream using
`@smithy/eventstream-serde-node`.
- Converts function requests and results into XML and back (to some
extent)
- some slight changes to existing functionality to achieve _some_ kind
of baseline performance with Bedrock + Claude.
Generally, GPT seems better at implicit tasks. Claude needs explicit
tasks, otherwise it will take things too literally. For instance, I had
to use a function for generating a title because Claude was too eager to
add explanations. For the `classify_esql` function, I had to add extra
instructions to stop it from requesting information that is not there.
It is prone to generating invalid XML.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
in https://github.com/elastic/kibana/pull/174284 we split serverless
roles into individual files per project.
If you run `yarn es serverless --ssl` ES will be provisioned only with
roles specified for elastisearch project type.
To use roles for oblt/security projects, you have to override roles file
with `--resources` flag:
```
yarn es serverless --ssl --resources /Users/dmle/github/kibana/packages/kbn-es/src/serverless_resources/project_roles/security/roles.yml
```
Since it is confusing and not dev-friendly approach, this PR adds new
required flag to `serverless` script: `--projectType`
Usage:
`yarn es serverless --projectType=es --ssl`
`yarn es --serverless=oblt --ssl`
roles.yml file will be picked up based on `projectType` value, you still
have an option to override it using `--resources` flag
How to test:
`yarn es serverless --project-type=oblt --ssl`
`yarn start serverless=oblt --ssl`
You should be able to login with all roles defined or Observability (and
other) project.
Cli docs were updated:
```
[main][~/github/kibana]$ node scripts/es --help
usage: es <command> [<args>]
Assists with running Elasticsearch for Kibana development
Available commands:
snapshot - Downloads and run from a nightly snapshot
source - Build and run from source
archive - Install and run from an Elasticsearch tar
build_snapshots - Build and collect ES snapshots
docker - Run an Elasticsearch Docker image
serverless - Run Serverless Elasticsearch through Docker
To start a serverless instance use the 'serverless' command with
'--projectType' flag or use the '--serverless=<ProjectType>'
shortcut, for example:
es --serverless=es
Global options:
--help
```
---------
Co-authored-by: Robert Oskamp <traeluki@gmail.com>
## Summary
We see quite frequently this kind of error in Jest unit tests:
```
Error: The `document` global was defined when React was initialized, but is not defined anymore. This can happen in a test environment if a component schedules an update from an asynchronous callback, but the test has already finished running. To solve this, you can either unmount the component at the end of your test (and ensure that any asynchronous operations get canceled in `componentWillUnmount`), or you can change the test itself to be asynchronous.
```
As the test execution stops due to this runtime error, and the console
logging is disabled in CI, we don't see a lot of the context of the
error.
This PR adds minimal extra logging when the case of this error happens.
## Summary
in #174284 we split serverless roles into individual files per project.
This PR updates mock-idp-plugin we use to simulate SAML auth in "local"
setup to fetch roles based on `projectType` from the respective yml
file:
- since we read roles from a yml file, new end point `GET
/mock_idp/supported_roles` was added to handle it.
- loginPage & rolesSwitcher hooks are updated to fetch roles via http
- hardcoded roles removed
Few other changes were made:
- move `readRolesFromResource` from `kbn-test` to `kbn-es` for
convenience: it is used to read ES resource files.
- move `system_indices_superuser` to the bottom of the file so it won't
be the first choice in UI role selector (+ we plan to remove the value
in the future)
- Change MOCK_IDP_REALM_NAME to `cloud-saml-kibana` as it is the actual
provider name we use in setup.
<img width="1026" alt="image"
src="060b3c21-9c1a-4210-8b5f-2d574a8f78e7">
<img width="1593" alt="image"
src="4afde9df-5a7e-4ae5-a9f5-ab18b871fc1b">
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR adds the ResizeObserver polyfill in Jest Tests reusing a
polyfill already used in Kibana.
The PR also removes all the mocks for the ResizeObserver used in tests.
The polyfill is no longer needed in code running on a browser as the
[ResizeObserver API is already
available](https://developer.mozilla.org/en-US/docs/Web/API/ResizeObserver#browser_compatibility)
in every Kibana-supported browser.
There is still one last polyfill to remove `@juggle/resize-observer` but
this is used internally by the `use-resize-observer` hook. A following
PR could probably replace that hook with a different hook that doesn't
require that polyfill to cleanup a bit our dependencies
## Summary
This PR started out as an attempt to resolve
https://github.com/elastic/kibana/issues/166559; which it does, the
appropriate colours for the message prompt displayed when an edit
attempt on read only content is made in the code editor for both dark
and light mode are now set;
### Light mode
<img width="412" alt="Screenshot 2023-11-22 at 11 30 17"
src="8675dd9f-b413-4098-a903-7ac63dc367fb">
### Dark mode
<img width="843" alt="Screenshot 2023-11-22 at 11 29 31"
src="64fd39e0-d5dd-4556-b6ca-75ba8fc55c94">
#### Noteworthy**
- See https://code.visualstudio.com/api/references/theme-color for more
clarification on the style definitions added to this PR
- There's also been accommodation made for consumers of the code editor
to provide their own custom message through the prop `readOnlyMessage`.
- That been said it's worth pointing out that this PR updates
react-monaco-editor and monaco-editor packages to their latest version,
primarily because the functionality that provides support to provide
customization for the providing a color scheme that would support in our
use case for setting colors for dark mode and light mode appropriately,
shipped in version 0.40.0 of monaco editor, also for react-monaco-editor
prior to it's current latest the pinned version of monaco editor was
0.38.0.
- Monaco-yaml is also updated in the PR, matching the change in
expectation of the underlying monaco-editor api.
~- Updates to the packages referenced above, in turn caused the
installed version of prettier to be updated to the latest minor version
2.8.8. This change caused some lint changes to the project files where
parentheses were added to types with Index Access on another type
created using the typeof operator (more context
[here](https://github.com/prettier/prettier/issues/14990)), for this
reason I've opted to lockdown prettier version, so that this PR only
contains the changes required for updating the code editor. A subsequent
PR will be created to revert the package lockdown so that PR contains
only the lint changes that will occur.~
### Checklist
<!--
Delete any items that are not applicable to this PR. -->
- [x] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)
<!-- - [ ]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [ ] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios -->
- [x] Any UI touched in this PR is usable by keyboard only (learn more
about [keyboard accessibility](https://webaim.org/techniques/keyboard/))
<!-- - [ ] Any UI touched in this PR does not create any new axe
failures (run axe in browser:
[FF](https://addons.mozilla.org/en-US/firefox/addon/axe-devtools/),
[Chrome](https://chrome.google.com/webstore/detail/axe-web-accessibility-tes/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US))
- [ ] If a plugin configuration key changed, check if it needs to be
allowlisted in the cloud and added to the [docker
list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)
- [ ] This renders correctly on smaller devices using a responsive
layout. (You can test this [in your
browser](https://www.browserstack.com/guide/responsive-testing-on-local-server))
- [ ] This was checked for [cross-browser
compatibility](https://www.elastic.co/support/matrix#matrix_browsers)
### Risk Matrix
Delete this section if it is not applicable to this PR.
Before closing this PR, invite QA, stakeholders, and other developers to
identify risks that should be tested prior to the change/feature
release.
When forming the risk matrix, consider some of the following examples
and how they may potentially impact the change:
| Risk | Probability | Severity | Mitigation/Notes |
|---------------------------|-------------|----------|-------------------------|
| Multiple Spaces—unexpected behavior in non-default Kibana Space.
| Low | High | Integration tests will verify that all features are still
supported in non-default Kibana Space and when user switches between
spaces. |
| Multiple nodes—Elasticsearch polling might have race conditions
when multiple Kibana nodes are polling for the same tasks. | High | Low
| Tasks are idempotent, so executing them multiple times will not result
in logical error, but will degrade performance. To test for this case we
add plenty of unit tests around this logic and document manual testing
procedure. |
| Code should gracefully handle cases when feature X or plugin Y are
disabled. | Medium | High | Unit tests will verify that any feature flag
or plugin combination still results in our service operational. |
| [See more potential risk
examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx) |
### For maintainers
- [ ] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
-->
---------
Co-authored-by: Aleh Zasypkin <aleh.zasypkin@elastic.co>
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
To make local/CI testing env closer to MKI experience this PR updates
serverless roles for each project to be defined in its own yml file.
When FTR tests are run, only project specific roles defined in the file
are provisioned. I use `kbnTestServer.serverArgs` from FTR config to get
projectType from `--serverless=<projectType>` and pass it to `kbn-es`.
If you start ES using `es serverless [<args>]` it will provision roles
defined for 'es' project by default, you need to use `--resources` flag
to override it with roles for other project types.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Recently the cloud api we use for saml auth in our FTR tests was removed
in [cloud#123010](https://github.com/elastic/cloud/pull/123010)
Since this change is still not released to all environments, this PR
adds temporary support for both endpoints.
It also changes the way of getting user full name by making API call to
kibana server
## Summary
@CoenWarmer found that `--watch` on jest tests will cause this sort of
error:
```
TypeError: Cannot assign to read only property 'structuredClone' of object '[object global]'
```
There's some workaround suggested on this thread (although not
necessarily related): https://github.com/zloirock/core-js/issues/1281
In the workaround, we set `structuredClone` to `{}`, this would allow
the currently offending 3rd party to overwrite it where it's currently
getting an error.
## Summary
This PR adds a script that determines GitHub code ownership for
functional test files in the Kibana repository.
### Why do we need this?
We want to be able to determine test ownership to allow teams to get a
better overview of their tests (number of tests, number of skipped
tests, number of failures in the last x days, etc).
### What does this PR bring?
This PR is a first step on closing the test ownership gaps. It adds
functionality to determine the GitHub code owner for a given file (in
the `@kbn/code-owners` package) and adds a script that makes use of this
to check if all functional test files have a code owner, reporting the
gaps.
### Future plans
The idea is to include the test ownership information in our ingested
test results, such that we can create dashboards, reports, etc based on
it.
At some point (once all ownership gaps are closed), we might consider
running this check on CI to prevent new test files without owners.
### How to run?
```
node scripts/check_ftr_code_owners.js
```
The script lists the functional test files that are not covered by code
owners and also gives a summary like this:
```
ERROR Found 2592 test files without code owner (checked 7550 test files in 12.73 s)
```
## Summary
This PR moves SAML session creation from FTR service to `@kbn/test`. It
should simplify its adoption in non-FTR context, e.g. Cypress tests or
jest integration tests:
```
import { SamlSessionManager } from '@kbn/test';
// create instance in your setup file
const sessionManager = new SamlSessionManager({
hostOptions: {
protocol,
hostname,
port,
username,
password,
},
log,
isCloud
});
```
use it in your tests
```
sessionManager.getSessionCookieForRole('viewer');
```
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Aleh Zasypkin <aleh.zasypkin@gmail.com>
[](https://renovatebot.com)
This PR contains the following updates:
| Package | Change | Age | Adoption | Passing | Confidence |
|---|---|---|---|---|---|
| [elastic-apm-node](https://togithub.com/elastic/apm-agent-nodejs) |
[`^4.1.0` ->
`^4.2.0`](https://renovatebot.com/diffs/npm/elastic-apm-node/4.1.0/4.2.0)
|
[](https://docs.renovatebot.com/merge-confidence/)
|
[](https://docs.renovatebot.com/merge-confidence/)
|
[](https://docs.renovatebot.com/merge-confidence/)
|
[](https://docs.renovatebot.com/merge-confidence/)
|
---
### Release Notes
<details>
<summary>elastic/apm-agent-nodejs (elastic-apm-node)</summary>
###
[`v4.2.0`](https://togithub.com/elastic/apm-agent-nodejs/releases/tag/v4.2.0)
[Compare
Source](https://togithub.com/elastic/apm-agent-nodejs/compare/v4.1.0...v4.2.0)
For more information, please see the
[changelog](https://www.elastic.co/guide/en/apm/agent/nodejs/current/release-notes-4.x.html#release-notes-4.2.0).
##### Elastic APM Node.js agent layer ARNs
|Region|ARN|
|------|---|
|af-south-1|arn:aws:lambda:af-south-1:267093732750:layer:elastic-apm-node-ver-4-2-0:1|
|ap-east-1|arn:aws:lambda:ap-east-1:267093732750:layer:elastic-apm-node-ver-4-2-0:1|
|ap-northeast-1|arn:aws:lambda:ap-northeast-1:267093732750:layer:elastic-apm-node-ver-4-2-0:1|
|ap-northeast-2|arn:aws:lambda:ap-northeast-2:267093732750:layer:elastic-apm-node-ver-4-2-0:1|
|ap-northeast-3|arn:aws:lambda:ap-northeast-3:267093732750:layer:elastic-apm-node-ver-4-2-0:1|
|ap-south-1|arn:aws:lambda:ap-south-1:267093732750:layer:elastic-apm-node-ver-4-2-0:1|
|ap-southeast-1|arn:aws:lambda:ap-southeast-1:267093732750:layer:elastic-apm-node-ver-4-2-0:1|
|ap-southeast-2|arn:aws:lambda:ap-southeast-2:267093732750:layer:elastic-apm-node-ver-4-2-0:1|
|ap-southeast-3|arn:aws:lambda:ap-southeast-3:267093732750:layer:elastic-apm-node-ver-4-2-0:1|
|ca-central-1|arn:aws:lambda:ca-central-1:267093732750:layer:elastic-apm-node-ver-4-2-0:1|
|eu-central-1|arn:aws:lambda:eu-central-1:267093732750:layer:elastic-apm-node-ver-4-2-0:1|
|eu-north-1|arn:aws:lambda:eu-north-1:267093732750:layer:elastic-apm-node-ver-4-2-0:1|
|eu-south-1|arn:aws:lambda:eu-south-1:267093732750:layer:elastic-apm-node-ver-4-2-0:1|
|eu-west-1|arn:aws:lambda:eu-west-1:267093732750:layer:elastic-apm-node-ver-4-2-0:1|
|eu-west-2|arn:aws:lambda:eu-west-2:267093732750:layer:elastic-apm-node-ver-4-2-0:1|
|eu-west-3|arn:aws:lambda:eu-west-3:267093732750:layer:elastic-apm-node-ver-4-2-0:1|
|me-south-1|arn:aws:lambda:me-south-1:267093732750:layer:elastic-apm-node-ver-4-2-0:1|
|sa-east-1|arn:aws:lambda:sa-east-1:267093732750:layer:elastic-apm-node-ver-4-2-0:1|
|us-east-1|arn:aws:lambda:us-east-1:267093732750:layer:elastic-apm-node-ver-4-2-0:1|
|us-east-2|arn:aws:lambda:us-east-2:267093732750:layer:elastic-apm-node-ver-4-2-0:1|
|us-west-1|arn:aws:lambda:us-west-1:267093732750:layer:elastic-apm-node-ver-4-2-0:1|
|us-west-2|arn:aws:lambda:us-west-2:267093732750:layer:elastic-apm-node-ver-4-2-0:1|
</details>
---
### Configuration
📅 **Schedule**: Branch creation - At any time (no schedule defined),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR has been generated by [Mend
Renovate](https://www.mend.io/free-developer-tools/renovate/). View
repository job log
[here](https://developer.mend.io/github/elastic/kibana).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy41OS44IiwidXBkYXRlZEluVmVyIjoiMzcuNTkuOCIsInRhcmdldEJyYW5jaCI6Im1haW4ifQ==-->
---------
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: pgayvallet <pierre.gayvallet@elastic.co>
## Summary
This PR disables TLS mode for Kibana run in serverless.
Related to #170417 enabling serverless roles testing
Blocked by #171513
PR is created in cooperation with @azasypkin and intended to simplify
the automated testing process for serverless:
starting Kibana with TLS enabled adds unnecessary complexity to the
process of getting session cookie and overall Kibana APIs calling with
Dev certificate in the tests.
The selected approach is to disable TLS for Kibana and simply rely on
#171513 to configure mocked idp realm for Serverless ES with TLS
enabled.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Goal of this PR is to re-enable the serverless tests that require the
login credentials for users that have the pre-defined roles from
serverless assigned to them.
### `@kbn/test` changes
- Added support for `esServerlessOptions` to FTR config. Currently
allows for `resources` to be defined
- `resources` overrides were introduced [in this
PR](https://github.com/elastic/kibana/pull/167087)
- new FTR option will allow for testing serverless with a set of
users/roles that are specific to the project type
### Security Solution Plugin
- Added `esServerlessOptions` to the Defend Workflows cypress
configurations
- Un-skips all serverless specific tests (now that we have support for
users/roles that are specific to the Security project)
- Changed the default username for cypress `login()` task to be
`endpoint_operations_analyst`
- Note that the previously used `endpoint_operations_analyst` role was
also updated to match the definition used for serverless.
- Added new common `fleet_server_services` cli module with reusable
methods for working with fleet server, including generic
`startFleetServer()` method
- New CLI script: `node
x-pack/plugins/security_solution/scripts/endpoint/start_fleet_server.js`
- Starts a fleet server locally (via Docker) and connects it to the
Kibana
- Supports running fleet server locally for serverless as well
## Summary
This PR wraps up the work the @elastic/kibana-presentation team has done
to finish the MVP of [Phase
1](https://github.com/elastic/kibana/issues/154354) of the `Link`
embeddable, which enables users to add panels to their dashboard that
contain links to other dashboards + external links - with respect to
dashboard links, we give the author control over which pieces of context
should be kept across dashboards so that things like filter pills,
queries, and time ranges are not lost. This marks a huge improvement in
dashboard navigation overall, which was previously only available via a
variety of different workarounds including (but not limited to):
- Creating (essentially) a `noop` dashboard-to-dashboard drilldown
- Using markdown panels with hard Dashboard links, which are prone to
break across updates
- Avoiding navigation all together, which resulted in large,
slow-to-load dashboards.
As an added benefit, because these panels contain **references** to each
dashboard rather than hard links, (1) unlike markdown links, they should
not break after updates and (2) if a links panel is exported and
imported into another space or instance, all of the dashboards it links
to will also be imported.
1a86b713-47e7-4db9-8a04-29d41b13681a
> **Note**
> 🔉 The above video has audio! Turn on your sound for the best
experience.
### Note about this PR
- A majority of this work was done on a feature branch, with thorough
reviews from @andreadelrio on behalf of @elastic/kibana-design along the
way. Therefore, while feedback on the design is encouraged, any large
concerns brought up in this PR should be filed as separate issues and
addressed in follow-up PRs.
- This PR contains work for giving embeddables control over their own
panel size / default positioning on the dashboard. This was especially
important for the links panel, since we assume that (a) most links
panels would be located somewhere near the top of the dashboard and (b)
the horizontal links panel should have a different default "shape"
(longer than it is tall) than the vertical panel (taller than it is
long).
- This PR also contains work for caching dashboard saved objects, which
makes navigation much more seamless.
### Flaky Test Runner
-
https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/3251
### Checklist
- [x] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)
- [ ]
~[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials~ This will
be addressed in a follow up:
https://github.com/elastic/kibana/issues/166750
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios - ~Units tests
are added, functional tests are forthcoming~ Edit: All tests are in.
- [x] Any UI touched in this PR is usable by keyboard only (learn more
about [keyboard accessibility](https://webaim.org/techniques/keyboard/))
- [x] Any UI touched in this PR does not create any new axe failures
(run axe in browser:
[FF](https://addons.mozilla.org/en-US/firefox/addon/axe-devtools/),
[Chrome](https://chrome.google.com/webstore/detail/axe-web-accessibility-tes/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US))
- [x] This renders correctly on smaller devices using a responsive
layout. (You can test this [in your
browser](https://www.browserstack.com/guide/responsive-testing-on-local-server))
- [x] This was checked for [cross-browser
compatibility](https://www.elastic.co/support/matrix#matrix_browsers)
### For maintainers
- [ ] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
---------
Co-authored-by: Nick Peihl <nick.peihl@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Andrea Del Rio <delrio.andre@gmail.com>
Co-authored-by: Devon Thomson <devon.thomson@elastic.co>
Co-authored-by: Nick Peihl <nickpeihl@gmail.com>
Co-authored-by: Gerard Soldevila <gerard.soldevila@elastic.co>
## Summary
Prepares the serverless FTR tests to be runnable with a custom ES image.
(`--esServerlessImage` cli arg)
Creates a pipeline for testing and promoting ES Serverless docker
releases.
The job can be triggered here:
https://buildkite.com/elastic/kibana-elasticsearch-serverless-verify-and-promote
The three main env variables it takes:
- BUILDKITE_BRANCH: the kibana branch to test with (maybe not as
important)
- BUILDKITE_COMMIT: the kibana commit to test with
- ES_SERVERLESS_IMAGE: the elasticsearch serverless image, or tag to use
from this repo:
`docker.elastic.co/elasticsearch-ci/elasticsearch-serverless`
## TODOS:
- [x] set `latest_verified` with full img path as default
- [x] ~~find other CLIs that might need the `esServerlessImage` argument
(if the docker runner has multiple usages)~~ | I confused the `yarn es
docker` with this, because I thought we only run ES serverless in a
docker container, but `elasticsearch` can also be run in docker.
- [x] set `latest-compatible` or similar flag in a manifest in gcs for
Elastic's use-case
- [ ] ensure we can only verify "forward" (ie.: to avoid a
parameterization on old versions to set our pointers back) [on a second
thought, this might be kept as a feature to roll back (if we should ever
need that)]
There are two confusing things I couldn't sort out just yet:
#### Ambiguity in --esServerlessImage
We can either have 2 CLI args: one for an image tag, one for an image
repo/image url, or we can have one (like I have it now) and interpret
that in the code, it can be either the image url, or the tag. It's more
flexible, but it's two things in one. Is it ok this way, or is it too
confusing?
e.g.:
```
node scripts/functional_tests --esFrom serverless --esServerlessImage docker.elastic.co/elasticsearch-ci/elasticsearch-serverless:git-8fc8f941bd4d --bail --config x-pack/test_serverless/functional/test_suites/security/config.ts
# or
node scripts/functional_tests --esFrom serverless --esServerlessImage latest --bail --config x-pack/test_serverless/functional/test_suites/security/config.ts
```
#### Ambiguity in the default image path
The published ES Serverless images will sit on this image path:
`docker.elastic.co/elasticsearch-ci/elasticsearch-serverless`, however,
our one exception is the `latest-verified` which we will be tagging
under a different path, where we have write rights:
`docker.elastic.co/kibana-ci/elasticsearch-serverless:latest-verified`.
Is it okay, that by default, we're searching in the `elasticsearch-ci`
images for any tags as parameters (after all, all the new images will be
published there), however our grand default will ultimately be
`docker.elastic.co/kibana-ci/elasticsearch-serverless:latest-verified`.
## Links
Buildkite:
https://buildkite.com/elastic/kibana-elasticsearch-serverless-verify-and-promote
eg.:
https://buildkite.com/elastic/kibana-elasticsearch-serverless-verify-and-promote/builds/24
Closes: https://github.com/elastic/kibana/issues/162931
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Closes#166543
- It is counterintuitive to `CTRL + C` from the `yarn es serverless`
process and the cluster is still running. This has caused issues when
switching between stateful and serverless work flows for some
developers. This PR inverts the logic to always teardown the cluster
unless a flag is passed.
- Small docs update for changing ES memory allocation on all operation
systems.
- Fixes bug were cluster status would continue looping after `SIGINT`.
- Bind to `SIGINT` earlier so nodes are always killed
## Summary
Upgrade `openpgp` from `5.3.0` to `5.10.1`
Commit log:
https://github.com/openpgpjs/openpgpjs/compare/v5.3.0...v5.10.1
There is an incompatibility of `Uint8Array` when using Jest/JSDom with
the TextEncoder/TextDecoder from node `util`.
`https://github.com/kayahr/text-encoding` has been added as a
`devDependency` so it can be used in the polyfill. It provides a working
TextEncoder/Decoder for our Jest tests.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Closes https://github.com/elastic/kibana/issues/161876
Creates a plugin providing utilities to access metrics data. The plugin
only exposes a server API which includes a client with two methods:
- `getMetricIndices` to retrieve the user-defined indices where metrics
are located
- `updateMetricIndices` to update the indices
The client is now used where we previously relied on infra plugin to
provide the configuration, in APM and Infra.
The plugin persists the configuration in a new saved object
`metrics-data-source`. Because this configuration was previously stored
in the `infrastructure-ui-source`, the plugin relies on a fallback to
reuse any existing value (see additional context
https://github.com/elastic/kibana/issues/161876#issuecomment-1673537400).
### Reviewers
There are no functional changes outside of Infra Monitoring UI and APM
UI, other codeowners are involved because this introduces a new saved
object
- APM - the change introduces a drop-in replacement of the
`infra.getMetricIndices` call. The ui code still relies on infra plugin
for a couple of components so we can't drop the dependency yet, those
we'll need to be moved to a tier 2 plugin (more details in
https://github.com/elastic/observability-dev/discussions/2787
(internal)) in a separate issue
### Testing
You'll need metrics data to verify data fetching works (I've used an
edge-oblt cluster)
1. Navigate to Infrastructure Settings and verify metric indices are
configured with the default value of `infrastructure-ui-source`
2. Update metric indices settings (if connected to oblt cluster add
`remote_cluster:..` indices)
3. Verify `metrics-data-source` saved object is persisted with correct
attributes
4. Verify Infrastructure Inventory is pulling data from the newly
configured indices
5. Go to APM services, verify service Infrastructure pulls data from
newly configured indices
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Jason Rhodes <jason.rhodes@elastic.co>
## Summary
Converting cluster.js to typescript with small logic adjustment. It
should improve readability and simplify maintenance:
keep the following cluster properties solely for stateful
source/snapshot ES instance:
- process
- outcome
- setupPromise
- stdioTarget
Use `serverlessNodes` prop to check if serverless ES was started in
`runServerless/stop/kill`
Remove return statement for `runDocker` & `runDockerContainer` as the
result (e.g. pid) is not used anyways, but assigning to `process` prop
lead to confusion (more in comments)
Adding more tests to increase cluster functionality coverage.
## Summary
Due to most users needing security plugin enabled by default, this
adjusts to that. Which requires transport SSL to be enabled as well. The
`--ssl` flag now will enable HTTP SSL only.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Aleh Zasypkin <aleh.zasypkin@gmail.com>
Closes#162593Closes#163939Closes#162625
The original intention of this PR was to add FTR support for ESS.
However the scope increased as that also required adding SSL support due
to tests failing from disabled `security` and no authentication.
Additionally, after using serverless in `kbn/es` extensively for this,
there was a bit of friction in regards to DX.
## Summary
- Switch `x-pack/test_serverless` FTR to use ES serverless instead of
(stateful) snapshot
- Adds SSL support to Docker and Serverless in `kbn/es`
- Adds `port` option override
- Adds `teardown` option to kill running nodes if the process exits
without shutdown
- Adds `kill` option to kill running nodes on startup if detected
- Adds `--esFrom serverless` to FTR CLI
- Adds `files` option to mount extra files into containers
- For serverless, automatically attach to first node with `docker logs
-f es01` on startup for better DX.
- Added `background` flag to not attach `logs`.
- Adds graceful shutdown for ESS cluster
- Separate `docker pull` from `run` for better logging, ensures latest
image and stops multiple pulls of the same image occurring in parallel
- Align (most) default settings for ES serverless with `gradlew`
[settings](https://github.com/elastic/elasticsearch-serverless/blob/main/serverless-build-tools/src/main/kotlin/elasticsearch.serverless-run.gradle.kts#L8)
- Fixes Docker bind mount permissions in CI
- Fixes issue where `esFrom` would default to `snapshot` and override
FTR config settings.
### Checklist
- [x]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
## Related Issues for Skipped Tests
Security Threat Hunting: #165135
Observability: #165138
Response Ops: #165145
---------
Co-authored-by: Dzmitry Lemechko <dzmitry.lemechko@elastic.co>
Co-authored-by: Tiago Costa <tiago.costa@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Patryk Kopycinski <contact@patrykkopycinski.com>
Implements more specific error handling, in addition to a bug fix w/ the
Lens function where it was not rendering outside of the Observability AI
Assistant plugin's context, and validation of the parameters before
executing the function.
Additionally:
- improves recall function
- filter alerts and services by alert/health status
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## [Security Solution] [Elastic AI Assistant] LangChain integration (experimental)
This PR integrates [LangChain](https://www.langchain.com/) with the [Elastic AI Assistant](https://www.elastic.co/blog/introducing-elastic-ai-assistant) as an experimental, alternative execution path.
### How it works
- There are virtually no client side changes to the assistant, apart from a new branch in `x-pack/packages/kbn-elastic-assistant/impl/assistant/api.tsx` that chooses a path based on the value of the `assistantLangChain` flag:
```typescript
const path = assistantLangChain
? `/internal/elastic_assistant/actions/connector/${apiConfig?.connectorId}/_execute`
: `/api/actions/connector/${apiConfig?.connectorId}/_execute`;
```
Execution of the LangChain chain happens server-side. The new route still executes the request via the `connectorId` in the route, but the connector won't execute the request exactly as it was sent by the client. Instead, the connector will execute one (or more) prompts that are generated by LangChain.
Requests routed to `/internal/elastic_assistant/actions/connector/${apiConfig?.connectorId}/_execute` will be processed by a new Kibana plugin located in:
```
x-pack/plugins/elastic_assistant
```
- Requests are processed in the `postActionsConnectorExecuteRoute` handler in `x-pack/plugins/elastic_assistant/server/routes/post_actions_connector_execute.ts`.
The `postActionsConnectorExecuteRoute` route handler:
1. Extracts the chat messages sent by the assistant
2. Converts the extracted messages to the format expected by LangChain
3. Passes the converted messages to `executeCustomLlmChain`
- The `executeCustomLlmChain` function in `x-pack/plugins/elastic_assistant/server/lib/langchain/execute_custom_llm_chain/index.ts`:
1. Splits the messages into `pastMessages` and `latestMessage`, where the latter contains only the last message sent by the user
2. Wraps the conversation history in the `BufferMemory` LangChain abstraction
3. Executes the chain, kicking it off with `latestMessage`
```typescript
const llm = new ActionsClientLlm({ actions, connectorId, request });
const pastMessages = langchainMessages.slice(0, -1); // all but the last message
const latestMessage = langchainMessages.slice(-1); // the last message
const memory = new BufferMemory({
chatHistory: new ChatMessageHistory(pastMessages),
});
const chain = new ConversationChain({ llm, memory });
await chain.call({ input: latestMessage[0].content }); // kick off the chain with the last message
};
```
- When LangChain executes the chain, it will invoke `ActionsClientLlm`'s `_call` function in `x-pack/plugins/elastic_assistant/server/lib/langchain/llm/actions_client_llm.ts` one or more times.
The `_call` function's signature is defined by LangChain:
```
async _call(prompt: string): Promise<string>
```
- The contents of `prompt` are completely determined by LangChain.
- The string returned by the promise is the "answer" from the LLM
The `ActionsClientLlm` extends LangChain's LLM interface:
```typescript
export class ActionsClientLlm extends LLM
```
This let's us do additional "work" in the `_call` function:
1. Create a new assistant message using the contents of the `prompt` (`string`) argument to `_call`
2. Create a request body in the format expected by the connector
3. Create an actions client from the authenticated request context
4. Execute the actions client with the request body
5. Save the raw response from the connector, because that's what the assistant expects
6. Return the result as a plain string, as per the contact of `_call`
## Desk testing
This experimental LangChain integration may NOT be enabled via a feature flag (yet).
Set
```typescript
assistantLangChain={true}
```
in `x-pack/plugins/security_solution/public/app/app.tsx` to enable this experimental feature in development environments.
## Summary
upgrade `axios` to 1.4
- adjust to header usage, and config optionality
- Axios' adapters are now resolved from a string key by axios, no need
to import/instantiate adapters
- most of the changed code stems from changes in Axios' types
- `response.config` is now optional
- there was a change in the type of AxiosHeaders <->
InternalAxiosHeaders
Closes: #162661Closes: #162414
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Risk engine initialisation, update from legacy risk engine workflow
and status change
dfb75d4a-f447-4346-9760-d0e9685cce39
Green areas it is what was implemented
<img width="1449" alt="Screenshot 2023-08-01 at 15 07 01"
src="4d87887f-1163-45eb-a4e9-a77a685f6565">
This pr has:
- Upgrade workflow. If the user has a risk host or user transforms, we
will show the panel with a call to action for the upgrade.
- Introduce new Saved object to save the configuration of risk engine
- API which is described bellow
It required experiment enabled - **riskScoringRoutesEnabled**
## New API
### /engine/status
#### GET
Get the status of the Risk Engine
##### Description:
Returns the status of both the legacy transform-based risk engine, as
well as the new risk engine
##### Responses
```json
{
"legacy_risk_engine_status": "NOT_INSTALLED" , "ENABLED"
,
"risk_engine_status": "NOT_INSTALLED" , "ENABLED" , "DISABLED"
}
```
### /engine/init
#### POST
Initialize the Risk Engine
##### Description:
Initializes the Risk Engine by creating the necessary indices and
mappings, removing old transforms, creating saved object configuration
##### Responses
```json
{
"result": {
"risk_engine_enabled": true,
"risk_engine_resources_installed": true,
"risk_engine_configuration_created": true,
"legacy_risk_engine_disabled": true,
"errors": [
"string"
]
}
}
```
### /engine/enable
#### POST
Enable the Risk Engine
##### Description:
Change saved object configuration and in the future here we will start
task
### /engine/disable
#### POST
Disable the Risk Engine
Change saved object configuration and in the future here we will stop
task
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Ryland Herrick <ryalnd@gmail.com>
## Summary
Since we already have some E2E tests running for serverless, this PR
turns on the internal API restriction flag to test whether our UI
functions _as such_ under these tests.
An alternative could be to have a specific smoke test for this, but it
seems this is thoroughly covered by piggy-backing off the existing set
of tests.
Blocks: https://github.com/elastic/kibana/pull/162149
> Pre-req for https://github.com/elastic/kibana/issues/56406
## Summary
We've had a long-standing problem in Kibana around our use of React
context, particularly with EUI and i18n. There hasn't existed an
idempotent context structure, and that has lead to a lot of unexpected
results, (e.g. missing translations, inconsistent dark mode, excess
context providers, etc).
The biggest change coming from this PR is knowing exactly which provider
to use in a particular use case. This means, for example,
`ReactDOM.render` calls won't be missing `i18n` or `theme` due to a
missing context. It also allows consumers to use `darkMode` without
having to read the `uiSetting` themselves, instead allowing the context
to do it for them.
We also haven't been honoring the intended [`EuiProvider`
API](https://eui.elastic.co/#/utilities/provider#theming-and-global-styles)...
in some cases we've been creating and re-creating the Emotion caches,
often by copy/paste of the cache code. We've also been nesting
`EuiThemeProvider` contexts unnecessarily-- thinking we need to render a
theme provider in an isolated component-- which renders an additional
`span` element into the DOM.
This PR attempts to address this inconsistency by creating a set of
context providers divided by use case:
### `KibanaRootContextProvider`
A root context provider for Kibana. This is the top level context
provider that wraps the entire application. It is responsible for
initializing all of the other contexts and providing them to the
application. It's provided as a package for specific use cases, (e.g.
the `RenderingService`, cases where we replace the entire page content,
Storybook, testing, etc), but not intended for plugins.
### `KibanaRenderContextProvider`
A render context provider for Kibana. This context is designed to be
used with ad-hoc renders of React components, (usually with
`ReactDOM.render`).
### `KibanaThemeContextProvider`
A theme context provider for Kibana. A corollary to EUI's
`EuiThemeProvider`, it uses Kibana services to ensure the EUI Theme is
customized correctly.
### (deprecated) `KibanaStyledComponentsThemeProvider`
A styled components theme provider for Kibana. This package is supplied
for compatibility with legacy code, but should not be used in new code.
## Deprecation strategy
This PR does *not* change any use of context by consumers. It maps the
existing contexts in `kibanaReact` to the new contexts, (along with the
loose API). This means that we won't have completely fixed all of our
dark mode issues yet. But this is necessary to keep this PR focused on
the change, rather than drawing in a lot of teams to review individual
uses.
We should, however, see an immediate performance improvement in the UI
from the reduction in `EuiProvider` calls.
## Open questions
- [ ] Does it make sense to expose a `useTheme` hook from
`@kbn/react-kibana-context-theme` to replace `useEuiTheme`?
## Next steps
- [ ] Update deprecated uses to new contexts.
- [ ] Audit and update calls to `ReactDOM.render`.
- [ ] Add ESLint rule to warn for use of EUI contexts.
- [ ] Delete code from `kibanaReact`.
This PR adds the `Blob` polyfill into the jest jsdom env which is
currently not supported as mentioned in
https://github.com/jsdom/jsdom/issues/2555
---------
Co-authored-by: Thomas Watson <w@tson.dk>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Partially addresses https://github.com/elastic/kibana/issues/159590
## Summary
This PR adds an an internal uiSettings API that is a duplicate of the
public API and is intended for use by the browser-side uiSettings
client.
The PR also adds a config settings that is configured in serverless
context only and exposes the public uiSettings routes based on the value
of this setting (it defaults to false since we don't want to expose the
public routes in serverless).
**How to test:**
I. Verify that in serverless the internal routes are exposed but the
public ones aren't:
1. Start Es with `yarn es snapshot` and Kibana with `yarn
serverless-{mode}` where `{mode}` can be `es`, `oblt`, or `security`
(the public routes should be disabled for all projects).
2. Verify that the public endpoints are not accessible. For example,
`curl --user elastic:changeme
'http://localhost:5601/zhb/api/kibana/settings' -X 'GET'` should return
`{"statusCode":404,"error":"Not Found","message":"Not Found"}`.
3. Verify that the internal endpoints are accessible. For example, `curl
--user elastic:changeme
'http://localhost:5601/zhb/internal/kibana/settings' -X 'GET'` should
return
`{"settings":{"buildNum":{"userValue":9007199254740991},"isDefaultIndexMigrated":{"userValue":true},"defaultRoute":{"isOverridden":true,"userValue":"/app/elasticsearch"}}}`
II. Verify that the both public and internal routes are exposed in
self-managed:
1. Start Es with `yarn es snapshot` and Kibana with `yarn start`
2. Verify that the public endpoints are accessible. For example, `curl
--user elastic:changeme 'http://localhost:5601/zhb/api/kibana/settings'
-X 'GET'` should return
`{"settings":{"buildNum":{"userValue":9007199254740991},"isDefaultIndexMigrated":{"userValue":true}}}`
3. Verify that the internal endpoints are accessible. For example, `curl
--user elastic:changeme
'http://localhost:5601/zhb/internal/kibana/settings' -X 'GET'` should
return
`{"settings":{"buildNum":{"userValue":9007199254740991},"isDefaultIndexMigrated":{"userValue":true}}}`
III. Verify that the plugins/services that consume the internal
uiSettings endpoints work as expected in both self-managed and
serverless environment.
### For maintainers
- [ ] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Running FTR tests locally (not on CI) that make API requests to public
versioned Kibana endpoints is currently broken. This is because:
* we require version headers to be set for both internal and **public**
endpoints in **dev** by way of a runtime check (ensures our code is
locked to a version)
* the vast majority of FTR tests do not set these headers for talking to
public endpoints
* on CI, this is different as we run these tests against a distributable
build (i.e., non-dev)
This manifests locally as a 400 response. E.g. the current
api_integration tests for data views by running:
```
node scripts/functional_test_runner.js --config ./test/api_integration/config.js --grep 'index_pattern_crud'
```
---
There are a few ways to resolve this, this PR proposes that we:
* Keep FTR tests as they are (i.e., don't update all of them to set
headers when making requests to public versioned endpoints), this is a
useful way to exercise our intended end-user behaviour
* Make the version resolution behaviour not depend on `--dev`: rather
set the default resolution to `none` (new setting) when we run in
`--dev` so that it can be configured to behave as we want for tests.
In this way we keep the runtime check for its intended purpose and can
run our FTR tests "as end users" of our endpoints.
---
Close https://github.com/elastic/kibana/issues/161435
## Summary
This PR fixes few issues occurring while running FTR API tests against
actual serverless project.
How to run:
```
TEST_CLOUD=1 ES_SECURITY_ENABLED=1 NODE_TLS_REJECT_UNAUTHORIZED=0 TEST_ES_URL=<your_es_url_with_credentials> TEST_KIBANA_URL=<your_es_url_with_credentials> node --no-warnings scripts/functional_test_runner --es-version=8.9.0 --config x-pack/test_serverless/api_integration/test_suites/search/config.ts --bail
```
The first error is faced during Elasticsearch version validation
```
ERROR Error: attempted to use the "es" service to fetch Elasticsearch version info but the request failed: ResponseError: {"ok":false,"message":"Unknown resource."}
at SniffingTransport.request (/Users/dmle/github/kibana/node_modules/@elastic/transport/src/Transport.ts:535:17)
at processTicksAndRejections (node:internal/process/task_queues:96:5)
at Client.InfoApi [as info] (/Users/dmle/github/kibana/node_modules/@elastic/elasticsearch/src/api/api/info.ts:60:10)
at FunctionalTestRunner.validateEsVersion (functional_test_runner.ts:129:16)
at functional_test_runner.ts:64:11
at FunctionalTestRunner.runHarness (functional_test_runner.ts:251:14)
at FunctionalTestRunner.run (functional_test_runner.ts:48:12)
at log.defaultLevel (cli.ts:112:32)
at run.ts:70:7
at withProcRunner (with_proc_runner.ts:29:5)
at run (run.ts:69:5)
at FunctionalTestRunner.validateEsVersion (functional_test_runner.ts:131:13)
at processTicksAndRejections (node:internal/process/task_queues:96:5)
at functional_test_runner.ts:64:11
at FunctionalTestRunner.runHarness (functional_test_runner.ts:251:14)
at FunctionalTestRunner.run (functional_test_runner.ts:48:12)
at log.defaultLevel (cli.ts:112:32)
at run.ts:70:7
at withProcRunner (with_proc_runner.ts:29:5)
at run (run.ts:69:5)
```
Since there is no version term in case of serverless, we can skip
version check by using newly added to FTR schema `serverless` property
(`false` by default). It is set to `true` in root FTR config
`/shared/config.base`.
The next error is related to ESArchiver relying on `ES` FTR service to
provide ESClient.
```
ResponseError: security_exception
│ Root causes:
│ security_exception: unable to authenticate user [system_indices_superuser] for REST request [/kibana_sample_data_flights]
```
It is fixed by using the default user (from host url) instead of
`system_indices_superuser` we use in stateful run.
