ad01057f90
## Summary Removes the "side car" actions object and side car notification (Part 1). Part 1 makes it so that newly created rules and editing existing rules will update them to using the new side car notifications. Part 2 in a follow up PR will be the migrations to move the existing data. The saved object side we are removing usages of is: ``` siem-detection-engine-rule-actions ``` The alerting side car notification system we are removing is: ``` siem.notifications ``` * Removes the notification files and types * Adds transform to and from alerting concepts of `notityWhen` and our `throttle` * Adds unit tests for utilities and pure functions created * Updates unit tests to have more needed jest mock * Adds business rules and logic for the different states of `notifyWhen`, and `throttle` on each of the REST routes to determine when we should `muteAll` vs. not muting using secondary API call from client alerting * Adds e2e tests for the throttle conditions and how they are to interact with the kibana-alerting `throttle` and `notifyWhen` A behavioral change under the hood is that we now support the state changes of `muteAll` from the UI/UX of [stack management](https://www.elastic.co/guide/en/kibana/master/create-and-manage-rules.html#controlling-rules). Whenever the `security_solution` ["Perform no actions"](https://www.elastic.co/guide/en/security/current/rules-api-create.html ) is selected we do a `muteAll`. However, we do not change the state if all individual actions are muted within the rule. Instead we only maintain the state of `muteAll`: <img width="2299" alt="ui_state_change" src="https://user-images.githubusercontent.com/1151048/130823045-48a9f34b-db23-44e3-b9ed-cbbb57edc3d6.png"> <img width="1163" alt="no_actions_state_change" src="https://user-images.githubusercontent.com/1151048/130823056-3f8953fa-9433-4973-a2d3-6e11263b9619.png"> Ref: * Issue and PR where notifyWhen was added to kibna-alerting * https://github.com/elastic/kibana/pull/82969 * https://github.com/elastic/kibana/issues/50077 ### 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 |
||
|---|---|---|
| .. | ||
| .storybook | ||
| common | ||
| cypress | ||
| public | ||
| scripts | ||
| server | ||
| jest.config.js | ||
| kibana.json | ||
| package.json | ||
| README.md | ||
| tsconfig.json | ||
Security Solution
Welcome to the Kibana Security Solution plugin! This README will go over getting started with development and testing.
Development
Tests
The endpoint specific tests leverage the ingest manager to install the endpoint package. Before the api integration and functional tests are run the ingest manager is initialized. This initialization process includes reaching out to a package registry service to install the endpoint package. The endpoint tests support three different ways to run the tests given the constraint on an available package registry.
- Using Docker
- Running your own local package registry
- Using the default external package registry
These scenarios will be outlined the sections below.
Endpoint API Integration Tests Location
The endpoint api integration tests are located here
Endpoint Functional Tests Location
The endpoint functional tests are located here
Using Docker
To run the tests using the recommended docker image version you must have docker installed. The testing infrastructure
will stand up a docker container using the image defined here
Make sure you're in the Kibana root directory.
Endpoint API Integration Tests
In one terminal, run:
FLEET_PACKAGE_REGISTRY_PORT=12345 yarn test:ftr:server --config x-pack/test/security_solution_endpoint_api_int/config.ts
In another terminal, run:
FLEET_PACKAGE_REGISTRY_PORT=12345 yarn test:ftr:runner --config x-pack/test/security_solution_endpoint_api_int/config.ts
Endpoint Functional Tests
In one terminal, run:
FLEET_PACKAGE_REGISTRY_PORT=12345 yarn test:ftr:server --config x-pack/test/security_solution_endpoint/config.ts
In another terminal, run:
FLEET_PACKAGE_REGISTRY_PORT=12345 yarn test:ftr:runner --config x-pack/test/security_solution_endpoint/config.ts
Running your own package registry
If you are doing endpoint package development it will be useful to run your own package registry to serve the latest package you're building. To do this use the following commands:
Make sure you're in the Kibana root directory.
Endpoint API Integration Tests
In one terminal, run:
PACKAGE_REGISTRY_URL_OVERRIDE=<url to your package registry like http://localhost:8080> yarn test:ftr:server --config x-pack/test/security_solution_endpoint_api_int/config.ts
In another terminal, run:
PACKAGE_REGISTRY_URL_OVERRIDE=<url to your package registry like http://localhost:8080> yarn test:ftr:runner --config x-pack/test/security_solution_endpoint_api_int/config.ts
Endpoint Functional Tests
In one terminal, run:
PACKAGE_REGISTRY_URL_OVERRIDE=<url to your package registry like http://localhost:8080> yarn test:ftr:server --config x-pack/test/security_solution_endpoint/config.ts
In another terminal, run:
PACKAGE_REGISTRY_URL_OVERRIDE=<url to your package registry like http://localhost:8080> yarn test:ftr:runner --config x-pack/test/security_solution_endpoint/config.ts
Using the default public registry
If you don't have docker installed and don't want to run your own registry, you can run the tests using the ingest manager's default public package registry. The actual package registry used is here
Make sure you're in the Kibana root directory.
Endpoint API Integration Tests
In one terminal, run:
yarn test:ftr:server --config x-pack/test/security_solution_endpoint_api_int/config.ts
In another terminal, run:
yarn test:ftr:runner --config x-pack/test/security_solution_endpoint_api_int/config.ts
Endpoint Functional Tests
In one terminal, run:
yarn test:ftr:server --config x-pack/test/security_solution_endpoint/config.ts
In another terminal, run:
yarn test:ftr:runner --config x-pack/test/security_solution_endpoint/config.ts