Skip to content
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

[8.x] [Security Solution] Allow importing of prebuilt rules via the API (#190198) #196613

Merged
merged 1 commit into from
Oct 16, 2024

Commits on Oct 16, 2024

  1. [Security Solution] Allow importing of prebuilt rules via the API (el…

    …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)
    rylnd committed Oct 16, 2024
    Configuration menu
    Copy the full SHA
    7015873 View commit details
    Browse the repository at this point in the history