-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RAM][Security Solution][Alerts] moves legacy actions migration to rulesClient #153101
[RAM][Security Solution][Alerts] moves legacy actions migration to rulesClient #153101
Conversation
…ithub.com/vitaliidm/kibana into alerts/legacy-actions-migration-to-alerting # Conflicts: # x-pack/plugins/security_solution/server/lib/detection_engine/rule_actions_legacy/logic/rule_actions/legacy_rules_client_migration_hook.ts
…ithub.com/vitaliidm/kibana into alerts/legacy-actions-migration-to-alerting
…ithub.com/vitaliidm/kibana into alerts/legacy-actions-migration-to-alerting
…ithub.com/vitaliidm/kibana into alerts/legacy-actions-migration-to-alerting
…ithub.com/vitaliidm/kibana into alerts/legacy-actions-migration-to-alerting
|
* @param params | ||
* @returns | ||
*/ | ||
export const migrateLegacyActions: MigrateLegacyActions = async ( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we add a try/catch here and log the error to not block the main method? what do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
added
{} | ||
); | ||
|
||
if (isEmpty(actionReference)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we need to throw an error, maybe we can just ignore it and return empty array?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
added try/catch in formatLegacyActions
and migrateLegacyActions
on top level. So any thrown errors will be caught and logged
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please make sure, to mute any errors during migration/formatting, so we do not block our user form the main method that they wanted to do.
Also I tested it locally and running and everything is working as expected and I did not see any re-generation of API key.
const actionSavedObjects = results.flat().flatMap((r) => r.saved_objects); | ||
|
||
if (errors.length) { | ||
throw new AggregateError(errors, 'Error fetching rule actions'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let's mute the error, we should log it for sure!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
added try/catch in formatLegacyActions
and migrateLegacyActions
on top level. So any thrown errors will be caught and logged
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Codeowners for security-solution-platform LGTM. I haven't gotten to test all the cases on my local yet, but do not want to block this as I know other PR's are waiting on this part to go in.
I saw we do increment the rule version - is that also true for migration on a read? Would that appear strange to the user that on a read, their rule appears to have been modified? (I know technically it was, but they won't necessarily know why or in what way).
@yctercero
In current implementation in Security Solution, when user updates rule, we do 2 updates under the hood:
So, in legacy actions migration case revision is getting incremented by 2. Here is a PR, when revision increment was introduced: #147398 But since, migration is moved to rulesClient, we perform only single update. So, revision will be incremented by |
💛 Build succeeded, but was flaky
Failed CI StepsTest Failures
Metrics [docs]Unknown metric groupsESLint disabled line counts
References to deprecated APIs
Total ESLint disabled count
History
To update your PR or re-run it, just comment with: cc @vitaliidm |
…ecurity solution rule page (#154990) ## Summary [Main ticket](#151916) This PR dependant on [these changes](#153101) These changes cover next two tickets: - [RAM][SECURITYSOLUTION][ALERTS] - Integrate per-action frequency field in security solution APIs #154532 - [RAM][SECURITYSOLUTION][ALERTS] - Integrate per-action frequency UI in security solution #154534 With this PR we will integrate per-action `frequency` field which already works within alert framework and will update security solution UI to incorporate the possibility to select "summary" vs "for each alert" type of actions. ![](https://user-images.githubusercontent.com/616158/227377473-f34a330e-81ce-42b4-af1b-e6e302c6319d.png) ## NOTES: - There will be no more "Perform no actions" option which mutes all the actions of the rule. For back compatibility, we need to show that rule is muted in the UI cc @peluja1012 @ARWNightingale - The ability to generate per-alert action will be done as part of #153611 ## Technical Notes: Here are the overview of the conversions and transformations that we are going to do as part of these changes for devs who are going to review. On rule **create**/**read**/**update**/**patch**: - We always gonna set rule level `throttle` to `undefined` from now on - If each action has `frequency` attribute set, then we just use those values - If actions do not have `frequency` attribute set (or for some reason there is a mix of actions with some of them having `frequency` attribute and some not), then we transform rule level `throttle` into `frequency` and set it for each action in the rule On rule **bulk editing**: - We always gonna set rule level `throttle` to `undefined` - If each action has `frequency` attribute set, then we just use those values - If actions do not have `frequency` attribute set, then we transform rule level `throttle` into `frequency` and set it for each action in the rule - If user passed only `throttle` attribute with empty actions (`actions = []`), this will only remove all actions from the rule This will bring breaking changes which we agreed on with the Advanced Correlation Group cc @XavierM @vitaliidm @peluja1012 ### Checklist Delete any items that are not applicable to this PR. - [x] Any text added follows [EUI's writing guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses sentence case text and includes [i18n support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md) - [ ] [Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html) was added for features that require explanation or tutorials - [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 <[email protected]> Co-authored-by: Maxim Palenov <[email protected]>
Summary
frequency
object, that would allow to have notifyWhen/throttle on action level once META - [RAM][SECURITYSOLUTION][ALERTS] - Integrate Alert summary inside of security solution rule page #151916 is implemented, which is targeted in 8.8, right after this PR.But before it's merged,
frequency
is getting removed in update/bulk_edit/create APIs. Hence it's not reflected in most of the tests at this point.Changes in behaviour, introduced in this PR:
since, migration happens within single rulesClient API call, revision in migrated rule will increment by
1
only.legacy actions from sidecar SO, now will be merged with rules actions, if there any.
Before, in the previous implementation, there was inconsistency in a way how legacy and rules actions were treated.
On read: actions existing in rule, would take precedence over legacy ones
On migration: SO actions only saved. If any actions present in rule, they will be lost. Here is an example video from main branch
Here is an example video from MAIN branch, where action in rule is overwritten by legacy action
Screen.Recording.2023-04-06.at.14.45.12.mov
So, depends on sequence of events, different actions could be saved for identical use case: rule has both legacy and existing action.
In this implementation, both existing in rule and legacy actions will be merged, to prevent loss of actions
Here is an example video from this PR branch, where actions are merged
Screen.Recording.2023-04-06.at.15.18.00.mov
when duplicating rule, we don't migrate source rule anymore. It can lead to unwanted API key regeneration, with possible loss of privileges, earlier associated with the source rule. As part of UX, when duplicating any entity, users would not be expecting source entity to be changed
TODO:
Relevant ticket is [Security Solution][Alerts] after legacy actions migration, triggered through enable/disable API, actions disappear from UI #154567
I haven't fixed it in this PR, as in the next one , we will display notifyWhen/throttle on action level in UI, rather than on rule level. So, once that PR is merged, actions should be displayed in new UI
Checklist
Delete any items that are not applicable to this PR.
For maintainers