[8.x] [Security Solution] Allow importing of prebuilt rules via the API (#190198) #196613
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…astic#190198) ## Summary This PR introduces the backend functionality necessary to import prebuilt rules via our existing import API. The [RFC](https://github.com/elastic/kibana/blob/main/x-pack/plugins/security_solution/docs/rfcs/detection_response/prebuilt_rules_customization.md) goes into detail, and the import-specific issue is described [here](elastic#180168), but at a high level we're adding two things in this PR: 1. The logic to calculate the new `rule_source` field on import, which contains the information about the rule's relationship to existing prebuilt rules. 2. A new code path for importing rules, which respects the calculated `rule_source` field. In order to maintain backwards compatibility with the existing import logic, and because the existing import implementation is hard to modify/extend, I opted to add a top-level switch on the feature flag in the import route itself, which calls either the existing import function (now named `importRulesLegacy`), or the new function, `importRules`, which ultimately calls the new `DetectionRulesClient` method, `importRules`. Neither knows about the feature flag, and thanks to great suggestions from @xcrzx there are nice, clean boundaries between the import functions and the client methods. I went down the path of trying to write the new import code by reusing the outer `importRules` function, but after discussion with the team we decided it was simplest to simply bifurcate the code at that point, so that we have: 1. The legacy import code, which: * only supports custom rules (`immutable: false`) * accepts `version` as an optional parameter * calculates a legacy `rule_source` value based on the `immutable` field 2. The new import code, which * Installs the prebuilt rules assets as necessary * Accepts both kinds of rules (`immutable: true/false`) * Requires `version` as a parameter for _prebuilt_ rules * Allows `version` to be optional for custom rules * calculates a proper `rule_source` (and `immutable`) ### Deprecation of `immutable` The RFC (and thus I) had initially thought that we'd be deprecating the `immutable` field as part of this PR/Epic. However, after [discussion](elastic#190198 (comment)) we have opted to continue supporting `immutable` until such time as we can drop it, compatibility-wise. ## Steps to Review 1. Enable the Feature Flag: `prebuiltRulesCustomizationEnabled` 2. Install the prebuilt rules package via fleet 3. Create and export a custom rule to serve as a template (or download one: curl -L -H 'Authorization: 8eef0fe5d7dfc52b' -o 'rules_export (1).ndjson' https://upload.elastic.co/d/4693e7fe4356ce7bcf7b7d6b72881a9fd189730c61bf5ef47c9930458d746979 ) 4. Install some prebuilt rules, and obtain a prebuilt rule's `rule_id`, e.g. `ac8805f6-1e08-406c-962e-3937057fa86f` 5. Edit the `rules_export.ndjson` to contain only the first line, and modify the `rule_id` with the prebuilt rule's 6. Import `rules_export.ndjson` and then retrieve the rule via the Dev Console: GET kbn:api/detection_engine/rules?rule_id=ac8805f6-1e08-406c-962e-3937057fa86f 7. Observe that the rule has the expected `rule_source` and `immutable` values 8. Test other permutations of import by modifying `rules_export.ndjson` and re-importing; see ([the test plan](elastic#191116) as well as a [reference table of scenarios](https://github.com/elastic/kibana/blob/main/x-pack/plugins/security_solution/docs/rfcs/detection_response/prebuilt_rules_customization.md#importing-rules)) ### 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 - [ ] [Flaky Test Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was used on any tests changed --------- Co-authored-by: kibanamachine <[email protected]> Co-authored-by: Georgii Gorbachev <[email protected]> (cherry picked from commit c0b1301)
4 tasks
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Backport
This will backport the following commits from
mainto8.x:Questions ?
Please refer to the Backport tool documentation