-
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
[Security Solution] Prebuilt rule is duplicated during upgrade when its new version has a different rule type #161305
Labels
8.9 candidate
blocker
bug
Fixes for quality problems that affect the customer experience
Feature:Prebuilt Detection Rules
Security Solution Prebuilt Detection Rules area
fixed
impact:critical
This issue should be addressed immediately due to a critical level of impact on the product.
QA:Validated
Issue has been validated by QA
Team:Detection Rule Management
Security Detection Rule Management Team
Team:Detections and Resp
Security Detection Response Team
Team: SecuritySolution
Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc.
v8.9.0
Comments
banderror
added
bug
Fixes for quality problems that affect the customer experience
impact:critical
This issue should be addressed immediately due to a critical level of impact on the product.
Team:Detections and Resp
Security Detection Response Team
Team: SecuritySolution
Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc.
Team:Detection Rule Management
Security Detection Rule Management Team
Feature:Prebuilt Detection Rules
Security Solution Prebuilt Detection Rules area
v8.9.0
labels
Jul 5, 2023
Pinging @elastic/security-detections-response (Team:Detections and Resp) |
Pinging @elastic/security-solution (Team: SecuritySolution) |
1 task
1 task
banderror
changed the title
[Security Solution] Prebuilt rules are duplicated when upgraded one by one
[Security Solution] Prebuilt rule is duplicated during upgrade when its new version has a different rule type
Jul 7, 2023
banderror
pushed a commit
that referenced
this issue
Jul 7, 2023
…t rules (#161331) Fixes: #161305 ## Summary - Passes a new `immutable` params to the `upgradeRule` method that is used when upgrading rules. - Looks like we had a longstanding bug here in which rule updates of rule types that changed the type of the rule were overwriting the `immutable` prop to `false`. (Actually, those rules were deleted and recreated with `immutable: false`) - This was causing the `fetchAllInstalledRules` method of our `ruleObjectsClient` NOT to retrieve these rules when they were already installed. - Since our installation `_review` and `_perform` endpoint depends on this client, these rules that had had their types updated were being incorrectly listed as available for installation. ## Testing Repeat testing steps laid out in: #161305 Rules shouldn't be duplicated. ### For maintainers - [ ] 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)
kibanamachine
pushed a commit
to kibanamachine/kibana
that referenced
this issue
Jul 7, 2023
…t rules (elastic#161331) Fixes: elastic#161305 ## Summary - Passes a new `immutable` params to the `upgradeRule` method that is used when upgrading rules. - Looks like we had a longstanding bug here in which rule updates of rule types that changed the type of the rule were overwriting the `immutable` prop to `false`. (Actually, those rules were deleted and recreated with `immutable: false`) - This was causing the `fetchAllInstalledRules` method of our `ruleObjectsClient` NOT to retrieve these rules when they were already installed. - Since our installation `_review` and `_perform` endpoint depends on this client, these rules that had had their types updated were being incorrectly listed as available for installation. ## Testing Repeat testing steps laid out in: elastic#161305 Rules shouldn't be duplicated. ### For maintainers - [ ] 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) (cherry picked from commit 61fa0f5)
kibanamachine
added a commit
that referenced
this issue
Jul 7, 2023
…rebuilt rules (#161331) (#161455) # Backport This will backport the following commits from `main` to `8.9`: - [[Security Solution] Set immutable param to true when updating prebuilt rules (#161331)](#161331) <!--- Backport version: 8.9.7 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport) <!--BACKPORT [{"author":{"name":"Juan Pablo Djeredjian","email":"jpdjeredjian@gmail.com"},"sourceCommit":{"committedDate":"2023-07-07T12:06:28Z","message":"[Security Solution] Set immutable param to true when updating prebuilt rules (#161331)\n\nFixes: https://github.com/elastic/kibana/issues/161305\r\n\r\n## Summary\r\n\r\n- Passes a new `immutable` params to the `upgradeRule` method that is\r\nused when upgrading rules.\r\n- Looks like we had a longstanding bug here in which rule updates of\r\nrule types that changed the type of the rule were overwriting the\r\n`immutable` prop to `false`. (Actually, those rules were deleted and\r\nrecreated with `immutable: false`)\r\n- This was causing the `fetchAllInstalledRules` method of our\r\n`ruleObjectsClient` NOT to retrieve these rules when they were already\r\ninstalled.\r\n- Since our installation `_review` and `_perform` endpoint depends on\r\nthis client, these rules that had had their types updated were being\r\nincorrectly listed as available for installation.\r\n\r\n## Testing\r\n\r\nRepeat testing steps laid out in:\r\nhttps://github.com//issues/161305\r\n\r\nRules shouldn't be duplicated.\r\n\r\n\r\n### For maintainers\r\n\r\n- [ ] This was checked for breaking API changes and was [labeled\r\nappropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)","sha":"61fa0f543e84c8e89b0351a82652123d0895a818","branchLabelMapping":{"^v8.10.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["bug","blocker","release_note:skip","impact:critical","Team:Detections and Resp","Team: SecuritySolution","Team:Detection Rule Management","Feature:Prebuilt Detection Rules","v8.9.0","v8.10.0"],"number":161331,"url":"https://github.com/elastic/kibana/pull/161331","mergeCommit":{"message":"[Security Solution] Set immutable param to true when updating prebuilt rules (#161331)\n\nFixes: https://github.com/elastic/kibana/issues/161305\r\n\r\n## Summary\r\n\r\n- Passes a new `immutable` params to the `upgradeRule` method that is\r\nused when upgrading rules.\r\n- Looks like we had a longstanding bug here in which rule updates of\r\nrule types that changed the type of the rule were overwriting the\r\n`immutable` prop to `false`. (Actually, those rules were deleted and\r\nrecreated with `immutable: false`)\r\n- This was causing the `fetchAllInstalledRules` method of our\r\n`ruleObjectsClient` NOT to retrieve these rules when they were already\r\ninstalled.\r\n- Since our installation `_review` and `_perform` endpoint depends on\r\nthis client, these rules that had had their types updated were being\r\nincorrectly listed as available for installation.\r\n\r\n## Testing\r\n\r\nRepeat testing steps laid out in:\r\nhttps://github.com//issues/161305\r\n\r\nRules shouldn't be duplicated.\r\n\r\n\r\n### For maintainers\r\n\r\n- [ ] This was checked for breaking API changes and was [labeled\r\nappropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)","sha":"61fa0f543e84c8e89b0351a82652123d0895a818"}},"sourceBranch":"main","suggestedTargetBranches":["8.9"],"targetPullRequestStates":[{"branch":"8.9","label":"v8.9.0","labelRegex":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"main","label":"v8.10.0","labelRegex":"^v8.10.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/161331","number":161331,"mergeCommit":{"message":"[Security Solution] Set immutable param to true when updating prebuilt rules (#161331)\n\nFixes: https://github.com/elastic/kibana/issues/161305\r\n\r\n## Summary\r\n\r\n- Passes a new `immutable` params to the `upgradeRule` method that is\r\nused when upgrading rules.\r\n- Looks like we had a longstanding bug here in which rule updates of\r\nrule types that changed the type of the rule were overwriting the\r\n`immutable` prop to `false`. (Actually, those rules were deleted and\r\nrecreated with `immutable: false`)\r\n- This was causing the `fetchAllInstalledRules` method of our\r\n`ruleObjectsClient` NOT to retrieve these rules when they were already\r\ninstalled.\r\n- Since our installation `_review` and `_perform` endpoint depends on\r\nthis client, these rules that had had their types updated were being\r\nincorrectly listed as available for installation.\r\n\r\n## Testing\r\n\r\nRepeat testing steps laid out in:\r\nhttps://github.com//issues/161305\r\n\r\nRules shouldn't be duplicated.\r\n\r\n\r\n### For maintainers\r\n\r\n- [ ] This was checked for breaking API changes and was [labeled\r\nappropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)","sha":"61fa0f543e84c8e89b0351a82652123d0895a818"}}]}] BACKPORT--> Co-authored-by: Juan Pablo Djeredjian <jpdjeredjian@gmail.com>
Bug fixed and validated for 8.9 BC4. Upgraded prebuilt rules from version 8.3.3 to 8.9.2 REC-20230718192721.mp4 |
@vgomez-el can we close this ticket or is there any testing missing? Thanks! :) |
sorry @MadameSheema, I forgot to close it. Everything was ok. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
8.9 candidate
blocker
bug
Fixes for quality problems that affect the customer experience
Feature:Prebuilt Detection Rules
Security Solution Prebuilt Detection Rules area
fixed
impact:critical
This issue should be addressed immediately due to a critical level of impact on the product.
QA:Validated
Issue has been validated by QA
Team:Detection Rule Management
Security Detection Rule Management Team
Team:Detections and Resp
Security Detection Response Team
Team: SecuritySolution
Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc.
v8.9.0
🚨🚨🚨 This is a blocker for the
8.9.0
release 🚨🚨🚨Related to: #161247 (comment)
Summary
When you have an installed prebuilt rule that can be upgraded, if Elastic has changed its type and in the new version it has a different rule type, then during the upgrade it will be duplicated -- instead of having 1 upgraded instance you will get 2 upgraded instances of the same rule.
Steps to reproduce
xpack.securitySolution.prebuiltRulesPackageVersion: '8.3.1'
and with empty ES data.8.3.1
package version is installed in Integrations.xpack.securitySolution.prebuiltRulesPackageVersion
setting.8.9.1
package version is installed in Integrations.8.9.1
compared to8.3.1
.Actual behavior: The 4 rules I was upgrading one by one became duplicated. Each of the 2 duplicates has the same signature
rule_id
, but different objectid
s. The other rules were upgraded correctly without creating duplicates.Expected behavior: Rules should not be duplicated during an upgrade, regardless of the way you upgrade them: one by one, a few of them in bulk, all of them in bulk.
Screenshots
Data
I was able to verify that only the 4 rules I was upgrading one by one have been duplicated:
The text was updated successfully, but these errors were encountered: