[Cases] Case action: Registration and Oracle#168370
[Cases] Case action: Registration and Oracle#168370cnasikas merged 23 commits intoelastic:case_actionfrom
Conversation
…o register_case_action
| "dynamic": false, | ||
| "properties": {} | ||
| }, | ||
| "cases-oracle": { |
There was a problem hiding this comment.
This is a new saved object type that we will use for the case action. This PR will be merged on a feature branch and the definition may change as we develop.
There was a problem hiding this comment.
Aren't we already sure the grouping_definition should be included?
There was a problem hiding this comment.
We will not index the grouping_definition so it will not be included in the mapping.
|
Pinging @elastic/response-ops (Team:ResponseOps) |
|
Pinging @elastic/response-ops-cases (Feature:Cases) |
adcoelho
left a comment
There was a problem hiding this comment.
LGTM I am just not familiar with the SubActionConnectors
| owner, | ||
| this.cryptoService.stringifyDeterministically(grouping), | ||
| ] | ||
| .filter(Boolean) |
| const spaceId = 'default'; | ||
| const owner = 'cases'; | ||
| const grouping = { 'host.ip': '0.0.0.1', 'agent.id': '8a4f500d' }; | ||
| const sortedGrouping = { 'agent.id': '8a4f500d', 'host.ip': '0.0.0.1' }; |
There was a problem hiding this comment.
Where is this done in the implementation?
There was a problem hiding this comment.
Here https://github.com/elastic/kibana/pull/168370/files/c210a0c9cefc167ac1c1339757ec8494729abb4e#diff-6d91ad0215d2086dc33208df409ca2e693725d41e076a04b4bee371b36cfabf6R24. json-stable-stringify always return a sorted version of the object. We need the order to be the same to produce the same hash for the same grouping no matter how the object is defined (order is not guaranteed by JS neither we should care in the application level).
| const spaceId = 'default'; | ||
| const owner = 'cases'; | ||
|
|
||
| // @ts-expect-error: ruleId and grouping are omitted for testing |
There was a problem hiding this comment.
Does ExclusiveUnion<OracleKeyWithOptionalKey, OracleKeyWithOptionalGrouping>; guarantee that either can be null but not both?
There was a problem hiding this comment.
This is correct. As we throw an error either way I added a test to check it.
| constructor(params: ServiceParams<CasesConnectorConfig, CasesConnectorSecrets>) { | ||
| super(params); | ||
|
|
||
| this.registerSubActions(); |
There was a problem hiding this comment.
Where do i find more about what this and SubActionConnector are for?
There was a problem hiding this comment.
|
|
||
| public async increaseCounter(recordId: string): Promise<OracleRecord> { | ||
| const { id: _, version, ...record } = await this.getRecord(recordId); | ||
| const newCounter = record.counter + 1; |
There was a problem hiding this comment.
will there be no hard limit for the counter? We will put a limit on the number of total cases that can be created on an execution but what about total cases?
There was a problem hiding this comment.
This service is responsible for interacting with the cases-oracle saved object. It is the consumer's responsibility to impose any limits before updating the counter.
| type: 'date', | ||
| }, | ||
| /* | ||
| grouping: { |
There was a problem hiding this comment.
Should this still be commented out?
There was a problem hiding this comment.
No, we do not want to index the grouping at the moment. No plans to query the oracle about grouping. The other data are needed for telemetry purposes. They are not actually needed by the connector. It may change as we develop though.
| "dynamic": false, | ||
| "properties": {} | ||
| }, | ||
| "cases-oracle": { |
There was a problem hiding this comment.
Aren't we already sure the grouping_definition should be included?
💔 Build FailedFailed CI StepsTest Failures
Metrics [docs]
History
To update your PR or re-run it, just comment with: cc @cnasikas |
## Summary This PR is a continuation of the work for the Case action. This PR implements the basic logic of the case connector. Specifically: 1. Group the alerts based on the grouping provided by the user 2. Create the Oracle's SO IDs to fetch the records. If they do not exist they will get created and the counter will be set to 1. 3. Create the cases' SO IDs to fetch the Cases. If they do not exist they will get created. 4. Attach the alerts to the corresponding cases. Not in this PR: - Handle errors - Retries on errors - Reopen cases - Time window - Race conditions - Circuit breakers Depends on: #168370, #169484 ### 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) --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary Depends on: #166267, #170326, #169484, #173740, #173763, #178068, #178307, #178600, #180437 PRs: - #168370 - #169229 - #171754 - #172709 - #173012 - #175107 - #175452 - #175505 - #177033 - #178277 - #177139 - #179796 Fixes: #153837 ## Testing Run Kibana with `--run-examples` if you want to use the "Always firing" rule. Create a rule with a case action in observability and the stack. The security solution is not supported. You should not be able to assign a case action in a security solution rule. 1. Test the "Reopen closed cases" configuration. 2. Test the "Grouping by" configuration. Only one field is allowed. Not all fields are persisted in alerts. If you select a field not part of the alert the case action will create a case where the grouping value is set to `unknow`. 3. Test the "Time window" feature. You can comment out the validation to test for shorter times. 4. Verify that the case action is experimental. 5. Verify that based on the rule type the case is created in the correct solution. 6. Verify that you cannot create a rule with the case action on the basic license. 7. Verify that the execution of the case action fails if you do not have permission for cases. Pending work on the system actions framework level to not allow users to create rules with system actions where they do not have permission. 8. Stress test the case action by creating multiple rules. ### Checklist Delete any items that are not applicable to this PR. - [x] [Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html) was added for features that require explanation or tutorials - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios ### 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 Automatically create cases when an alert is triggered. --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: adcoelho <antonio.coelho@elastic.co> Co-authored-by: Janki Salvi <117571355+js-jankisalvi@users.noreply.github.com>
Summary
This PR is the first of many that will follow for the case connector (automatically create cases when firing a rule). The PR will be merged on a feature branch. Please refer to the Case Action RFC for further details. In this PR:
CasesOracleServiceto interact with the Cases Oracle SOCryptoServiceto do cryptographic operationsChecklist
Delete any items that are not applicable to this PR.
For maintainers