## Summary
Allows one to export and import content packs in archive format. The
format follows the integration content package's format so it becomes
possible to import existing integration packages.
Content packs only support dashboard assets at the moment.
A pattern replacement logic has been implemented for dashboards and
referenced data views:
- at export time, any pattern matching the source stream will be
replaced with a placeholder. Other patterns will remain as-is unless
user explicitly ask to replace them
- at import time, the placeholders are replaced with the target stream
pattern
For example, if a dashboard is first exported from stream `logs.nodejs`
and reads data from patterns `logs.nodejs` and `logs.nodejs.prod`, the
patterns will be updated to `logs.ruby` and `logs.ruby.prod` when
imported into `logs.ruby` stream.
The relevant UI components are hidden behind a feature flag, set the
following in `kibana.dev.yml` to enable them:
`feature_flags.overrides.featureFlagsStreams.contentPackUIEnabled: true`
https://github.com/user-attachments/assets/9fb07daf-9fb9-4c62-9f5b-387e1833eaf0
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: tommyers-elastic <106530686+tommyers-elastic@users.noreply.github.com>
## Summary
~**DO NOT MERGE:** depends on
https://github.com/elastic/kibana/issues/213468~
This PR reintegrates the work from the `workchat_m1` branch into `main`:
- introduces a 4th solution type, `chat`, that will be used for the
*WorkChat* project type.
- edit things in various platform code to introduce/handle that new
project type
- add plugins and packages for the workchat app.
### To AppEx reviewers:
File change count is scary, but you can safely ignore anything from
`xpack/solutions/chat` (given it's solution code), and focus on your
owned changes, which are way more reasonable
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Joe McElroy <joseph.mcelroy@elastic.co>
Co-authored-by: Rodney Norris <rodney.norris@elastic.co>
Co-authored-by: Jedr Blaszyk <jedrazb@gmail.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Meghan Murphy <meghan.murphy@elastic.co>
## Summary
After https://github.com/elastic/kibana/pull/214843, `axios` client
usages need to set a flag to prevent the vulnerable behavior.
To reviewers: if you think it's a mistake, and you created a client to
request for absolute URLs, consider unsetting the `baseURL` to
communicate intent.
## Summary
Add a new telemetry task to the security solution plugin to collect
ingest pipeline stats. The new task runs once a day, calls the
`_nodes/stats/ingest` API, and sends an EBT event with the following
information:
```js
export interface NodeIngestPipelinesStats {
name: string;
totals: Totals;
pipelines: Pipeline[];
}
export interface Pipeline {
name: string;
totals: Totals;
processors: Processor[];
}
export interface Processor {
name: string;
totals: Totals;
}
export interface Totals {
count: number;
time_in_millis: number;
current: number;
failed: number;
}
```
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [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
- [x] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Ryland Herrick <ryalnd@gmail.com>
## Summary
This PR optimizes the FTR service initialization by not loading UI
service for API tests and by removing retries during test user setup
## Changes
- Remove loading of common UI services from common services (UI services
should not be loaded for API tests)
- Move `security` service from `@kbn/ftr-common-functional-ui-services`
to `@kbn/ftr-common-functional-services` as it should be available to
API tests as well
- Only try once to delete `testUser` during init (this user usually does
not exist on a fresh deployment - and if it does, a single delete
request is enough to get rid of it)
## Benchmark results
**These changes will reduce FTR CI runtime overall by ~100 minutes**
🚀
Due to parallel workers in CI, the effective runtime of the whole CI job
will be less than that.
- The removal of UI service loading (which includes starting a browser
instance) for API tests reduces init time by ~0.5 seconds. With 313 API
configs that are started on CI, this reduces the runtime overall by ~156
seconds / ~2.6 minutes.
- The removal of test user delete retries reduces init time by ~10
seconds. With 589 FTR configs that are started on CI, this reduces the
runtime overall by ~5890 seconds / ~98 minutes.
- These numbers have been taken on a local machine and since CI workers
are usually slower, we should see at least this amount of improvement if
not more in CI.
## Summary
Updating the ES client to 9.0.
Resolves#116102
## What changes?
**Breaking change**: `body` has been removed.
Most of the changes are about bringing all the content inside the body
as a root attribute to the API params:
```diff
const response = await client.search({
index: 'test',
- body: {
query: {
match_all: {}
}
- }
})
```
For this reason, enabling the "Hide whitespace changes" option when
reviewing is recommended.
Some exceptions to this rule:
* Bulk APIs replace the `body` array with `operations` array (direct
replacement)
* Index Put Settings API replace `body` array with `settings` (direct
replacement)
* Msearch replaces the `body` array with `searches` array (direct
replacement)
* Document Index API replaces `body` with `document` (direct
replacement)
* Create Repository replaces `body` with `repository` (direct
replacement)
Because of a known issue in the client
(https://github.com/elastic/elasticsearch-js/issues/2584), there's still
an escape hatch to send data in the body in case the specific use case
requires it via `// @ts-expect-error elasticsearch@9.0.0
https://github.com/elastic/elasticsearch-js/issues/2584`, but it
shouldn't be abused because we lose types. In this PR we've used it in
those scenarios where we reuse the response of a GET as the body of a
PUT/POST.
### Other changes
* `estypes` can be imported from the root of the library as `import type
{ estypes } from '@elastic/elasticsearch';`
* `estypesWithBody` have been removed
* `requestTimeout`'s 30s default has been removed in the client. This PR
explicitly adds the setting in all client usages.
### Identify risks
- [x] The client places unknown properties as querystring, risking body
params leaking there, and causing 400 errors from ES => Solved by
forcing `body` usage there via `// @ts-expect-error elasticsearch@9.0.0
https://github.com/elastic/elasticsearch-js/issues/2584`. The next
version of the client will address this.
- [x] We need to run the MKI tests to make sure that we're not breaking
anything there =>
https://elastic.slack.com/archives/C04HT4P1YS3/p1739528112482629?thread_ts=1739480136.231439&cid=C04HT4P1YS3
---------
Co-authored-by: Gloria Hornero <gloria.hornero@elastic.co>
## Summary
The `/packages` folder at the root of the Kibana repository used to
contain a lot of packages.
In the context of SKA, they have been gradually moved to various
locations:
* `src/platform/packages`
* `x-pack/platform/packages`
* `src/core/packages`
Currently, only `devOnly: true` packages are left in this folder. This
comprises libraries for CLI scripts as well as testing utilities.
With this PR, we are moving ~half of these packages under
`src/platform/packages/(private|shared)/`.
In particular, we are moving those packages that are being used from
platform and/or solutions.
Since they are `"devOnly": true`, this means they are ONLY used from
tests, cypress tests, storybook configs, ./scripts/ folders inside some
modules, or other non-prod-time logic. Nonetheless, they are effectively
referenced from platform and/or solutions code, hence I decided they
should be placed under `platform` folders.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Should fix TS check error `Project references may not form a circular
graph` by removing `@kbn/test-suites-xpack` from `kbn-scout` dependency
list.
Since dockerImage for Fleet package registry is just a constant, that is
used across different FTR and Scout configurations, it makes sense to
export it from `kbn-test`
Links dashboard to Streams.
Changes:
- Introduces `IndexStorageAdapter` to manage ES indices - see
https://github.com/dgieselaar/kibana/blob/streams-app-asset-linking/x-pack/solutions/observability/packages/utils_server/es/storage/README.md
for motivation
- Introduces `AssetClient` and `AssetService` to manage asset links with
`IndexStorageAdapter`
- `RepositorySupertestClient` to make it easier to use
`@kbn/server-route-repository` with FTR tests
- refactors related to above changes
---------
Co-authored-by: Chris Cowan <chris@elastic.co>
Co-authored-by: Joe Reuter <johannes.reuter@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Implements a security_solution task scheduled to run once a day to
collect the following information:
1. Datastreams stats
2. Indices stats
3. ILMs stats
4. ILM configs
The task allows a runtime configuration to limit the number of indices
and data streams to analyze or event to disable the feature entirely.
Once the data is gathered, the task sends it as EBT events.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
This PR aims to decouple the feature IDs from the `consumer` attribute
of rules and alerts.
Towards: https://github.com/elastic/kibana/issues/187202
Fixes: https://github.com/elastic/kibana/issues/181559
Fixes: https://github.com/elastic/kibana/issues/182435
> [!NOTE]
> Unfortunately, I could not break the PR into smaller pieces. The APIs
could not work anymore with feature IDs and had to convert them to use
rule type IDs. Also, I took the chance and refactored crucial parts of
the authorization class that in turn affected a lot of files. Most of
the changes in the files are minimal and easy to review. The crucial
changes are in the authorization class and some alerting APIs.
## Architecture
### Alerting RBAC model
The Kibana security uses Elasticsearch's [application
privileges](https://www.elastic.co/guide/en/elasticsearch/reference/current/security-api-put-privileges.html#security-api-put-privileges).
This way Kibana can represent and store its privilege models within
Elasticsearch roles. To do that, Kibana security creates actions that
are granted by a specific privilege. Alerting uses its own RBAC model
and is built on top of the existing Kibana security model. The Alerting
RBAC uses the `rule_type_id` and `consumer` attributes to define who
owns the rule and the alerts procured by the rule. To connect the
`rule_type_id` and `consumer` with the Kibana security actions the
Alerting RBAC registers its custom actions. They are constructed as
`alerting:<rule-type-id>/<feature-id>/<alerting-entity>/<operation>`.
Because to authorizate a resource an action has to be generated and
because the action needs a valid feature ID the value of the `consumer`
should be a valid feature ID. For example, the
`alerting:siem.esqlRule/siem/rule/get` action, means that a user with a
role that grants this action can get a rule of type `siem.esqlRule` with
consumer `siem`.
### Problem statement
At the moment the `consumer` attribute should be a valid feature ID.
Though this approach worked well so far it has its limitation.
Specifically:
- Rule types cannot support more than one consumer.
- To associate old rules with a new feature ID required a migration on
the rule's SOs and the alerts documents.
- The API calls are feature ID-oriented and not rule-type-oriented.
- The framework has to be aware of the values of the `consumer`
attribute.
- Feature IDs are tightly coupled with the alerting indices leading to
[bugs](https://github.com/elastic/kibana/issues/179082).
- Legacy consumers that are not a valid feature anymore can cause
[bugs](https://github.com/elastic/kibana/issues/184595).
- The framework has to be aware of legacy consumers to handle edge
cases.
- The framework has to be aware of specific consumers to handle edge
cases.
### Proposed solution
This PR aims to decouple the feature IDs from consumers. It achieves
that a) by changing the way solutions configure the alerting privileges
when registering a feature and b) by changing the alerting actions. The
schema changes as:
```
// Old formatting
id: 'siem', <--- feature ID
alerting:['siem.queryRule']
// New formatting
id: 'siem', <--- feature ID
alerting: [{ ruleTypeId: 'siem.queryRule', consumers: ['siem'] }] <-- consumer same as the feature ID in the old formatting
```
The new actions are constructed as
`alerting:<rule-type-id>/<consumer>/<alerting-entity>/<operation>`. For
example `alerting:rule-type-id/my-consumer/rule/get`. The new action
means that a user with a role that grants this action can get a rule of
type `rule-type` with consumer `my-consumer`. Changing the action
strings is not considered a breaking change as long as the user's
permission works as before. In our case, this is true because the
consumer will be the same as before (feature ID), and the alerting
security actions will be the same. For example:
**Old formatting**
Schema:
```
id: 'logs', <--- feature ID
alerting:['.es-query'] <-- rule type ID
```
Generated action:
```
alerting:.es-query/logs/rule/get
```
**New formatting**
Schema:
```
id: 'siem', <--- feature ID
alerting: [{ ruleTypeId: '.es-query', consumers: ['logs'] }] <-- consumer same as the feature ID in the old formatting
```
Generated action:
```
alerting:.es-query/logs/rule/get <--- consumer is set as logs and the action is the same as before
```
In both formating the actions are the same thus breaking changes are
avoided.
### Alerting authorization class
The alerting plugin uses and exports the alerting authorization class
(`AlertingAuthorization`). The class is responsible for handling all
authorization actions related to rules and alerts. The class changed to
handle the new actions as described in the above sections. A lot of
methods were renamed, removed, and cleaned up, all method arguments
converted to be an object, and the response signature of some methods
changed. These changes affected various pieces of the code. The changes
in this class are the most important in this PR especially the
`_getAuthorizedRuleTypesWithAuthorizedConsumers` method which is the
cornerstone of the alerting RBAC. Please review carefully.
### Instantiation of the alerting authorization class
The `AlertingAuthorizationClientFactory` is used to create instances of
the `AlertingAuthorization` class. The `AlertingAuthorization` class
needs to perform async operations upon instantiation. Because JS, at the
moment, does not support async instantiation of classes the
`AlertingAuthorization` class was assigning `Promise` objects to
variables that could be resolved later in other phases of the lifecycle
of the class. To improve readability and make the lifecycle of the class
clearer, I separated the construction of the class (initialization) from
the bootstrap process. As a result, getting the `AlertingAuthorization`
class or any client that depends on it (`getRulesClient` for example) is
an async operation.
### Filtering
A lot of routes use the authorization class to get the authorization
filter (`getFindAuthorizationFilter`), a filter that, if applied,
returns only the rule types and consumers the user is authorized to. The
method that returns the filter was built in a way to also support
filtering on top of the authorization filter thus coupling the
authorized filter with router filtering. I believe these two operations
should be decoupled and the filter method should return a filter that
gives you all the authorized rule types. It is the responsibility of the
consumer, router in our case, to apply extra filters on top of the
authorization filter. For that reason, I made all the necessary changes
to decouple them.
### Legacy consumers & producer
A lot of rules and alerts have been created and are still being created
from observability with the `alerts` consumer. When the Alerting RBAC
encounters a rule or alert with `alerts` as a consumer it falls back to
the `producer` of the rule type ID to construct the actions. For example
if a rule with `ruleTypeId: .es-query` and `consumer: alerts` the
alerting action will be constructed as
`alerting:.es-query/stackAlerts/rule/get` where `stackRules` is the
producer of the `.es-query` rule type. The `producer` is used to be used
in alerting authorization but due to its complexity, it was deprecated
and only used as a fallback for the `alerts` consumer. To avoid breaking
changes all feature privileges that specify access to rule types add the
`alerts` consumer when configuring their alerting privileges. By moving
the `alerts` consumer to the registration of the feature we can stop
relying on the `producer`. The `producer` is not used anymore in the
authorization class. In the next PRs the `producer` will removed
entirely.
### Routes
The following changes were introduced to the alerting routes:
- All related routes changed to be rule-type oriented and not feature ID
oriented.
- All related routes support the `ruleTypeIds` and the `consumers`
parameters for filtering. In all routes, the filters are constructed as
`ruleTypeIds: ['foo'] AND consumers: ['bar'] AND authorizationFilter`.
Filtering by consumers is important. In o11y for example, we do not want
to show ES rule types with the `stackAlerts` consumer even if the user
has access to them.
- The `/internal/rac/alerts/_feature_ids` route got deleted as it was
not used anywhere in the codebase and it was internal.
All the changes in the routes are related to internal routes and no
breaking changes are introduced.
### Constants
I moved the o11y and stack rule type IDs to `kbn-rule-data-utils` and
exported all security solution rule type IDs from
`kbn-securitysolution-rules`. I am not a fan of having a centralized
place for the rule type IDs. Ideally, consumers of the framework should
specify keywords like `observablility` (category or subcategory) or even
`apm.*` and the framework should know which rule type IDs to pick up. I
think it is out of the scope of the PR, and at the moment it seems the
most straightforward way to move forward. I will try to clean up as much
as possible in further iterations. If you are interested in the upcoming
work follow this issue https://github.com/elastic/kibana/issues/187202.
### Other notable code changes
- Change all instances of feature IDs to rule type IDs.
- `isSiemRuleType`: This is a temporary helper function that is needed
in places where we handle edge cases related to security solution rule
types. Ideally, the framework should be agnostic to the rule types or
consumers. The plan is to be removed entirely in further iterations.
- Rename alerting `PluginSetupContract` and `PluginStartContract` to
`AlertingServerSetup` and `AlertingServerStart`. This made me touch a
lot of files but I could not resist.
- `filter_consumers` was mistakenly exposed to a public API. It was
undocumented.
- Files or functions that were not used anywhere in the codebase got
deleted.
- Change the returned type of the `list` method of the
`RuleTypeRegistry` from `Set<RegistryRuleType>` to `Map<string,
RegistryRuleType>`.
- Assertion of `KueryNode` in tests changed to an assertion of KQL using
`toKqlExpression`.
- Removal of `useRuleAADFields` as it is not used anywhere.
## Testing
> [!CAUTION]
> It is very important to test all the areas of the application where
rules or alerts are being used directly or indirectly. Scenarios to
consider:
> - The correct rules, alerts, and aggregations on top of them are being
shown as expected as a superuser.
> - The correct rules, alerts, and aggregations on top of them are being
shown as expected by a user with limited access to certain features.
> - The changes in this PR are backward compatible with the previous
users' permissions.
### Solutions
Please test and verify that:
- All the rule types you own with all possible combinations of
permissions both in ESS and in Serverless.
- The consumers and rule types make sense when registering the features.
- The consumers and rule types that are passed to the components are the
intended ones.
### ResponseOps
The most important changes are in the alerting authorization class, the
search strategy, and the routes. Please test:
- The rules we own with all possible combinations of permissions.
- The stack alerts page and its solution filtering.
- The categories filtering in the maintenance window UI.
## Risks
> [!WARNING]
> The risks involved in this PR are related to privileges. Specifically:
> - Users with no privileges can access rules and alerts they do not
have access to.
> - Users with privileges cannot access rules and alerts they have
access to.
>
> An excessive list of integration tests is in place to ensure that the
above scenarios will not occur. In the case of a bug, we could a)
release an energy release for serverless and b) backport the fix in ESS.
Given that this PR is intended to be merged in 8.17 we have plenty of
time to test and to minimize the chances of risks.
## FQA
- I noticed that a lot of routes support the `filter` parameter where we
can pass an arbitrary KQL filter. Why we do not use this to filter by
the rule type IDs and the consumers and instead we introduce new
dedicated parameters?
The `filter` parameter should not be exposed in the first place. It
assumes that the consumer of the API knows the underlying structure and
implementation details of the persisted storage API (SavedObject client
API). For example, a valid filter would be
`alerting.attributes.rule_type_id`. In this filter the consumer should
know a) the name of the SO b) the keyword `attributes` (storage
implementation detail) and c) the name of the attribute as it is
persisted in ES (snake case instead of camel case as it is returned by
the APIs). As there is no abstraction layer between the SO and the API,
it makes it very difficult to make changes in the persistent schema or
the APIs. For all the above I decided to introduce new query parameters
where the alerting framework has total control over it.
- I noticed in the code a lot of instances where the consumer is used.
Should not remove any logic around consumers?
This PR is a step forward making the framework as agnostic as possible.
I had to keep the scope of the PR as contained as possible. We will get
there. It needs time :).
- I noticed a lot of hacks like checking if the rule type is `siem`.
Should not remove the hacks?
This PR is a step forward making the framework as agnostic as possible.
I had to keep the scope of the PR as contained as possible. We will get
there. It needs time :).
- I hate the "Role visibility" dropdown. Can we remove it?
I also do not like it. The goal is to remove it. Follow
https://github.com/elastic/kibana/issues/189997.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Aleh Zasypkin <aleh.zasypkin@elastic.co>
Co-authored-by: Paula Borgonovi <159723434+pborgonovi@users.noreply.github.com>
closes [#198015](https://github.com/elastic/kibana/issues/198015)
## Summary
Migrate most of the infra APIs integration tests to the
deployment-agnostic approach.
>[!important]
> - Metrics UI related tests were note migrated because the feature is
not enabled on serverless.
> - `Host with active alerts` test was not migrated because
`es_archiver` fails to load the alerts data. This is because on
serverless, the alerts indices are created as managed data streams and
that causes the `es_archiver` to fail. We should probably try use
synthtrace.
- [x] Tested against MKI
- [x] Tested against stateful
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Closes#192153
## Summary
This PR sets the spaces and roles CRUD operation HTTP API endpoints to
public in both stateful and serverless offerings, and additionally,
switches to the versioned router to register these endpoints.
Prior to this PR, the access level was not explicitly set, thus any
endpoints registered in serverless were by default internal. CRUD
operations for spaces and roles are being set to public to support the
rollout of custom roles in serverless, which coincides with enabling
multiple spaces.
### Note
- Currently, roles APIs are only available in serverless via a feature
flag (`xpack.security.roleManagementEnabled`)
- Spaces APIs are already registered in serverless, however, the maximum
number of spaces is by default 1, rendering create and delete operations
unusable. By overriding `xpack.spaces.maxSpaces` to a number greater
than 1 (stateful default is 1000), it will effectively enable use of the
spaces CRUD operations in serverless.
## Tests
-
x-pack/test_serverless/api_integration/test_suites/common/management/multiple_spaces_enabled.ts
-
x-pack/test_serverless/api_integration/test_suites/common/management/spaces.ts
-
x-pack/test_serverless/api_integration/test_suites/common/platform_security/authorization.ts
-
x-pack/test_serverless/api_integration/test_suites/common/platform_security/roles_routes_feature_flag.ts
- Unit tests for each endpoint (to account for versioned router)
- Flaky Test Runner:
https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/7002
## Manual Testing
1. Start ES & Kibana in serverless mode with config options to enable
role management and multiple spaces
Elasticsearch:
```
xpack.security.authc.native_roles.enabled: true
```
KIbana:
```
xpack.security.roleManagementEnabled: true
xpack.spaces.maxSpaces: 100
```
3. Issue each CRUD HTTP API without including the internal origin header
('x-elastic-internal-origin') and verify you do not receive a 400 with
the message "method [get|post|put|delete] exists but is not available
with the current configuration"
4. Repeat steps 1 & 2 from the current head of main and verify that you
DO receive a 400 with the message "method [get|post|put|delete] exists
but is not available with the current configuration"
Regression testing - ensure that interfaces which leverage spaces and
roles APIs are functioning properly
- Spaces management
- Space navigation
- Roles management
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Follow-up to #190690
Most of API integration tests does not match the path pattern set in the
original PR (thanks @pheyos for catching it) and where not updated.
This PR updates `.eslintrc.js` with explicit patterns to lint
api_integration tests. Hopefully it is final change, but I rely on code
owners to double check it.
Most of the changes are trivial adjustments:
- duplicated before/after hooks `mocha/no-sibling-hooks`
- duplicated test titles `mocha/no-identical-title`
- async function in describe() `mocha/no-async-describe`
---------
Co-authored-by: Ash <1849116+ashokaditya@users.noreply.github.com>
## Summary
Moving common services to respective new homes.
Resolves: https://github.com/elastic/kibana/issues/188541
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/189867
#### Summary
This PR improves the use of synthtrace as data generator for infra
functional test
#### What was done
- update `host.ts` in infra synthtrace client, so it can accept `cpu`
value as a param, added `core` metrics and the option to create a k8s
node same as a pod
- added `k8snode` entity to synthtrace client
- created `uninstallSystemPackage` method to
`infra_synthtrace_kibana_client`
- created a getter for the logs ES client in the test utils
- update and fix infra funtional tests
#### TODO in follow-up
- remove the use of archives
- get processes data also with synthtrace
- create alerts data with synthtrace
## Summary
While working on #188737 I had to move `supertestWithoutAuth` into
`kbn-ftr-common-functional-services` package. This change seems to be
bigger than initially planned.
Moving it to the separate PR with following changes:
- move FTR `SupertestWithoutAuthProvider` service to package
- remove "duplicates" in favour of service from package
- update service type where needed
## Summary
At the moment, our package generator creates all packages with the type
`shared-common`. This means that we cannot enforce boundaries between
server-side-only code and the browser, and vice-versa.
- [x] I started fixing `packages/core/*`
- [x] It took me to fixing `src/core/` type to be identified by the
`plugin` pattern (`public` and `server` directories) vs. a package
(either common, or single-scoped)
- [x] Unsurprisingly, this extended to packages importing core packages
hitting the boundaries eslint rules. And other packages importing the
latter.
- [x] Also a bunch of `common` logic that shouldn't be so _common_ 🙃
### For maintainers
- [x] 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
https://github.com/elastic/kibana/pull/183611
I moved x-pack/test/security_solution_endpoint to
x-pack/test/security_solution_api_integration in
https://github.com/elastic/kibana/pull/183611 as I thought all the tests
regarding Security Solution should live there.
However security_solution_endpoint are not api tests , they are UI
tests. After discussions, we decided to move security_solution_endpoint
back to `x-pack/test/`
The two files below are shared between
`x-pack/test/security_solution_api_integration/test_suites/security_solution_endpoint_api_int`
and `x-pack/test/security_solution_endpoint`, moved them to `services`
in this PR to avoid type check confusion.
-
x-pack/test/common/services/security_solution/endpoint_data_stream_helpers.ts
-
x-pack/test/common/services/security_solution/endpoint_registry_helpers.ts
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR introduces Alert Suppression for ML Detection Rules. This
feature is behaviorally similar to alerting suppression for other
Detection Engine Rule types, and nearly identical to the analogous
features for EQL rules.
There are some additional UI behaviors introduced here as well, mainly
intended to cover the shortcomings discovered in
https://github.com/elastic/kibana/issues/183100. Those behaviors are:
1. Populating the suppression field list with fields from the anomaly
index(es).
1. Disabling the suppression UI if no selected ML jobs are running
(because we cannot populate the list of fields on which they'll be
suppressing).
1. Warning the user if _some_ selected ML jobs are not running (because
the list of suppression fields may be incomplete).
See screenshots below for more info.
### Intermediate Serverless Deployment
As per the "intermediate deployment" requirements for serverless, while
the schema (and declared alert SO mappings) will be extended to allow
this functionality, the user-facing features are currently hidden behind
a feature flag. Once this is merged and released, we can issue a "final"
deployment in which the feature flag is enabled, and the feature
effectively released.
## Screenshots
* Overview of new UI fields
<img width="1044" alt="Screenshot 2024-05-16 at 3 22 02 PM"
src="8c07700d-5860-4d1e-a701-eac84fc35558">
* Example of Anomaly fields in suppression combobox
<img width="881" alt="Screenshot 2024-06-06 at 5 14 17 PM"
src="9aa6ed99-1e02-44a0-ad1b-785136510d68">
* Suppression disabled due to no jobs running
<img width="668" alt="Screenshot 2024-06-17 at 11 23 39 PM"
src="a8636a52-31bd-4579-9bcd-d59d93c26984">
* Warning due to not all jobs running
<img width="776" alt="Screenshot 2024-06-17 at 11 26 16 PM"
src="f44c2400-570e-4fde-adce-e5841a2de08d">
## Steps to Review
1. Review the Test Plan for an overview of behavior
2. Review Integration tests for an overview of implementation and edge
cases
3. Review Cypress tests for an overview of UX changes
4. Testing on [Demo
Instance](https://rylnd-pr-181926-ml-rule-alert-suppression.kbndev.co/)
(elastic/changeme)
1. This instance has the relevant feature flag enabled, has some sample
auditbeat data, as well as the [anomalies archive
data](https://github.com/elastic/kibana/tree/main/x-pack/test/functional/es_archives/security_solution/anomalies)
for the purposes of exercising an ML rule against "real" anomalies
1. There are a few example rules in the default space:
1. A simple [query
rule](f6f5960d-7e4b-40c1-ae15-501112822130)
against auditbeat data
1. An [ML
rule](9122669e-b2e1-41ce-af25-eeae15aa9ece)
with per-execution suppression on both `by_field_name` and
`by_field_value` (which ends up not actually suppressing anything)
1. An [ML
rule](0aabc280-00bd-42d4-82e6-65997c751797)
with per-execution suppression on `by_field_name` (which suppresses all
anomalies into a single alert)
## Related Issues
- This feature was temporarily blocked by
https://github.com/elastic/kibana/issues/183100, but those changes are
now in this PR.
## Checklist
- [x] Functional changes are hidden behind a feature flag. If not
hidden, the PR explains why these changes are being implemented in a
long-living feature branch.
- [x] Functional changes are covered with a test plan and automated
tests.
* [Test Plan](https://github.com/elastic/security-team/pull/9279)
- [x] Stability of new and changed tests is verified using the [Flaky
Test Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner) in
both ESS and Serverless. By default, use 200 runs for ESS and 200 runs
for Serverless.
* [ESS - Cypress x
200](https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/6449)
* [Serverless - Cypress x
200](https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/6450)
* [ESS - API x
200](https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/6447)
* [Serverless - API x
200](https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/6448)
- [ ] Comprehensive manual testing is done by two engineers: the PR
author and one of the PR reviewers. Changes are tested in both ESS and
Serverless.
- [ ] Mapping changes are accompanied by a technical design document. It
can be a GitHub issue or an RFC explaining the changes. The design
document is shared with and approved by the appropriate teams and
individual stakeholders.
- [ ] (OPTIONAL) OpenAPI specs changes include detailed descriptions and
examples of usage and are ready to be released on
https://docs.elastic.co/api-reference. NOTE: This is optional because at
the moment we don't have yet any OpenAPI specs that would be fully
"documented" and "GA-ready" for publishing on
https://docs.elastic.co/api-reference.
- [ ] Functional changes are communicated to the Docs team. A ticket is
opened in https://github.com/elastic/security-docs using the [Internal
documentation request (Elastic
employees)](https://github.com/elastic/security-docs/issues/new?assignees=&labels=&projects=&template=docs-request-internal.yaml&title=%5BRequest%5D+)
template. The following information is included: feature flags used,
target ESS version, planned timing for ESS and Serverless releases.
---------
Co-authored-by: Nastasha Solomon <79124755+nastasha-solomon@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Part of https://github.com/elastic/kibana/issues/7104
Add support for `http2` to the Kibana server. `http2` can be enabled by
setting `server.protocol: http2` in the Kibana config file.
*Note: by default, enabling `http2` requires a valid `h2c`
configuration, meaning that it can only run over HTTPS with TLS1.2+*
```yaml
## kibana.yaml
server.protocol: http2
server.ssl.enabled: true
server.ssl.key: path/to/key
server.ssl.certificate: path/my/cerf
```
## What is this PR doing
### Add HTTP2 support for the Kibana server
#### - Plug http2 to the Kibana server
Even if HAPI was never officially updated to really support HTTP2,
node's `http`/`https`/`http2` modules are compatible enough to be able
to just instantiate an http2 server/listener and provide it to HAPI "as
a plain https listener". There were some tweaks to do (mostly silencing
a few warnings that HAPI was causing by sending http2-illegal headers
such as `Connection`), but overall, it went smoothly.
#### - Add config validation
By default, Kibana will require a valid `h2c` configuration to accept
enabling `http2`. It means that TLS must be enabled and that TLS1.2+
should at least be in the list of supported SSL protocols
(`server.ssl.supportedProtocols`). Note that default value of this
setting includes TLS1.2 and 1.3.
#### - Add escape hatch to run `h2` without `h2c`
In some situations, it may be required to enable http2 without a valid
`h2c` configuration. Kibana supports it, by setting
`server.http2.allowUnsecure` to `true`.
(*Note, however, that if http2 is enabled without TLS, ALPN protocol
negotiation won't work, meaning that most http2 agents/clients will fail
connecting unless they're explictly configured to use http2.*)
### Add documentation about this new feature
#### - Update the user-facing doc about this new `server.protocol`
setting
Update the user-facing Kibana settings documentation to include this
`http.protocol` setting (and refer to `server.http2.allowUnsecure`)
**Note: this setting, and this feature, are considered as experimental**
### Adapt our dev tooling to support running Kibana with http2 enabled
#### - Add a `--http2` flag to the dev CLI
Enabling this flag will add the proper configuration settings to run
Kibana with `http2` enabled in an (almost) valid `h2c` configutation.
*Note: when using this flag, even if listening on the same port, the
Kibana server will be accessible over https, meaning that you need to
use https in your browser to access it. Aka `http://localhost:5601`
won't work, you need to use `https://localhost:5601`. Also, we're using
the self-signed dev certificates, meaning that you must go though the
scary warning of your browser*
#### - Implement an http2-compatible base-path proxy
The current base path proxy is based on `hapi` and `hapi/h2o2`. I tried
for a bunch hours trying to hack around to make it work with http2
proxying, but ultimately gave up and implemented a new version from
scratch.
Note that with some additional efforts, this new http2 basepath proxy
could probably fully replace the existing one and be used for both http1
and http2 traffic, but it's an optimization / refactoring that did not
feel required for this PR.
### Adapt the FTR to run suites against http2
#### - Add support to run FTR test suite against an h2c-enabled Kibana
Note that with ALPN, clients using http1 should be (and are) able to
communicate with http2 Kibana, given h2c/alpn allows protocol
negitiation. So adapting our FTR tooling was not really about making it
work with http2 (which worked out of the box), but making it work with
**the self signed certifcates we use for https on dev mode**
Note that I'm not a big fan of what I had to do, however, realistically
this was the only possible approach if we want to run arbitrary test
suites with TLS/HTTP2 enabled without massively changing our FTR setup.
Operations and QA, feel free to chime in there, as this is your
territory.
#### - Change some FTR test suites to run against an HTTP2-enabled
server
I added a quick `configureHTTP2` helper function to take any "final" FTR
suite config and mutate it to enable `http2`. I then enabled it on a few
suites locally, to make sure the suites were passing correctly.
I kept two suites running with http2 enabled:
- the `console` oss functional tests
- the `home` oss functional tests
We could possibly enable it for more, but we need to figure out what
kind of strategy we want on that matter (see below)
## What is this pull request NOT doing
#### - Making sure everything works when HTTP2 is enabled
I navigated the applications quite a bit, and did not see anything
broken, however I obviously wasn't able to do a full coverage. Also, the
self-signed certificate was a huge pain to detect issues really caused
by http2 compared to issues because the local setup isn't valid `h2c`.
In theory though (famous last words) anything not doing http/1.1
specific hacks such as bfetch should work fine with http2, given that
even if using non-http2 clients, ALPN should just allow to fallback to
http/1.x (this part was tested)
#### - Enabling HTTP2 by default
PR isn't doing it for obvious reasons.
#### - Enabling HTTP2 for all FTR suites
First of all, it's not that easy, because it requires adapting various
parts of the config (and even some var env...), and we don't have any
proper way to override config "at the end". For instance, if you add the
http2 config on a top level config (e.g. the oss functional one that is
reuse by the whole world - learned the hard way), it won't work because
higher-level configs redefined (and override) the `browser` part of the
config, loosing the settings added to run the browser in insecure mode.
Secondly, I'm not sure we really need to run that many suites with http2
enabled. I learned working on that PR that we only have like one suite
where https is enabled for the Kibana server, and I feel like it could
be fine to have the same for http2. In theory it's just a protocol
change, unless parts of our apps (e.g. bfetch) are doing things that are
specific to http/1.1, switching to http2 should be an implementation
detail.
But I'd love to get @elastic/kibana-operations and @elastic/appex-qa
opinion on that one, given they have more expertise than I do on that
area.
- Running performances tests
We should absolutely run perf testing between http/1.1 over https and
http/2, to make sure that it goes into the right directly (at least in
term of user perceived speed), but I did not do it in the scope of this
PR (and @dmlemeshko is on PTO so... 😅)
## Release Note
Add support for `http2` to the Kibana server. `http2` can be enabled by
setting `server.protocol: http2` in the Kibana config file.
Note: by default, enabling `http2` requires a valid `h2c` configuration,
meaning that it can only run over HTTPS with TLS1.2+
Please refer to the Kibana config documentation for more details.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Rule execution log support backfill rule run types
38662629-d600-449b-949a-2aa0166ea3a1
### Feature flag
`manualRuleRunEnabled`
### Description
- Add new column for table with rule run type "Manual" / "Scheduled"
- Add new switch to show column with source event time range for
backfill run
- event execution log api support `run_type_filters` filters as
parameter with values like "standard" and "backfill"
- event execution log result will return new field for backfill runs -
`backfill`
### How to test
1 . Enable feature flag - `manualRuleRunEnabled`
2. For you rule call schedule api
`/internal/alerting/rules/backfill/_schedule` `POST`
With this body (put your values for rule id and date range):
```
[{"rule_id":"58b4b926-6348-4c23-be1f-870a461fa342","start":"2024-05-21T13:00:00.000Z","end":"2024-05-21T14:05:00.000Z"}]
```
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Related to https://github.com/elastic/kibana/issues/7104
Update supertest, superagent, and the corresponding type package, to
their latest version.
(of course, types had some signature changes and we're massively using
supertest in all our FTR suites so the whole Kibana multiverse has to
review it)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Part of https://github.com/elastic/kibana/issues/179844
### In this PR
- From Inventory, open asset details page view for Containers
- Show overview tab with CPU and Memory KPIs and metric charts
- Metadata tab with old fields, more metadata fields will be shown in
follow-up PR
- Added links to container metrics documentation, currently there are no
docs for K8s metrics just for docker containers
#### How to test
- The feature is under a FF, on inventory page go to settings and enable
`Container view`
- In containers inventory, select a container and click on 'Docker
container metrics' link (there's an
[issue](https://github.com/elastic/kibana/issues/180806) to reword this
links as K8s containers are also shown)
- Container details page should be shown with overview and metadata tabs
- On overview tab KPIs for CPU and Memory and Metrics section with CPU
and Memory charts should be displayed
<img width="937" alt="image"
src="d2f25f2a-ea4f-4516-b216-38464682fd14">
## Summary
Revives this https://github.com/elastic/kibana/pull/181969
To do so, I had to create a new package `search-types` and move the
types I need there.
The Discovery team can take it from here.
Note: It also does a cleanup on the types I move, some of them were
declared twice.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Closes https://github.com/elastic/kibana/issues/175064
- Creates a service for ApmSynthtraceKibanaClient to easily access in
tests and other plugins for managing the installation of the APM package
needed for indexing apm documents with synthtrace's elasticsearch client
- Updates the Infra api integration and functional tests to use the
service
- Updates Infra tests to cleanup and uninstall the apm package
- Updates ApmSynthtraceKibanaClient.installApmPackage to install the
latest version if no version was passed in
- Updates ApmSynthtraceKibanaClient.installApmPackage to return the
version that was installed
- Updates ApmSynthtraceKibanaClient to have an uninstallApmPackage
method
https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/5599
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Felix Stürmer <weltenwort@users.noreply.github.com>
**Resolves: https://github.com/elastic/kibana/issues/151902**
## Summary
After this PR, all D&R FTRs are moved to new folder where they can be
run in ESS and serverless. Please see below table for a summary of what
tests need revisiting by the teams. During the test migration there may
have been some tests that failed on serverless, but not ESS. Some we
were able to fix and get running on both, others are still marked as
`brokenInServerless` and need triage.
**Addresses:** https://github.com/elastic/kibana/issues/164451
## Summary
This PR allows to run role based reused between ESS and Serverless Cypress tests.
## Details
The main idea behind is to make environmental differences for tests unnoticeable. As Serverless env already has roles and users but ESS env allows to create any possible role and user we just need to create Serverless roles and corresponding users + specific ESS roles and corresponding users in ESS env before running any ESS tests. This way tests will run in a similar env and don't have to bother by roles/users creation in test suites. This is achieved by using separate Cypress support files (Cypress includes `support/e2e.js` by default) `ess_e2e.ts` and `serverless_e2e.ts` executed for corresponding environments. `ess_e2e.ts` contains logic to create mentioned above roles and users while `serverless_e2e.ts` doesn't contain such logic.
_Only one user created per role and user has the same name as its corresponding role with `changeme` password._
To have an ability to create roles we need to store their definitions somewhere. It's also convenient to have JSON definitions instead of YAML. Plus Serverless roles should be pulled from `project-controller` repo but it's not addressed in this PR. I've chosen the following locations
- Serverless Security roles in `packages/kbn-es/src/serverless_resources/security_roles.json`. While `@kbn/es` is a common package it has `serverless_resources` folder containing `roles.yml` with a mix of `https://github.com/elastic/project-controller/blob/main/internal/project/observability/config/roles.yml`, `https://github.com/elastic/project-controller/blob/main/internal/project/esproject/config/roles.yml` and `https://github.com/elastic/project-controller/blob/main/internal/project/security/config/roles.yml` copied from `project-controller` and used for ES data restore. As there is no automation yet it looks logical to keep Security roles subset next to ES Serverless resources.
- ESS Security specific roles in `x-pack/plugins/security_solution/common/test/ess_roles.json`
On top of that the following has been done
- `reader` role replaced with `t1_analyst` where possible in tests (besides `e2e/explore/cases/attach_alert_to_case.cy.ts` but it's purely ESS test so it's fine) as `reader` is ESS specific and make harder to run the same tests in ESS and Serverless environments but both roles are almost equivalent
- `login()` helper function accepts all known roles (Serverless + ESS) but throws an exception if a custom ESS role is used under Serverless env
- `x-pack/plugins/security_solution/server/lib/detection_engine/scripts/roles_users` isn't necessary anymore as `security_roles.json` + `ess_roles.json` contain all the necessary data to create roles and users
### Does it enable role support for MKI environments?
No. This PR only enabling role support for Non-MKI Serverless environments. MKI env has predefined roles but not users. This will be addressed in a follow up PR.
## Flaky test runner
Two unskiped in this PR Serverless Cypress tests using non default role `detection_response/detection_alerts/missing_privileges_callout.cy.ts` and `detection_response/prebuilt_rules/prebuilt_rules_install_update_authorization.cy.ts` [150 runs](https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/3723) 🟢 (there is one env related failure but it doesn't look related to the changes in this PR)
## 📓 Summary
Closes#159128
Due to a dependencies issue when disabling a plugin in serverless mode,
the LogStream feature and related logic were disabled for every
consumer.
We decided to split this shared component and endpoint into their own
plugin of shared logs utilities, reducing to the minimum the required
dependency that could disable the plugin.
What we moved can be summarized with:
- `infrastructure-monitoring-log-view` saved object definition and
registration
- LogViews server/client services (exposed with start contract) +
related endpoints
- LogEntries server service + related endpoints
- LogEntriesDomain logic (exposed with start contract)
- `<LogStream />` component
- `<ScrollableLogTextStreamView />` component and related logic
- LogView state machine
- Containers/Hooks to consume the moved APIs.
- Common types/utils definition, now exported and consumed as a
dependency from the `infra` plugin.
## 🤓 Review hints
Most of the changes are just renaming and moving stuff into the new
plugin, but for some operations was required to implement new logic,
which may deserve a more critical review:
- server/public `plugin.ts` files for the `infra` and `logs_shared`
plugins. The new plugin now registers the fallback actions to retrieve a
source configuration if there's no stored log view. It also set the
configuration for the message field and registers the log view saved
object.
- the `logEntriesDomain` has also been moved inside the new plugin, but
is also used by the logs-analysis endpoints, so it is exposed by the
logs_shared plugin and consumed by `infra`.
## 👣 Following steps
We currently are still using the `observability` plugin for consuming
the CoPilot feature on our LogsStream flyout.
The plugin dependency is marked as optional, so disabling the
`observability` plugin in a serverless environment won't disable also
the exposed features in this new plugin, but it'll affect only the
CoPilot feature, which won't be loaded.
In future, would be nice to extract the CoPilot feature into its own
package/plugin, so that also serverless projects can consume it without
depending on `observability.
---------
Co-authored-by: Marco Antonio Ghiani <marcoantonio.ghiani@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Description
Fix https://github.com/elastic/kibana/issues/104081
This PR move some of the SO types from the `.kibana` index into the
following ones:
- `.kibana_alerting_cases`
- `.kibana_analytics`
- `.kibana_security_solution`
- `.kibana_ingest`
This split/reallocation will occur during the `8.8.0` Kibana upgrade
(*meaning: from any version older than `8.8.0` to any version greater or
equal to `8.8.0`*)
**This PR main changes are:**
- implement the changes required in the SO migration algorithm to
support this reallocation
- update the FTR tools (looking at you esArchiver) to support these new
indices
- update hardcoded references to `.kibana` and usage of the
`core.savedObjects.getKibanaIndex()` to use new APIs to target the
correct index/indices
- update FTR datasets, tests and utility accordingly
## To reviewers
**Overall estimated risk of regressions: low**
But, still, please take the time to review changes in your code. The
parts of the production code that were the most impacted are the
telemetry collectors, as most of them were performing direct requests
against the `.kibana` index, so we had to adapt them. Most other
contributor-owned changes are in FTR tests and datasets.
If you think a type is misplaced (either we missed some types that
should be moved to a specific index, or some types were moved and
shouldn't have been) please tell us, and we'll fix the reallocation
either in this PR or in a follow-up.
## .Kibana split
The following new indices are introduced by this PR, with the following
SO types being moved to it. (any SO type not listed here will be staying
in its current index)
Note: The complete **_type => index_** breakdown is available in [this
spreadsheet](https://docs.google.com/spreadsheets/d/1b_MG_E_aBksZ4Vkd9cVayij1oBpdhvH4XC8NVlChiio/edit#gid=145920788).
#### `.kibana_alerting_cases`
- action
- action_task_params
- alert
- api_key_pending_invalidation
- cases
- cases-comments
- cases-configure
- cases-connector-mappings
- cases-telemetry
- cases-user-actions
- connector_token
- rules-settings
- maintenance-window
#### `.kibana_security_solution`
- csp-rule-template
- endpoint:user-artifact
- endpoint:user-artifact-manifest
- exception-list
- exception-list-agnostic
- osquery-manager-usage-metric
- osquery-pack
- osquery-pack-asset
- osquery-saved-query
- security-rule
- security-solution-signals-migration
- siem-detection-engine-rule-actions
- siem-ui-timeline
- siem-ui-timeline-note
- siem-ui-timeline-pinned-event
#### `.kibana_analytics`
- canvas-element
- canvas-workpad-template
- canvas-workpad
- dashboard
- graph-workspace
- index-pattern
- kql-telemetry
- lens
- lens-ui-telemetry
- map
- search
- search-session
- search-telemetry
- visualization
#### `.kibana_ingest`
- epm-packages
- epm-packages-assets
- fleet-fleet-server-host
- fleet-message-signing-keys
- fleet-preconfiguration-deletion-record
- fleet-proxy
- ingest_manager_settings
- ingest-agent-policies
- ingest-download-sources
- ingest-outputs
- ingest-package-policies
## Tasks / PRs
### Sub-PRs
**Implementation**
- 🟣https://github.com/elastic/kibana/pull/154846
- 🟣https://github.com/elastic/kibana/pull/154892
- 🟣https://github.com/elastic/kibana/pull/154882
- 🟣https://github.com/elastic/kibana/pull/154884
- 🟣https://github.com/elastic/kibana/pull/155155
**Individual index split**
- 🟣https://github.com/elastic/kibana/pull/154897
- 🟣https://github.com/elastic/kibana/pull/155129
- 🟣https://github.com/elastic/kibana/pull/155140
- 🟣https://github.com/elastic/kibana/pull/155130
### Improvements / follow-ups
- 👷🏼 Extract logic into
[runV2Migration](https://github.com/elastic/kibana/pull/154151#discussion_r1158470566)
@gsoldevila
- Make `getCurrentIndexTypesMap` resillient to intermittent failures
https://github.com/elastic/kibana/pull/154151#discussion_r1169289717
- 🚧 Build a more structured
[MigratorSynchronizer](https://github.com/elastic/kibana/pull/154151#discussion_r1158469918)
- 🟣https://github.com/elastic/kibana/pull/155035
- 🟣https://github.com/elastic/kibana/pull/155116
- 🟣https://github.com/elastic/kibana/pull/155366
## Reallocation tweaks
Tweaks to the reallocation can be done after the initial merge, as long
as it's done before the public release of 8.8
- `url` should get back to `.kibana` (see
[comment](https://github.com/elastic/kibana/pull/154888#discussion_r1172317133))
## Release Note
For performance purposes, Kibana is now using more system indices to
store its internal data.
The following system indices will be created when upgrading to `8.8.0`:
- `.kibana_alerting_cases`
- `.kibana_analytics`
- `.kibana_security_solution`
- `.kibana_ingest`
---------
Co-authored-by: pgayvallet <pierre.gayvallet@elastic.co>
Co-authored-by: Christos Nasikas <christos.nasikas@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Georgii Gorbachev <georgii.gorbachev@elastic.co>
