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] Adds Cypress test for index action in detection rules #141069

Merged
merged 25 commits into from
Sep 29, 2022

Conversation

MadameSheema
Copy link
Member

@MadameSheema MadameSheema commented Sep 20, 2022

Summary

In this PR we are adding a test to validate that an index action can be added during the rule creation and that the action is properly triggered.

In order to do that, we have extended the object/connectors.ts file creating a new interface, called IndexConnector, which contains all the information needed to create an index connector. We have also created the Connectors type that would be used when creating a rule with actions.

In this test we are creating the rule from the UI to include also the creation of the action. The main focus of the test is to check that the action works correctly, that is why we don’t need a rule with all the fields, we just need a rule with the mandatory field needed on the UI to make also the test execution faster.

To be able to have a rule with just the UI mandatory fields, we have refactored the CustomRule interface to make optional some of the current fields, forcing us to refactor also the methods where some of those fields are used. A part from the refactor, we have extended the interface, with the Actions field.

The new test performs the following actions:



  1. Clean any possible data that may impact our test on the before hooks.

  2. Creates an index we will need to have in elastic search to be able to create the index action.
  3. Creates a custom rule with an index action
  4. Once the rule is executed checks that the document with the expected JSON has been correctly indexed.

@MadameSheema
Copy link
Member Author

@elasticmachine merge upstream

@MadameSheema
Copy link
Member Author

@elasticmachine merge upstream

@MadameSheema MadameSheema changed the title adds rule actions spec file [Security Solution] Adds Cypress test for index action in detection rules Sep 26, 2022
@MadameSheema MadameSheema self-assigned this Sep 26, 2022
@MadameSheema MadameSheema added Team: SecuritySolution Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc. Team:Detection Rule Management Security Detection Rule Management Team v8.6.0 release_note:skip Skip the PR/issue when compiling release notes labels Sep 26, 2022
@MadameSheema MadameSheema marked this pull request as ready for review September 26, 2022 09:04
@MadameSheema MadameSheema requested review from a team as code owners September 26, 2022 09:04
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.

Alright, I ended up posting a ton of comments, sorry about that :)

One general comment: my expectation was that it should be enough to cover action execution at the integration test level - just like it's done for the alerts generation logic for every rule type.

Scenario: Rule executes successfully with added action (1 integration)

But I'm not going to ask to remove this new e2e test - I think it's also good to have one at the e2e level!

Comment on lines +246 to +247
runsEvery: getRunsEvery(),
lookBack: getLookBack(),
Copy link
Contributor

Choose a reason for hiding this comment

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

I noticed that runsEvery equals 1 second by default.

// Default interval is 1m, our tests config overwrite this to 1s
// See https://github.com/elastic/kibana/pull/125396 for details
const getRunsEvery = (): Interval => ({
  interval: '1',
  timeType: 'Seconds',
  type: 's',
});

What's the reason for having such a short interval?

I think for most of the tests where we need to run a rule, we need to run it only once in order to verify something. This means we could set the interval to a large value like 24 hours.

If we use a very short interval in e2e tests, this can:

  • create unnecessary load (Alerting Framework needs to schedule rules all the time while tests are running)
  • introduce unexpected race conditions between a test and Kibana running and re-running rules in the background
  • ultimately make the tests more flaky

Copy link
Member Author

Choose a reason for hiding this comment

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

I don't remember why we did it like that, originally for sure that was a reason behind. Good to have revisited this then :)

description: rule.description,
interval: `${rule.runsEvery.interval}${rule.runsEvery.type}`,
from: `now-${rule.lookBack.interval}${rule.lookBack.type}`,
interval: `${rule.runsEvery?.interval}${rule.runsEvery?.type}`,
Copy link
Contributor

@banderror banderror Sep 27, 2022

Choose a reason for hiding this comment

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

This will render it to undefinedundefined if rule.runsEvery is nullable. This is why I'm skeptical about making most of the rule fields optional in the CustomRule interface.

