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

[Security Solution] Enable prebuilt rules customization feature flag #212761

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

maximpn
Copy link
Contributor

@maximpn maximpn commented Feb 28, 2025

Addresses: #180267

Summary

This PR enables prebuiltRulesCustomizationEnabled feature flag.

Details

Besides simply enabling prebuiltRulesCustomizationEnabled feature flag the following required changes were done

  • failed tests due enabling the FF were fixed
  • FF setting was removed from test configurations (integrations and Cypress tests)
  • FF logic was removed from the codebase. Disabling the FF would require roll back test changes as well. So just in case we have to disable the FF it's simpler to roll back the PR's commit.

@maximpn maximpn added release_note:skip Skip the PR/issue when compiling release notes impact:high Addressing this issue will have a high level of impact on the quality/strength of our product. v9.0.0 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 backport:version Backport to applied version labels v8.18.0 v9.1.0 v8.19.0 labels Feb 28, 2025
@maximpn maximpn self-assigned this Feb 28, 2025
@maximpn maximpn force-pushed the enable-prebuilt-rules-customization-ff branch 7 times, most recently from 100afa4 to 86db5ac Compare March 5, 2025 09:33
@maximpn maximpn marked this pull request as ready for review March 5, 2025 11:38
@maximpn maximpn requested review from a team as code owners March 5, 2025 11:38
@maximpn maximpn requested a review from jkelas March 5, 2025 11:38
@elasticmachine
Copy link
Contributor

Pinging @elastic/security-detections-response (Team:Detections and Resp)

@elasticmachine
Copy link
Contributor

Pinging @elastic/security-solution (Team: SecuritySolution)

@elasticmachine
Copy link
Contributor

Pinging @elastic/security-detection-rule-management (Team:Detection Rule Management)

@maximpn maximpn requested review from xcrzx and banderror and removed request for jkelas March 5, 2025 11:38
Copy link
Member

@jbudz jbudz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ftr_configs.yml LGTM

Copy link
Contributor

@banderror banderror left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@maximpn Thank you, I guess that was quite an effort.

Overall LGTM, but I'm not sure I understand the approach with removing the FF checks from the code but keeping the FF itself. I'd suggest we remove the FF from x-pack/solutions/security/plugins/security_solution/common/experimental_features.ts as well to make sure there's no leftover logic that depends on it.

I left some comments but I don't think any of them are critical. Will be happy to approve the PR when you respond to them.

Comment on lines 188 to 193
* Turned: 12 March 2025 in https://github.com/elastic/kibana/pull/212761
*
* Enabling the FF required fixing some tests.
* To disable revert merge commit by https://github.com/elastic/kibana/pull/212761.
*/
prebuiltRulesCustomizationEnabled: false,
prebuiltRulesCustomizationEnabled: true,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we say that in order to disable the feature back we have to revert the commit instead of just flipping the feature flag to false, why are we keeping the feature flag in the codebase? Can we remove it right away in this PR?

IMHO keeping it in the code overcomplicates the setup. There's a FF, but it's not respected anymore, according to the PR description: "FF logic was removed from the codebase". Or is it? One has to check the code to be sure. This could be confusing for future us or someone else who'd find this flag.

// We show the upselling message only if the feature flag is enabled
const isFeatureFlagEnabled = useIsExperimentalFeatureEnabled('prebuiltRulesCustomizationEnabled');
return isFeatureFlagEnabled ? upsellingMessage : undefined;
return useUpsellingMessage(messageId);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment on lines +25 to +28
const isRulesCustomizationEnabled = !upsellingMessage;
const customizationDisabledReason = isRulesCustomizationEnabled
? undefined
: PrebuiltRulesCustomizationDisabledReason.License;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment on lines +92 to +101
const prebuiltRule = getRuleMock(
getQueryRuleParams({
ruleId: 'rule-1',
immutable: true,
ruleSource: {
type: 'external',
isCustomized: false,
},
})
);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: Maybe we could specify a mixture of non-customized, customized, and even custom rules here. Or have separate unit tests for these cases.

Nit because the main tests for this should be at the integration level.

