- Enabled @typescript-eslint/consistent-type-imports eslint rule for
ResponseOps packages and plugins:
- this rule ensures that imports used only for type declarations are
consistently written using import type syntax
- fixed type imports for:
- x-pack/test/alerting_api_integration
- x-pack/test/cases_api_integration
- x-pack/test/rule_registry
- x-pack/test/api_integration/apis/cases
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## 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
This PR adds a test config category to the scout reporting. This allows
us to distinguish between UI and API FTR tests.
A new property `testConfigCategory` has been added to all FTR configs
that don't already inherit it from a higher level config.
## 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>
## Summary
All lifecycle rule types have been migrated to use the alerting
framework alerts client so the lifecycle executor in the rule registry
can be removed since it is no longer in use.
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Adds the `['rac']` API access scope to the Stack Alerts feature to
correctly authenticate alerts API endpoints with the `stackAlerts`
permission.
Also adds a dedicated API integration test for the impacted endpoint and
permission set.
## Release note
Fix Stack Alerts feature API access control
## To verify
1. Create rules that fire alerts in Stack management
2. Wait for alerts to be created
3. Create a role with only `Stack Management > Rules : Read` privilege
4. Create a user with that role
5. In another window, open Kibana with the newly created user
6. Check that the Stack Management > Alerts page renders correctly, not
showing any missing 403 error toasts
## Summary
Alerts use its own RBAC model. The RBAC relies on a property called
`consumer`. The consumer is tight coupled with the feature ID. It
denotes the user's access to the rule and the alerts. For example, a
user with access to the "Logs" feature has access only to alerts and
rules with the `consumer` set as `logs`. Users can create an ES Query
rule from Discover. When the feature was
[implemented](https://github.com/elastic/kibana/pull/124534) (v8.3.0)
the consumer was set to `discover`. Then it
[changed](https://github.com/elastic/kibana/pull/166032) (v8.11.0) to
`stackAlerts` (visible only on the stack management page) and then
[to](https://github.com/elastic/kibana/pull/171364) (v8.12.0) `alerts`
so it can be visible in Observability. Users who created rules that
generated alerts with the `discover` consumer cannot see the alerts
generated by the rule when they upgrade Kibana to 8.11+ even as
superusers. This PR fixes the issues around the `discover` consumer.
I added the following alert document to the `data.json.gz` to test for
alerts with `discover` consumer.
```
{
"type": "doc",
"value": {
"id": "1b75bfe9-d2f5-47e9-bac6-b082dd9c9e97",
"index": ".internal.alerts-stack.alerts-default-000001",
"source": {
"@timestamp": "2021-10-19T14:00:38.749Z",
"event.action": "active",
"event.kind": "signal",
"kibana.alert.duration.us": 1370302000,
"kibana.alert.evaluation.threshold": -1,
"kibana.alert.evaluation.value": 80,
"kibana.alert.instance.id": "query matched",
"kibana.alert.reason": "Document count is 80 in the last 100d in .kibana_alerting_cases index. Alert when greater than -1.",
"kibana.alert.rule.category": "Elasticsearch query",
"kibana.alert.rule.consumer": "discover",
"kibana.alert.rule.name": "EsQuery discover",
"kibana.alert.rule.producer": "stackAlerts",
"kibana.alert.rule.rule_type_id": ".es-query",
"kibana.alert.rule.uuid": "25c14920-faa7-4a9a-830c-ce32c8211237",
"kibana.alert.start": "2021-10-19T15:00:41.555Z",
"kibana.alert.status": "active",
"kibana.alert.time_range": {
"gte": "2021-10-19T15:00:41.555Z"
},
"kibana.alert.uuid": "23237979-75bf-4b68-a210-ce5056b93356",
"kibana.alert.workflow_status": "open",
"kibana.space_ids": [
"default"
],
"kibana.version": "8.0.0",
"tags": []
}
}
}
```
## Testing
1. Create a rule with the consumer as `discover`. See
https://github.com/elastic/kibana/issues/184595 for instructions.
2. Go to the rule details page.
3. Verify that you do not get any error toaster and you can see the
alerts.
Fixes: https://github.com/elastic/kibana/issues/184595
### Checklist
Delete any items that are not applicable to this PR.
- [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
### 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)
## Release notes
Fix an issue with rules not being accessible created from Discover
before 8.11.0.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Resolves https://github.com/elastic/kibana/issues/184324
## Summary
This PR moves the loading of maintenance windows further down in rule
execution so maintenance windows are only loaded when a rule execution
generates alerts. Also caches maintenance windows per space to reduce
the number of requests.
## To Verify
1. Add some logging to
x-pack/plugins/alerting/server/task_runner/maintenance_windows/maintenance_windows_service.ts
to indicate when windows are being fetched and when they're returning
from the cache.
2. Create and run some rules in different spaces with and without alerts
to see that the maintenance windows are only loaded when there are
alerts and that the windows are returned from the cache when the cache
has not expired.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Kibana requires security to be enabled and a platinum or better license
to run in FIPS mode.
Since not all FTR configs assume these conditions will be enabled, we
cant run every test. So these failing tests will be skipped when these
overrides are enforced.
This does not mean that the functionality is not supported in FIPS mode.
## What is the point?
Running these tests in FIPS mode is not necessarily to check that the
functionality works as expected, it is to make sure Kibana does not
crash due to unsupported algorithm usage (`md4`, `md5`, etc).
When running in FIPS mode, Node will throw an `unsupported envelope
function` error (with FIPS enabled) if it encounters an unsupported
algorithm, so the more lines of code covered, the more assurance we can
have that features will work in FIPS mode.
## Nature of the changes
To skip a test, a `tag` is added: `this.tags('skipFIPS')`
`this.tags` is only available for `describe('description', function()
{...});`
There should not be any logical changes, just tests wrapped in an extra
block.
I tried to make the wording in the new `describe` block "flow" 😅 if you
prefer different wording in the new `describe` block - please add a
change!
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Nikita Indik <nikita.indik@elastic.co>
## Summary
We saw a stateful project which had a pause of 46m from when Kibana
started, to when it completed. It appears ES must have been inaccessible
during that time and the rule registry was not able to install the
alerting resources. This PR uses an observable from Core to wait to
install the alerting resources until ES is ready.
### Checklist
- [ ] [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
### To verify
- Start Kibana without starting ES
```
yarn start --logging.root.level=debug
```
- Verify that the alerting resources are not installed, you should not
see this debug log `Initializing resources for AlertsService`
- Start ES and verify that the resources are installed, and you see the
log above
## Summary
Implements a new `useSearchAlertsQuery` hook based on TanStack Query to
replace the `useFetchAlerts` hook, following [this organizational
logic](https://github.com/elastic/kibana/issues/186448#issuecomment-2228853337).
This PR focuses mainly on the fetching logic itself, leaving the
surrounding API surface mostly unchanged since it will be likely
addressed in subsequent PRs.
## To verify
1. Create rules that fire alerts in different solutions
2. Check that the alerts table usages work correctly ({O11y, Security,
Stack} alerts and rule details pages, ...)
1. Check that the alerts displayed in the table are coherent with the
solution, KQL query, time filter, pagination
2. Check that pagination changes are reflected in the table
3. Check that changing the query when in pages > 0 resets the pagination
to the first page
Closes point 1 of https://github.com/elastic/kibana/issues/186448
Should fix https://github.com/elastic/kibana/issues/171738
### Checklist
- [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
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Fixes autocomplete in kuery bar for uptime/synthetics fields !!
Also added tags into documents !!
### Before
uptime/synthetics field names never appeared in kql query bar on alerts
<img width="1728" alt="image"
src="e471567b-951d-4ad0-9d3a-78a5168b7a91">
### After
Typing fields name will show suggestions
<img width="1725" alt="image"
src="da453f0d-1956-4703-a371-842139bd7d4c">
Towards: https://github.com/elastic/kibana/issues/169867
This PR onboards the Transaction Error Rate rule type with FAAD.
### To verify
1. Run the following script to generate APM data:
```
node scripts/synthtrace many_errors.ts --local --live
```
2. Create a transaction error rate rule.
Example:
```
POST kbn:/api/alerting/rule
{
"params": {
"threshold": 0,
"windowSize": 5,
"windowUnit": "m",
"environment": "ENVIRONMENT_ALL"
},
"consumer": "alerts",
"schedule": {
"interval": "1m"
},
"tags": [],
"name": "test",
"rule_type_id": "apm.transaction_error_rate",
"notify_when": "onActionGroupChange",
"actions": []
}
```
3. Your rule should create an alert and should saved it in
`.internal.alerts-observability.apm.alerts-default-000001`
Example:
```
GET .internal.alerts-*/_search
```
4. Recover the alert by setting `threshold: 200`
5. The alert should be recovered and the AAD in the above index should
be updated `kibana.alert.status: recovered`.
Resolves https://github.com/elastic/kibana/issues/175998
## Summary
Follow on work from the alert creation delay feature. This PR adds
consecutive_matches, which is the count of active alerts that is used to
determine the alert delay, to the aad doc and to the action variables.
### Checklist
- [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
### To verify
- Create a new rule with an alert delay
- Add the new `alert.consecutiveMatches` action variable to the action
message. Verify that when the alert fires the action variable is
populated in the message.
- To verify that the alert docs are as expected, go to [Dev
Tools](http://localhost:5601/app/dev_tools#/console) and run the
following `GET .internal.alerts-*/_search`
- Go back to the rule alerts table, and add the
`kibana.alert.consecutive_matches` field to the table. Verify that it is
populated and looks as expected.
## Summary
Bring back functionality for alert search bar for security solution.
<img width="899" alt="image"
src="13100bd3-4ba9-4cba-9702-d657ee781a4a">
<img width="911" alt="image"
src="0c586d2c-67be-4b37-8fe5-cd483e6def16">
### Checklist
- [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
## Summary
This PR is updating Discover's rule to be created under the
`stackAlerts` consumer and we created an [breaking change
issue](https://github.com/elastic/dev/issues/2344) to explain the
consequences of this update.
We also fix the rule's consumer for all rule types created under the
observability rule management to use their producer instead of `alerts`.
Also, we add the ability for the ES Query and new Generic Threshold
rules type to pick the consumer associated to the rule. The
`ensureAuthorized` and the `filter` functions have modified and
simplified to support this use case please check the newest unit test
added in
`x-pack/plugins/alerting/server/authorization/alerting_authorization.test.ts`.
There is now a dropdown in the rule form to prompt the user when
creating ES Query/Generic threshold rules to select the consumer based
on their authorized consumers (we can no longer use `alerts` for these).
If there is only 1 option, then the dropdown will not be shown and the
option will be chosen automatically.
Generic threshold rules will have the following possible consumers:
- infrastructure
- logs
ES query rules will have the following possible consumers:
- infrastructure
- logs
- stackAlerts (only from the stack management rule page)
## To Test:
### Single Consumer:
1. Create a user with only `logs` feature enabled (ensuring
`stackAlerts` is not enabled).
2. Navigate to the O11Y rule management page
3. Click the create rule button
4. Assert that both ES query and generic threshold rules are available
5. Click ES query and fill out the relevant information and create the
rule
6. Assert that the rule created has `logs` set in the `consumer` field
7. Repeat 5-6 for the generic threshold rule
8. Repeat 2-7 but on the Stack Management rules page
9. Repeat 1-8 for the `infrastructure` feature.
### Multiple Consumers:
1. Create a user with `logs`, `infrastructure` and `apm` features
enabled (ensuring `stackAlerts` is not enabled).
2. Navigate to the O11Y rule management page
3. Click the create rule button
4. Assert that both ES query and generic threshold rules are available
5. Click ES query and fill out the relevant information and create the
rule
6. A dropdown should prompt the user to select between 1 of the 3
consumers, select 1
7. Assert that the rule was created with the selected consumer
8. Repeat 5-7 for the generic threshold rule
9. Repeat 2-8 but on the Stack Management rules page
### Checklist
- [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
---------
Co-authored-by: Jiawei Wu <74562234+JiaweiWu@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
resolves https://github.com/elastic/kibana/issues/154266
Changes the way the alerts-as-data (AAD) indices are created and written
to, to allow them to be built as they have been in the past (alias and
backing indices created manually) OR as an ES Data Stream.
Serverless will use Data Streams, other environments will use the
existing alias and backing indices. The determination is made by
optionally including the `serverless` plugin, and determining if it's
available.
The implementation is organized around a `DataStreamAdapter` object,
which is instantiated with a "data stream" or "alias" flavor, and then
it handles the specialized behavior. Currently, a lot of the smaller
implementation bits, like setting property values in ES calls, is done
via in-line boolean checks of that object, as to whether data streams or
aliases are being used. This could probably be cleaned up some.
Existing non-serverless function tests are largely unchanged, as they
can't test the new data stream path. Some tests have been added to the
serverless function tests, to test basic reading / writing via updated
alert documents.
## DEFER
- more serverless AaD tests
- https://github.com/elastic/kibana/issues/158403 - this issue is more
noticeable now that we HAVE to do OCC with data streams, so we get
errors instead of simply overwriting documents (which is also bad)
Co-authored-by: Patryk Kopycinski <contact@patrykkopycinski.com>
## Summary
We were using the feature Id to determine the alert indices, but we
realized that we should use the rule type id instead. Meaning that we
check which rule type does the user have access and then we get the
indices related to this rule type.
We also took advantage of the new suggestion abstraction of the search
bar components to remove the toaster of hell ->
https://github.com/elastic/kibana/issues/163003
### Checklist
- [ ] [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
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Resolves: #160176
This PR intends to move the getting alert-as-data fetching logic from
ruleRegistry to alerting framework.
`getPersistentAlerts` method fetches the alerts-as-data as long as the
ruleType has `alerts` settings (fields, formatAlert etc.)
## To verify:
All the rules that use alert-as-data should be still working as they
are.
## Summary
In support of https://github.com/elastic/security-team/issues/6726 -
defining a `common/api/` folder for types that must not have breaking
changes made to them.
security_solution/
| - common/
| | - api/
| | | - detection_engine/
| | | | - api_routes/
| | | | - model/
| | | | - sub_domains/
| | | | | - api_routes/
| | | - other_domains/
### Structure
- Every domain can have 3 components: sub-domains, a model, and api
routes
- Every API route has a folder dedicated to that route (e.g.
`/detection_engine/rule_management/crud/create_rule`)
- API route request and response schemas are defined in a single
`*_route.ts` file
- No file in `/common/api/` should import from outside of `/common/api`
(not implemented yet, but this will be enforced by the switch to OpenAPI
yaml files)
- Routes are grouped into domains for convenience
- Domains may have sub-domains
- Domains and sub-domains *may* contain a `model` folder for complex
structures that are shared throughout the domain (e.g.
`/detection_engine/model/rule_schema/`)
- `model` folders *must not* contain any routes in any sub-directory.
Any file with `/model/` in its path is a shared component, not a route.
- Every domain *must* contain at least one route
- Instead of creating `/detection_engine/rule_schema/model`, where
`rule_schema` would not have any routes, we should create
`/detection_engine/model/rule_schema`
- When importing API schemas from outside of `/common/api`, e.g. for
usage in `public` or `server` code, prefer importing from
`/common/api/<domain>` rather than `/common/api/<domain>/<sub
domain>/<route>` to avoid depending on the internal structure of the API
folder
- When importing from one API schema to another, prefer fully specifying
the import path (`/common/api/<domain>/<sub domain>/<route>` instead of
`/common/api/<domain>`) to avoid import cycle problems
- `index.ts` files should be created per top level API domain and export
the API schemas
- `index.ts` files may be created for sub domains if it's convenient
- Avoid importing schemas from one route into another - it's a sign that
the schema should be extracted to the common `model` for the domain
- There are still a number of places where this happens that I haven't
tried to fix yet
### Full List of APIs
https://docs.google.com/spreadsheets/d/1VCoJ74EkyGuj59VwWj_3v2ecB84pNCpzGqkYnS0SUKw/edit#gid=0
To print the full list of APIs for a plugin, add the following code in
`plugin.ts`:
```
const tempGet = router.get;
router.get = (route, handler) => {
console.log(`GET: ${route.path}`);
tempGet(route, handler);
};
const tempPost = router.post;
router.post = (route, handler) => {
console.log(`POST: ${route.path}`);
tempPost(route, handler);
};
const tempPut = router.put;
router.put = (route, handler) => {
console.log(`PUT: ${route.path}`);
tempPut(route, handler);
};
const tempPatch = router.patch;
router.patch = (route, handler) => {
console.log(`PATCH: ${route.path}`);
tempPatch(route, handler);
};
const tempDelete = router.delete;
router.delete = (route, handler) => {
console.log(`DELETE: ${route.path}`);
tempDelete(route, handler);
};
```
## Summary
Closes#158324
Adds API to retrieve the `fieldsForAAD` from a given rule type. This is
a list of fields used for Alerts As Data; at the moment we need these
fields to provide an accurate autocomplete list to the Conditional
Actions UI.
### Checklist
- [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
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Patryk Kopyciński <contact@patrykkopycinski.com>
Reverts elastic/kibana#156869
We need to revert because after talking to @kobelb, we are introducing a
new bug where user always need to be a super user to access the fields
from the alert index since only only super user can access the kibana
index.
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Fix https://github.com/elastic/kibana/issues/155000, @dgieselaar thank
you so much for finding that!!! lot of love from our part. And, we find
a good solution around this API... We are deleting it!!! LOL
### Checklist
Delete any items that are not applicable to this PR.
- [ ] [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
---------
Co-authored-by: Julian Gernun <17549662+jcger@users.noreply.github.com>
## Summary
The way that we canceled every notification for our alert life cycle
during an active maintenance window was not close enough to what our
customers were expecting. For our persisted security solution alerts, we
did not have to change the logic because it will always be a new alert.
Therefore, @shanisagiv1, @mdefazio, @JiaweiWu, and @XavierM had a
discussion about this problem and we decided this:
To summarize, we will only keep the notification during a maintenance
window if an alert has been created/active outside of window
maintenance. We created three different scenarios to explain the new
logic and we will make the assumption that our alert has an action per
status change. For you to understand the different scenarios, I created
this legend below:
<img width="223" alt="image"
src="https://user-images.githubusercontent.com/189600/236045974-f4fa379b-db5e-41f8-91a8-2689b9f24dab.png">
### Scenario I
If an alert is active/created before a maintenance window and recovered
inside of the maintenance window then we will send notifications
<img width="463" alt="image"
src="https://user-images.githubusercontent.com/189600/236046473-d04df836-d3e6-42d8-97be-8b4f1544cc1a.png">
### Scenario II
If an alert is active/created and recovered inside of window maintenance
then we will NOT send notifications
<img width="407" alt="image"
src="https://user-images.githubusercontent.com/189600/236046913-c2f77131-9ff1-4864-9dab-89c4c429152e.png">
### Scenario III
if an alert is active/created in a maintenance window and recovered
outside of the maintenance window then we will not send notifications
<img width="496" alt="image"
src="https://user-images.githubusercontent.com/189600/236047613-e63efe52-87fa-419e-9e0e-965b1d10ae18.png">
### Checklist
- [ ] [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
---------
Co-authored-by: Xavier Mouligneau <xavier.mouligneau@elastic.co>
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Setting `xpack.alerting.enableFrameworkAlerts` to true by default. This
causes alerts-as-data resource installation to be handled by the
alerting plugin and not the rule registry. We're keeping the feature
flag in case we run into issues but eventually we'll clean up the code
to remove the feature flag and clean up the rule registry code that
relies on the feature flag. Changing this default setting early will
allow us to identify issues before the 8.8 FF where we can revert if
needed.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
resolves https://github.com/elastic/kibana/issues/142874
The alerting framework now generates an alert UUID for every alert it
creates. The UUID will be reused for alerts which continue to be active
on subsequent runs, until the alert recovers. When the same alert (alert
instance id) becomes active again, a new UUID will be generated. These
UUIDs then identify a "span" of events for a single alert.
The rule registry plugin was already adding these UUIDs to it's own
alerts-as-data indices, and that code has now been changed to make use
of the new UUID the alerting framework generates.
- adds property in the rule task state
`alertInstances[alertInstanceId].meta.uuid`; this is where the alert
UUID is persisted across runs
- adds a new `Alert` method getUuid(): string` that can be used by rule
executors to obtain the UUID of the alert they just retrieved from the
factory; the rule registry uses this to get the UUID generated by the
alerting framework
- for the event log, adds the property `kibana.alert.uuid` to
`*-instance` event log events; this is the same field the rule registry
writes into the alerts-as-data indices
- various changes to tests to accommodate new UUID data / methods
- migrates the UUID previous stored with lifecycle alerts in the alert
state, via the rule registry *INTO* the new `meta.uuid` field in the
existing alert state.
**Relates to:** https://github.com/elastic/kibana/pull/152900
## Summary
This PR adds an ability to wait for rule status by its rule id in functional tests. It is a result of splitting of https://github.com/elastic/kibana/pull/150553 into isolated parts.
## Details
Based on what kind of id is used (SO id or rule id) it leads to different behaviour under the hood. SO id related functionality consumes ES Get API while rule id related functionality consumes ES Search API. This way it may require to add some delay to let ES to refresh the data if the testing logic consumes ES Search API while rule status was awaited via SO id so that handled by ES Get API. This PR removes such a delay at rule exporting functional tests.
Resolves https://github.com/elastic/kibana/issues/151697
## Summary
In a previous [PR](https://github.com/elastic/kibana/pull/145581) we
started installing a context-specific component templates, index
templates and concrete write indices for framework alerts as data when
the `xpack.alerting.enableFrameworkAlerts` config flag is set to true.
In that PR we used a different naming pattern than what is used by the
rule registry for those resources. In this PR, we are aligning the
naming of these resources with the rule registry and installing these
resources on alerting plugin setup when `enableFrameworkAlerts: true`.
If the flag is set to false, the rule registry will continue to handle
this resource installation.
In this PR we are doing the following:
* Registering all rules currently registered with the rule registry with
the alerting framework. This registration allows the alerting framework
to build context specific component templates. Because this PR only
addresses resource installation, rules will continue to be registered
with the rule registry.
* When `enableFrameworkAlerts: true`:
* The framework installs the context specific component template with
the following naming convention: `.alerts-{context}.alerts-mappings`.
This matches what the rule registry currently installs so the transition
should be seamless
* The framework installs the context specific index template for the
`default` space with the following name:
`.alerts-{context}.alerts-default-index-template`. Space awareness will
be addressed in a followup PR. This matches the current rule registry
naming.This index template will reference
(1) ECS component template (if `useEcs: true`),
(2) context-specific component template,
(3) legacy alert component template and
(4) framework component template
where the legacy alert component template + framework component template
= technical component template (from the rule registry).
* The framework creates or updates the concrete write index for the
`default` space with the naming convention:
`.internal.alerts-{context}.alerts-default-000001`. Space awareness will
be addressed in a followup PR. This matches the current rule registry
naming.
* The installation of the index template & write index differs from the
rule registry in that it occurs on alerting plugin start vs the first
rule run.
* We modified the rule registry resource installer to skip installation
of these resources when `enableFrameworkAlerts: true`. In addition, it
will wait for the alerting resource installation promise so if a rule
runs before its resources are fully initialized, it will wait for
initialization to complete before writing.
## To Verify
The following rule registry contexts are affected:
`observability.apm`
`observability.logs`
`observability.metrics`
`observability.slo`
`observability.uptime`
`security`
For each context, we should verify the following:
`Note that if your rule context references the ECS mappings, there may
be differences in those mappings between main and this branch depending
on whether you're running main with enableFrameworkAlerts true or false.
These differences are explained in the summary of this prior PR:
https://github.com/elastic/kibana/pull/150384 but essentially we're
aligning with the latest ECS fields. In the instructions, I suggest
running main with enableFrameworkAlerts: true to minimize the
differences caused by ECS changes`
**While running `main` with `enableFrameworkAlerts: true`:**
1. Get the context specific component template `GET
_component_template/.alerts-{context}.alerts-mappings`
2. Create rule for this context that creates an alert and then
3. Get the index template `GET
_index_template/.alerts-{context}.alerts-default-index-template`
4. Get the index mapping for the concrete index: `GET
.internal.alerts-{context}.alerts-default-000001/_mapping`
**While running this branch with `xpack.alerting.enableFrameworkAlerts:
true` (with a fresh ES instance):**
5. Get the context specific component template `GET
_component_template/.alerts-{context}.alerts-mappings`
6. Get the index template `GET
_index_template/.alerts-{context}.alerts-default-index-template`
7. Get the index mapping for the concrete index: `GET
.internal.alerts-{context}.alerts-default-000001/_mapping`
Note that you should not have to create a rule that generates alerts
before seeing these resources installed.
**Compare the component templates**
Compare 1 and 5. The difference should be:
* component template from this branch should have `_meta.managed: true`.
This is a flag indicating to the user that these templates are system
managed and should not be manually modified.
**Compare the index templates**
Compare 3 and 6. The differences should be:
* index template from this branch should have `managed: true` in the
`_meta` fields
* index template from this branch should not have a `priority` field.
This will be addressed in a followup PR
* index template from this branch should be composed of
`.alerts-legacy-alert-mappings` and `.alerts-framework-mappings` instead
of `.alerts-technical-mappings` but under the hood, these mappings are
equivalent.
**Compare the index mappings**
Compare 4 and 7. The difference should be:
* index mappings from this branch should have `_meta.managed: true`.
### Verify that installed resources templates work as expected
1. Run this branch on a fresh ES install with
`xpack.alerting.enableFrameworkAlerts: true`.
2. Create a rule in your context that generates alerts.
3. Verify that there are no errors during rule execution.
4. Verify that the alerts show up in your alerts table as expected.
5. (For detection rules only): Run this branch with
`xpack.alerting.enableFrameworkAlerts: true` and verify rules in a
non-default space continue to create resources on first rule run and run
as expected.
6. (For detection rules only): Run this branch with
`xpack.alerting.enableFrameworkAlerts: true` and verify rule preview
continue to work as expected
### Verify that installed resources templates work with existing rule
registry resources.
1. Run `main` or a previous version and create a rule in your context
that generates alerts.
2. Using the same ES data, switch to this branch with
`xpack.alerting.enableFrameworkAlerts: false` and verify Kibana starts
with no rule registry errors and the rule continues to run as expected.
3. Using the same ES data, switch to this branch with
`xpack.alerting.enableFrameworkAlerts: true` and verify Kibana starts
with no alerting or rule registry errors and the rule continues to run
as expected.
4. Verify the alerts show up on the alerts table as expected.
5. (For detection rules only): Run this branch with
`xpack.alerting.enableFrameworkAlerts: true` and verify rules in a
non-default space continue to create resources on first rule run and run
as expected.
6. (For detection rules only): Run this branch with
`xpack.alerting.enableFrameworkAlerts: true` and verify rule preview
continue to work as expected
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Resolves https://github.com/elastic/kibana/issues/150358
## Summary
In a previous [PR](https://github.com/elastic/kibana/pull/145581) we
started installing a common component template for framework alerts as
data when the `xpack.alerting.enableFrameworkAlerts` config flag is set
to true. In that PR we used a different naming pattern than what is used
by the rule registry for its component templates.
In this PR we are doing the following:
* Renaming the installed `alerts-common-component-template` to
`.alerts-framework-mappings`.
* Creating and installing `.alerts-legacy-alert-mappings` component
template when `enableFrameworkAlerts: true` on alerting plugin setup
* The combination of the two component templates creates the same set of
mappings as the rule registry technical component template
* Creating and installing `.alerts-ecs-mappings` component template when
`enableFrameworkAlerts: true` on alerting plugin setup (when
`enableFrameworkAlerts: false`, the rule registry continues to install
this component template
* Using the `@kbn/ecs` package provided by core to generate the ECS
field map. The rule registry will continue to install the existing ECS
field map which is actually a subset of ECS fields
* Adding `useLegacy` and `useEcs` flags that allow rule types to specify
whether to include the legacy alerts component template and the ECS
component template when registering with framework alerts-as-data.
* Moved some common functions to alerting framework from the rule
registry
## Things to note
* When generating the ECS field map, we are now including the
`ignore_above` setting from the `@kbn/ecs` package. This changes the ECS
component template to include those settings. I tested updating an index
with just `"type":"keyword"` mappings to add the `ignore_above` field to
the mapping and had no issues so this seems like an additive change to
the mapping that will hopefully prevent problems in the future.
* The rule registry ECS component template also includes the technical
fields which is redundant because the technical component template is
automatically installed for all index templates so the framework ECS
component template only contains ECS fields.
| Previous mapping | Updated mapping |
| ----------- | ----------- |
| `{ "organization": { "type": "keyword" } }` | `{ "organization": {
"type": "keyword", "ignore_above": 1024 } }` |
## To Verify
### Verify that the generated component templates are as expected:
Get the following
**While running `main`:**
1. Get the ECS component template `GET
_component_template/.alerts-ecs-mappings`
2. Get the technical component template `GET
_component_template/.alerts-technical-mappings`
3. Create a detection rule that creates an alert and then get the index
mapping for the concrete security alert index `GET
.internal.alerts-security.alerts-default-000001/_mapping`
**While running this branch with `xpack.alerting.enableFrameworkAlerts:
false`:**
4. Get the ECS component template `GET
_component_template/.alerts-ecs-mappings`
5. Get the technical component template `GET
_component_template/.alerts-technical-mappings`
6. Create a detection rule that creates an alert and then get the index
mapping for the concrete security alert index `GET
.internal.alerts-security.alerts-default-000001/_mapping`
**While running this branch with `xpack.alerting.enableFrameworkAlerts:
true`:**
7. Get the ECS component template `GET
_component_template/.alerts-ecs-mappings`
8. Get the technical component template `GET
_component_template/.alerts-technical-mappings`
9. Create a detection rule that creates an alert and then get the index
mapping for the concrete security alert index `GET
.internal.alerts-security.alerts-default-000001/_mapping`
10. Verify that component templates exist for
`.alerts-framework-mappings` and `.alerts-legacy-alert-mappings`
**Compare the ECS component templates**
Compare 1 and 4 (ECS component template from `main` and installed by
rule registry in this branch). The difference should be:
* no difference in ECS fields
* because the rule registry ECS component template also includes
technical fields, you will see the 2 new technical fields in this branch
Compare 4 and 7 (ECS component template from rule registry & alerting
framework in this branch).
* some new ECS fields for alerting installed template
* each `keyword` mapped field for alerting installed template should
have `ignore_above` setting
* no `kibana.*` fields in the alerting installed template
**Compare the technical component templates**
Compare 2 and 5 (technical component template from `main` and installed
by rule registry in this branch). The difference should be:
* 2 new `kibana.alert` fields (`flapping_history` and `last_detected`)
Compare 5 and 8 (technical component template from rule registry &
alerting framework in this branch).
* there should be no difference!
**Compare the index mappings**
Compare 3 and 6 (index mapping from `main` and installed by rule
registry in this branch). The difference should be:
* 2 new `kibana.alert` fields (`flapping_history` and `last_detected`)
Compare 6 and 9 (index mapping from rule registry & alerting framework
in this branch).
* some new ECS fields
* each `keyword` mapped ECS field should have `ignore_above` setting
### Verify that the generated component templates work with existing
rule registry index templates & indices:
1. Run `main` or a previous version and create a rule that uses both ECS
component templates & technical component templates (detection rules use
both). Let it run a few times.
2. Using the same ES data, switch to this branch with
`xpack.alerting.enableFrameworkAlerts: false` and verify Kibana starts
with no rule registry errors and the rule continues to run as expected.
3. Using the same ES data, switch to this branch with
`xpack.alerting.enableFrameworkAlerts: true` and verify Kibana starts
with no alerting or rule registry errors and the rule continues to run
as expected. Verify that the mapping on the existing
`.internal.alerts-security.alerts-default-000001` has been updated to
include the latest ECS mappings and the two new technical fields.
### Checklist
Delete any items that are not applicable to this PR.
- [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
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Mike Côté <mikecote@users.noreply.github.com>
Resolves https://github.com/elastic/kibana/issues/150331
## Summary
In a previous [PR](https://github.com/elastic/kibana/pull/145581) we
started installing an ILM policy for framework alerts as data when the
`xpack.alerting.enableFrameworkAlerts` config flag is set to true. In
that PR we used a different name than what is used by the rule registry
even though the policy bodies were the same.
In this PR, we are consolidating the naming of the two ILM policies so
that we are only ever installing 1 policy. The
`xpack.alerting.enableFrameworkAlerts` config is used to determine which
plugin is responsible for installing the policy. When set to true, the
alerting plugin installs the policy. When set the false, the rule
registry installs the policy. This is an incremental step toward the
alerting framework absorbing all of the resource installation
functionality of the rule registry
## To Verify
A few things to verify:
1. Verify that the alerting plugin installs the policy when
`xpack.alerting.enableFrameworkAlerts=true`
* Set `xpack.alerting.enableFrameworkAlerts: true` in your Kibana config
* Start a fresh ES and Kibana instance
* Verify that an ILM policy with name `.alerts-ilm-policy` is installed
* Create a metric threshold rule that creates an alert
* Verify that there is an index template called
`.alerts-observability.metrics.alerts-default-index-template` that uses
the `.alerts-ilm-policy` policy
2. Verify that the rule registry installs the policy when
`xpack.alerting.enableFrameworkAlerts=false`
* Set `xpack.alerting.enableFrameworkAlerts: false` in your Kibana
config
* Start a fresh ES and Kibana instance
* Verify that an ILM policy with name `.alerts-ilm-policy` is installed
* Create a metric threshold rule that creates an alert
* Verify that there is an index template called
`.alerts-observability.metrics.alerts-default-index-template` that uses
the `.alerts-ilm-policy` policy
3. Verify that we can switch between configurations
* Set `xpack.alerting.enableFrameworkAlerts: false` in your Kibana
config
* Start a fresh ES and Kibana instance
* Verify that an ILM policy with name `.alerts-ilm-policy` is installed
* Create a metric threshold rule that creates an alert
* Verify that there is an index template called
`.alerts-observability.metrics.alerts-default-index-template` that uses
the `.alerts-ilm-policy` policy
* Change `xpack.alerting.enableFrameworkAlerts: true`
* Restart Kibana
* Verify there are no errors, and the rule can still write alerts
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Fixes https://github.com/elastic/kibana/issues/149344
This PR migrates all plugins to packages automatically. It does this
using `node scripts/lint_packages` to automatically migrate
`kibana.json` files to `kibana.jsonc` files. By doing this automatically
we can simplify many build and testing procedures to only support
packages, and not both "packages" and "synthetic packages" (basically
pointers to plugins).
The majority of changes are in operations related code, so we'll be
having operations review this before marking it ready for review. The
vast majority of the code owners are simply pinged because we deleted
all `kibana.json` files and replaced them with `kibana.jsonc` files, so
we plan on leaving the PR ready-for-review for about 24 hours before
merging (after feature freeze), assuming we don't have any blockers
(especially from @elastic/kibana-core since there are a few core
specific changes, though the majority were handled in #149370).
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Resolves https://github.com/elastic/kibana/issues/145929
## Summary
Updates previous flapping tests to use the new flapping settings
configs.
Updates flapping logic to use flapping configs instead of hardcoded
values. Calls the flapping api on every rule execution, and then passes
in the flapping settings to the rule executors so they can be used by
the rule registry.
### Checklist
- [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
### To verify
I think it's helpful to hide the whitespace when reviewing this pr.
- The flapping logic should remain the same, and all previous tests
should pass. I only updated them to pass in the flapping settings.
- Create rules, and set flapping settings in the ui and see the flapping
behavior change for your rules.
- Verify that the
`x-pack/test/alerting_api_integration/spaces_only/tests/alerting/event_log.ts`
run with the new flapping configs and output results we would expect
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
This PR upgrades uuid into its latest version `9.0.0`.
The previous default used version `v4` was kept where it was previously
used and places using `v1` or `v5` are still using it.
In this latest version they removed the deep import feature and as we
are not using tree shaking it increased our bundles by a significant
size. As such, I've moved this dependency into the `ui-shared-deps-npm`
bundle.
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
The location of plugins was previously somewhat irrelevant, but as we
move into packages it's more important that we can find all plugins in
the repository, and we would like to be able to do that without needing
to maintain a manifest somewhere to accomplish this. In order to make
this possible we plan to find any plugin/package by spotting all
kibana.json files which are not "fixtures". This allows plugin-like code
(but not actual plugin code) to exist for testing purposes, but it must
be within some form of "fixtures" directory, and any plugin that isn't
in a fixtures directory will be automatically pulled into the system
(though test plugins, examples, etc. will still only be loaded when the
plugin's path is passed via `--plugin-path`, the system will know about
them and use that knowledge for other things).
Since this is just a rename Operations will review and merge by EOD Jan
12th unless someone has a blocking concern.
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