Comment on lines 108 to 109
const riskScore = rule.riskScore != null ? parseInt(rule.riskScore, 10) : undefined;
const severity = rule.severity != null ? rule.severity.toLocaleLowerCase() : undefined;
Copy link
Contributor

Choose a reason for hiding this comment

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

And we also have to check those fields for null all the time...

Comment on lines +182 to +197
export const deleteConnectors = () => {
const kibanaIndexUrl = `${Cypress.env('ELASTICSEARCH_URL')}/.kibana_\*`;
cy.request('POST', `${kibanaIndexUrl}/_delete_by_query?conflicts=proceed`, {
query: {
bool: {
filter: [
{
match: {
type: 'action',
},
},
],
},
},
});
};
Copy link
Contributor

Choose a reason for hiding this comment

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

It would be great to extract all API calls from this common file to the corresponding files under x-pack/plugins/security_solution/cypress/tasks/api_calls

MadameSheema and others added 3 commits September 28, 2022 06:54
…ule_actions.cy.ts

Co-authored-by: Dmitrii Shevchenko <dmshevch@gmail.com>
…ule_actions.cy.ts

Co-authored-by: Dmitrii Shevchenko <dmshevch@gmail.com>
@MadameSheema
Copy link
Member Author

@xcrzx @banderror lots of thanks for your thorough revision!!! :)

I believe it has helped a lot to put the focus on some pain points we have in general that need to be tackled in order to have a more robust and maintainable test suite. I'll write a ticket to collect all this information and I'll share it with you to gather more ideas.

Thanks!

@MadameSheema
Copy link
Member Author

@elasticmachine merge upstream

@MadameSheema
Copy link
Member Author

@elasticmachine merge upstream

@kibanamachine
Copy link
Contributor

merge conflict between base and head

@kibana-ci
Copy link
Collaborator

💛 Build succeeded, but was flaky

Failed CI Steps

Test Failures

  • [job] [logs] Security Solution Tests #2 / Alerts detection rules table auto-refresh should disable auto refresh when any rule selected and enable it after rules unselected

Metrics [docs]

Page load bundle

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

id before after diff
triggersActionsUi 98.9KB 98.9KB +36.0B

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

cc @MadameSheema

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.

The test now looks perfect, and thank you @MadameSheema for addressing so many comments!

I'll write a ticket to collect all this information and I'll share it with you to gather more ideas.

Please do, that would be awesome!

I'd like us to have ticket(s) for the following ideas:

  • Reusing existing rule schema in Cypress tests (comment)
  • Making tests driven by code instead of data; getting rid of optional properties in data (comment, comment, comment)
  • Cleaning up duplicate properties in data (comment, comment)
  • Setting a large default rule interval (comment)
  • Extracting some code from tasks/common into separate files (comment)

Let me know if I can help with writing them.

@MadameSheema MadameSheema merged commit db6a825 into elastic:main Sep 29, 2022
@MadameSheema MadameSheema deleted the cypress/adds-index-connector branch September 29, 2022 13:44
@kibanamachine kibanamachine added the backport:skip This commit does not require backporting label Sep 29, 2022
MadameSheema added a commit to MadameSheema/kibana that referenced this pull request Sep 29, 2022
…ules (elastic#141069)

Co-authored-by: Dmitrii Shevchenko <dmshevch@gmail.com>
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
(cherry picked from commit db6a825)
@MadameSheema
Copy link
Member Author

💚 All backports created successfully

Status Branch Result
8.5

Note: Successful backport PRs will be merged automatically after passing CI.

Questions ?

Please refer to the Backport tool documentation

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport:skip This commit does not require backporting release_note:skip Skip the PR/issue when compiling release notes Team:Detection Rule Management Security Detection Rule Management Team Team: SecuritySolution Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc. v8.5.0 v8.6.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

9 participants