@@ -53,7 +53,7 @@ describe('DetectionRulesClient.createCustomRule', () => {
mlAuthz,
savedObjectsClient,
license: licenseMock.createLicenseMock(),
experimentalFeatures: { prebuiltRulesCustomizationEnabled: true } as ExperimentalFeatures,
experimentalFeatures: {} as ExperimentalFeatures,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Detection rules client doesn't depend on experimentalFeatures anymore, so this could be removed completely if we remove the experimentalFeatures parameter from the createDetectionRulesClient function.

@@ -1525,7 +1525,7 @@ export default ({ getService }: FtrProviderContext): void => {
},
];
cases.forEach(({ type, value }) => {
it(`should return error when trying to apply "${type}" edit action to prebuilt rule`, async () => {
it(`should NOT return error when trying to apply "${type}" edit action to prebuilt rule`, async () => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this test should be moved outside of this file and be split into two tests:

  • The first one would be created in x-pack/test/security_solution_api_integration/test_suites/detections_response/rules_management/prebuilt_rules/prebuilt_rule_customization/customization_disabled/customization_via_bulk_editing.ts and would test that it should return error when trying to apply "${type}" edit action to prebuilt rule.
  • The second one would be created in x-pack/test/security_solution_api_integration/test_suites/detections_response/rules_management/prebuilt_rules/prebuilt_rule_customization/customization_enabled/customization_via_bulk_editing.ts and would test that it should NOT return error when trying to apply "${type}" edit action to prebuilt rule.


// if rule action is applied together with another edit action, that can't be applied to prebuilt rule (for example: tags action)
// bulk edit request should return error
it(`should return error if one of edit action is not eligible for prebuilt rule`, async () => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similarly, this should go to x-pack/test/security_solution_api_integration/test_suites/detections_response/rules_management/prebuilt_rules/prebuilt_rule_customization/customization_disabled/customization_via_bulk_editing.ts.

@@ -201,47 +201,29 @@ export default ({ getService }: FtrProviderContext): void => {
expect(ruleBody.tags).toEqual(tags);
});

it('should validate immutable rule edit', async () => {
it('should allow prebuilt rules edit', async () => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similarly, this should be moved to x-pack/test/security_solution_api_integration/test_suites/detections_response/rules_management/prebuilt_rules/prebuilt_rule_customization/customization_enabled/customization_via_bulk_editing.ts.

@@ -1625,7 +1625,7 @@ export default ({ getService }: FtrProviderContext): void => {

describe('supporting prebuilt rule customization', () => {
describe('compatibility with prebuilt rule fields', () => {
it('rejects rules with "immutable: true" when the feature flag is disabled', async () => {
it('accepts rules with "immutable: true"', async () => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The whole describe('supporting prebuilt rule customization' should be moved under x-pack/test/security_solution_api_integration/test_suites/detections_response/rules_management/prebuilt_rules/prebuilt_rule_customization/customization_enabled.

@maximpn maximpn force-pushed the enable-prebuilt-rules-customization-ff branch from 86db5ac to be648a4 Compare March 7, 2025 15:17
@maximpn maximpn force-pushed the enable-prebuilt-rules-customization-ff branch from be648a4 to afd314e Compare March 8, 2025 07:13
@maximpn
Copy link
Contributor Author

maximpn commented Mar 8, 2025

/ci

@elasticmachine
Copy link
Contributor

elasticmachine commented Mar 8, 2025

💔 Build Failed

Failed CI Steps

Test Failures

  • [job] [logs] FTR Configs #59 / Rules Management - Prebuilt rule export @ess @serverless @skipInServerlessMKI Prebuilt rule export - feature disabled Export API - doesn't export prebuilt rules when the feature is disabled
  • [job] [logs] FTR Configs #69 / Rules Management - Prebuilt rule export @ess @serverless @skipInServerlessMKI Prebuilt rule export - feature disabled Export API - doesn't export prebuilt rules when the feature is disabled
  • [job] [logs] FTR Configs #59 / Rules Management - Prebuilt rule export @ess @serverless @skipInServerlessMKI Prebuilt rule export - feature disabled Export API - doesn't export prebuilt rules when the feature is disabled
  • [job] [logs] FTR Configs #69 / Rules Management - Prebuilt rule export @ess @serverless @skipInServerlessMKI Prebuilt rule export - feature disabled Export API - doesn't export prebuilt rules when the feature is disabled
  • [job] [logs] FTR Configs #99 / Rules Management - Rule Import API - Customized prebuilt rules @ess @serverless @skipInServerlessMKI Prebuilt rule import does NOT import customized prebuilt rules when rule customization is disabled
  • [job] [logs] FTR Configs #99 / Rules Management - Rule Import API - Customized prebuilt rules @ess @serverless @skipInServerlessMKI Prebuilt rule import does NOT import customized prebuilt rules when rule customization is disabled
  • [job] [logs] FTR Configs #89 / Rules Management - Rule Import API - Non-customized prebuilt rules @ess @serverless @skipInServerlessMKI Prebuilt rule import does NOT allow importing non-customized prebuilt rules
  • [job] [logs] FTR Configs #101 / Rules Management - Rule Import API - Non-customized prebuilt rules @ess @serverless @skipInServerlessMKI Prebuilt rule import does NOT allow importing non-customized prebuilt rules
  • [job] [logs] FTR Configs #89 / Rules Management - Rule Import API - Non-customized prebuilt rules @ess @serverless @skipInServerlessMKI Prebuilt rule import does NOT allow importing non-customized prebuilt rules
  • [job] [logs] FTR Configs #101 / Rules Management - Rule Import API - Non-customized prebuilt rules @ess @serverless @skipInServerlessMKI Prebuilt rule import does NOT allow importing non-customized prebuilt rules

Metrics [docs]

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id before after diff
securitySolution 8.9MB 8.9MB -677.0B

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id before after diff
securitySolution 87.5KB 87.5KB -37.0B
Unknown metric groups

ESLint disabled line counts

id before after diff
securitySolution 578 576 -2

Total ESLint disabled count

id before after diff
securitySolution 661 659 -2

History

cc @maximpn

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport:version Backport to applied version labels Feature:Prebuilt Detection Rules Security Solution Prebuilt Detection Rules area impact:high Addressing this issue will have a high level of impact on the quality/strength of our product. release_note:skip Skip the PR/issue when compiling release notes 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.18.0 v8.19.0 v9.0.0 v9.1.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants