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

Add e2e for Attack discovery #182918

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

Conversation

patrykkopycinski
Copy link
Contributor

@patrykkopycinski patrykkopycinski commented May 8, 2024

Summary

Adds e2e tests for Attack discovery. It takes list of preconfigured connectors from ./config/kibana.dev.yml and for each of them is generating Attack discovery and checks if the output is correct (currently just checking if the host provider doesn't contain {, as it was common issue with one of the connectors)

To test in open mode run:

yarn --cwd x-pack/test/security_solution_cypress cypress:open:ess --spec cypress/e2e/ai_assistant/attack_discovery.cy.ts

To test in run mode:

yarn --cwd x-pack/test/security_solution_cypress cypress:ai_assistant:run:ess --headed

To load Attack discovery data to the existing instance:

yarn --cwd x-pack/plugins/security_solution/scripts/load_attack_discovery_data.js

@patrykkopycinski
Copy link
Contributor Author

/ci

@patrykkopycinski
Copy link
Contributor Author

/ci

@patrykkopycinski
Copy link
Contributor Author

/ci

@patrykkopycinski
Copy link
Contributor Author

/ci

@patrykkopycinski
Copy link
Contributor Author

/ci

@patrykkopycinski
Copy link
Contributor Author

/ci

@patrykkopycinski
Copy link
Contributor Author

/ci

@patrykkopycinski
Copy link
Contributor Author

/ci

@patrykkopycinski
Copy link
Contributor Author

/ci

@patrykkopycinski patrykkopycinski marked this pull request as ready for review May 15, 2024 09:29
@pzl pzl requested review from ashokaditya and removed request for pzl May 15, 2024 11:30
Copy link
Contributor

@paul-tavares paul-tavares left a comment

Choose a reason for hiding this comment

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

Changes to files owned by the Defend Workflows team look good 👍

Comment on lines +291 to +296
// TODO: add deletion logic
// for (const index of existingIndices) {
// await esClient.indices.delete({ index: pattern });

// log.info(`Deleted index ${index}`);
// }
Copy link
Contributor

@semd semd May 16, 2024

Choose a reason for hiding this comment

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

Could you explain a bit more why is the index delete logic commented out as a todo?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

it was in the original script we have used locally, but I wasn't sure if it's something we will need in our tests, but just wanted to make sure we don't loose it

Copy link
Contributor

Choose a reason for hiding this comment

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

okay, if you know the author of the original script it would be great to find out why this was commented out.
If this is needed we should uncomment it, and if not there's no point in having this checkDeleteIndices function implemented without executing the actual deletion, right now it's called only to log stuff without doing anything.
Just a suggestion to keep the code clean.

…covery-e2e

# Conflicts:
#	x-pack/test/security_solution_cypress/cypress/cypress.config.ts
#	x-pack/test/security_solution_cypress/cypress/cypress_ci.config.ts
#	x-pack/test/security_solution_cypress/cypress/cypress_ci_serverless.config.ts
#	x-pack/test/security_solution_cypress/cypress/cypress_ci_serverless_qa.config.ts
#	x-pack/test/security_solution_cypress/cypress/cypress_serverless.config.ts
visitWithTimeRange(ATTACK_DISCOVERY_URL);
});

it.each(Object.keys(kibanaDevConfig['xpack.actions.preconfigured']))('%s', (connectorId) => {
Copy link
Contributor

Choose a reason for hiding this comment

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

If there's no connector configured in the kibana.yml the test crashes in this line with:

> Cannot convert undefined or null to object

Consider defaulting it (?? []) so cypress will tell there's no test to run instead, or maybe check this value and fail more gracefully if it's not defined. wdyt?

@kibana-ci
Copy link
Collaborator

kibana-ci commented May 17, 2024

💔 Build Failed

Failed CI Steps

Test Failures

  • [job] [logs] FTR Configs #72 / Serverless observability API SLOs fetch historical summary computes the historical summary for a rolling occurrences SLO
  • [job] [logs] FTR Configs #72 / Serverless observability API SLOs fetch historical summary computes the historical summary for a rolling occurrences SLO
  • [job] [logs] FTR Configs #55 / SLO API Tests fetch historical summary computes the historical summary for a rolling occurrences SLO
  • [job] [logs] FTR Configs #55 / SLO API Tests fetch historical summary computes the historical summary for a rolling occurrences SLO

Metrics [docs]

✅ unchanged

History

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

@PhilippeOberti
Copy link
Contributor

@patrykkopycinski looking at the code owners (running node ./code-owners.js 182918 in the kibana-operations repo) I see that a lot of the files in this x-pack/test/security_solution_cypress/cypress/fixtures/assistant/attack_discovery/ folder are owned by multiple teams.
Maybe it would be a good idea to be a bit more granular here?

Copy link
Contributor

@PhilippeOberti PhilippeOberti left a comment

Choose a reason for hiding this comment

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

changes LGTM for the Threat Hunting Investigations team

Copy link
Member

@ashokaditya ashokaditya left a comment

Choose a reason for hiding this comment

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

Security Solution changes LGTM. I've a couple of nits related to readability and TS but nothing that blocks this PR.

filePath: string
): {
ftrConfig: SecuritySolutionDescribeBlockFtrConfig;
devConfig: boolean;
Copy link
Member

Choose a reason for hiding this comment

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

nit: Consider naming this to something that answers a yes/no. devConfig seems like a collection/object but it is a boolean. isDevRun/isDevMode or something like that?

@@ -90,25 +95,39 @@ export const parseTestFileConfig = (filePath: string): SecuritySolutionDescribeB
'key.name',
'ftrConfig',
]);
// @ts-expect-error
const devConfig = _.find(callExpressionProperties?.value?.properties, [
Copy link
Member

Choose a reason for hiding this comment

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

nit: Maybe rename this local devConfig to avoid confusion and variable re-declaration TS error?

Suggested change
const devConfig = _.find(callExpressionProperties?.value?.properties, [
const _devConfig = _.find(callExpressionProperties?.value?.properties, [

@@ -437,7 +437,7 @@ ${JSON.stringify(cypressConfigFile, null, 2)}

const productTypes = isOpen
? getProductTypes(tier, endpointAddon, cloudAddon)
: (parseTestFileConfig(filePath).productTypes as ProductType[]);
: (parseTestFileConfig(filePath).ftrConfig?.productTypes as ProductType[]);
Copy link
Member

Choose a reason for hiding this comment

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

Looks like ftrConfig is always present. The productTypes could be undefined which is why it is type casted here.

Suggested change
: (parseTestFileConfig(filePath).ftrConfig?.productTypes as ProductType[]);
: (parseTestFileConfig(filePath).ftrConfig.productTypes as ProductType[]);

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

9 participants