* WIP: Adding integration test
* Replace threat.indicator mappings with threat.enrichments mappings
The nested threat.indicator mappings were experimental, and replaced by
threat.enrichmentsin ECS 1.10. While these fields are also experimental,
they fix the conflict between CTI data's normal threat.indicator
mappings.
* Add threat.enrichments mappings to our signals template mappings
event.* is no longer nested within here; it was determined that event
fields were not relevant to enrichment. All relevant ECS fieldsets
(file, pe, etc) are now nested under threat.enrichments.
* Update snapshot with newest threat.enrichments mappings
This test is a snapshot of the actual mappings applied by our templates. Looks good to me!
* Update ECS types to match latest
We now have two threat fields we care about for CTI, for legacy and
official ECS.
* Add a basic test for behavior of legacy enriched signals.
They're still queryable by threat.indicator, meaning that any existing
dashboards will still work.
* WIP: First pass at a data migration for CTI signals
* Defines reindex script to move things around
* Adds integration tests to make sure the migration and new mappings
work
* Need to test a few more things and verify corner cases
* Need to extract some helpers from tests
* Bump our template version to ensure devs roll over
Marshall bumped to 55, giving us 10 versions for 7.14.x updates.
However, devs would not otherwise roll over and get my mapping updates
without destroying their signals index and rebuilding (which is also not
the same thing, exactly), so this trades having one higher signals
version for a more streamlined dev workflow.
* More robust guard against data migration
We only attempt to migrate legacy enrichments if the document:
* is a signal from an indicator match rule
* has a `threat.indicator` field
* does not have a `threat.enrichments` field
* Minor reorder of operations to make logic clearer
* Add more assertions around our signals data migration
Tests a few more pieces of the resulting document, giving more
confidence that it's the correct transformation (and mappings).
This also modifies/anonymizes the data that was originally generated on
a work machine.
* Remove outdated note
This was for when these tests were driven via the UI; the API is more
responsive and now synchronization is currently needed here, beyond the
200 responses.
* Fix typo in comment
These fields are in ECS 1.11.
* Update snapshot test
We bumped the version previously, causing this test to become outdated.
* Update ECS typings in timelines plugin
These were copied from the security_solution plugin. I updated those,
but neglected to update these.
Until there's a better mechanism for deduplication here, I'm going to
kick the can and update both for now.
* Update enrichments logic to read/write from threat.enrichments
* indicator match rule logic
* we now simply copy from the specified indicator path, and place that
in `threat.enrichments.indicator`
* event enrichment API logic
* We were previously returning fields from `indicator.*`, we now
include the `indicator.*` suffix in order to be more consistent with
the sibling `matched.*` fields
* row renderer logic
* removal of dataset
* updates relevant to API changes above
* Fix logical error in generating links from indicator fields
We want to link the reference field, not a `first_seen` field.
* Always include the indicator prefix in first-party indicator fields
Prior to this change we would display e.g. `threatintel.indicator.foo`
for investigation enrichment fields. Now that the structure has changed
slightly and we return both `indicator.*` and `matched.*` fields for
existing enrichents, we want to display investigation enrichment
similarly.
* Update indicator match rule integration tests
Now that we've updated our enrichment logic, we need to update our
enrichment tests.
* Remove unused translation
* Update example row renderer data for enriched alerts
* Update parallel CTI constants to get our CTI row renderer working
We were not requesting the necessary fields for our row renderer, since
these constants (specifically CTI_ROW_RENDERER_FIELDS) now exist in both
security_solution and the timelines plugin. I had updated the former,
but only the latter is actually used.
* Update CTI enrichment UI tests
* Update prepackaged threat timeline template with new threat fields
Also bumps the timelineTemplateVersion.
* Update Indicator Match rule tests
These needed three things:
* Update to timeline template (see previous commit)
* Changing expectations from `threat.indicator` to `threat.enrichments`
* Update row renderer expectation to exclude dataset
* Update mock data with newest CTI enrichment fields
* Fix assertion on our threat details
These fields are prefixed with `indicator` now because:
1. This data pertains to the indicator, not the match per se
2. The actual field is prefixed with indicator (or, it at least
specifies an indicator in the case of a custom threat index (via
threat_indicator_path))
* Update test data and tests for our field parsing helpers
* Update more event-parsing tests
Ths one involved updating a mock in another package.
* Modify our helper function to support old filebeat indicators
When we query indicators for enrichment matches, the current expectation
is that we'll be querying 7.14 filebeat modules, which have an indicator
path of 'threatintel.indicator'. The only place that matters on the UI
is on the threat intel panel, where these indicators come back with such
a prefix.
This change has one behavior: it brings back the `provider` field on the
Alert summary tab for queried enrichments from filebeat modules.
* Update variable and method names to be more consistent with internal terminology
Indicators come from a CTI index. Enrichments are the application of
indicator data to other documents, and contain both indicator fields and
matched context.
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Ryland Herrick <ryalnd@gmail.com>
* Remove legacy imports from 'elasticsearch' package
This prefers the newer types from '@elastic/elasticsearch'.
There was one instance where mock data was insufficient to satisfy the
newer analogous types; in all other cases this was just a find/replace.
* Fix type errors with a null guard
We know that this mock has hits with _source values, but we cannot
convey this to typescript as null assertions are disabled within this
project. This seems like the next best solution, preferable to a
@ts-expect-error.
* Fix a few more type errors
* Replace legacy type imports in integration tests
* refactors destructuring due to _source being properly declared as
conditional
* Update more integration tests to account for our optional _source
Changes here fall into one of two categories:
* If the test was making an assertion on a value from _source, we simply
null chain and continue to assert on a possibly undefined value.
* If the test logic depends on _source being present, we first assert that
presence, and exit the test early if absent.
* Fix more type errors
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Ryland Herrick <ryalnd@gmail.com>
## Summary
Fixes https://github.com/elastic/kibana/issues/102613, and targets `7.14.0` as a blocker/critical
Previously we never fully finished the plumbing for using the `os_types` (operating system type) in the exception lists to be able to filter out values based on this type. With the endpoint exceptions now having specific selections for os_type we have to filter it with exceptions and basically make it work.
Some caveats is that the endpoints utilize `host.os.name.casless` for filtering against os_type, while agents such as auditbeat, winlogbeat, etc... use `host.os.type`. Really `host.os.type` is the correct ECS field to use, but to retain compatibility with the current version of endpoint agents I support both in one query to where if either of these two matches, then that will trigger the exceptions.
* Adds e2e tests
* Enhances the e2e tooling to do endpoint exception testing with `os_types`.
* Adds the logic to handle os_type
* Updates the unit tests
### Checklist
Delete any items that are not applicable to this PR.
- [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
Co-authored-by: Frank Hassanabad <frank.hassanabad@elastic.co>
## Summary
Removes EQL timestamp workaround we introduced earlier when we found the bug https://github.com/elastic/kibana/pull/103771 now that it has been fixed with the fields API https://github.com/elastic/elasticsearch/issues/74582
* Fixes the EQL timestamp issue by removing the workaround
* Introduces EQL timestamps being formatted as ISO8601 like we do with KQL
* Adds e2e tests for the EQL timestamps
* Removes some boiler plating around our e2e tests by adding two utilities of `getEqlRuleForSignalTesting` and `getThresholdRuleForSignalTesting` and reducing those e2e code areas.
### Checklist
- [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
Co-authored-by: Frank Hassanabad <frank.hassanabad@elastic.co>
## Summary
Adds runtime field tests with skips around the tests that we do not support just yet.
* Adds tests around corner cases involving ".", "..", ".foo", "foo.", etc...
* Adds tests around overriding values from the runtime fields within the source document
* Adds tests around ambiguity for when we override an array in a runtime field
* Fixes minor wording around previous tests
* Fixes one line string when we do testing in one area
### Checklist
- [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
Co-authored-by: Frank Hassanabad <frank.hassanabad@elastic.co>
* Update @elastic/elasticsearch to 8.0.0-canary13 (#98266)
* bump @elastic/elasticsearch to canary.7
* address errors in core
* address errors in data plugin
* address errors in Alerting team plugins
* remove outdated messages in Lens
* remove unnecessary comments in ML
* address errors in Observability plugin
* address errors in reporting plugin
* address errors in Rule registry plugin
* fix errors in Security plugins
* fix errors in ES-UI plugin
* remove unnecessary union.
* update core tests
* fix kbn-es-archiver
* update to canary 8
* bump to v9
* use new typings
* fix new errors in core
* fix errors in core typeings
* fix type errors in data plugin
* fix type errors in telemetray plugin
* fix data plugin tests
* fix search examples type error
* fix errors in discover plugin
* fix errors in index_pattern_management
* fix type errors in vis_type_*
* fix errors in typings/elasticsearch
* fix type errors in actions plugin
* fix type errors in alerting and apm plugins
* fix type errors in canvas and cases
* fix errors in event_log
* fix type errors in ILM and ingest_pipelines
* fix errors in lens plugin
* fix errors in lists plugin
* fix errors in logstash
* fix errors in metrics_entities
* fix errors in o11y
* fix errors in watcher
* fix errors in uptime
* fix errors in upgrade_assistant
* fix errors in task_manager
* fix errors in stack_alerts
* fix errors in security_solution
* fix errors in rule_registry
* fix errors in snapshot_restore
* fix remaining errors
* fix search intergration tests
* adjust assetion
* bump version to canary.10
* adapt code to new naming schema
* use mapping types provided by the client library
* Revert "adjust assetion"
This reverts commit 19b8fe0464.
* fix so intergration tests
* fix http integration tests
* bump version to canary 11
* fix login test
* fix http integration test
* fix apm test
* update docs
* fixing some ml types
* fix new errors in data plugin
* fix new errors in alerting plugin
* fix new errors in lists plugin
* fix new errors in reporting
* fix or mute errors in rule_registry plugin
* more ML type fixes
* bump to canary 12
* fix errors after merge conflict
* additional ML fixes
* bump to canary 13
* fix errors in apm plugin
* fix errors in fleet plugin
* fix errors in infra plugin
* fix errors in monitoring plugin
* fix errors in osquery plugin
* fix errors in security solution plugins
* fix errors in transform plugin
* Update type imports for ES
* fix errors in x-pack plugins
* fix errors in tests
* update docs
* fix errors in x-pack/test
* update error description
* fix errors after master merge
* update comment in infra plugin
* fix new errors on xpack tests/
Co-authored-by: James Gowdy <jgowdy@elastic.co>
Co-authored-by: Dario Gieselaar <dario.gieselaar@elastic.co>
# Conflicts:
# package.json
# src/core/server/saved_objects/migrationsv2/integration_tests/migration.test.ts
# test/common/services/saved_object_info.ts
# x-pack/plugins/snapshot_restore/server/routes/api/repositories.ts
# x-pack/plugins/snapshot_restore/server/routes/api/snapshots.ts
# yarn.lock
* revert @ts-expect-error changes in infra plugin
* update docs
## Summary
Utilizes constants package and deletes duplicate code
* Renames the `securitysolution-constants` to be `securitysolution-list-constants` to be specific
* Deletes duplicated code found during cleanup
* Moves more tests into the packages found along the way with the duplicated code
* Moves `parseScheduleDates` from `@kbn/securitysolution-io-ts-types` to `@kbn/securitysolution-io-ts-utils`
### Checklist
- [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
Co-authored-by: Frank Hassanabad <frank.hassanabad@elastic.co>
## Summary
* Creates a `securitysolution-list-utils` packaged and moves the first set of utilities into there
* Fixes a slight bug with `kbn-securitysolution-io-ts-list-types` where the wrong name was used
* Moves _all_ of the lists schemas and types into the package `kbn-securitysolution-io-ts-list-types`
* Removes copied code found in a few places
## Tech debt
* Some spots I have to use an `any` in the package as Kibana kbn packages don't have the types I need
* Some spots I copy constants until we can straighten out those pieces.
* I keep copied mock files until we figure out how to share mocks from these packages without adding weight or we create dedicated mock packages for all of this.
### Checklist
- [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
Co-authored-by: Frank Hassanabad <frank.hassanabad@elastic.co>
## Summary
Re-adds a test that was skipped. If it goes bonkers again, I will add more debugging information to it. I will keep an eye on the operations channel to see when/if this fails again. Originally this looked to be timeouts waiting, so I increased the global timeout to be 20 seconds instead of the original 10 seconds.
Resolves:
https://github.com/elastic/kibana/issues/89389
### Checklist
- [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
* Add API integration tests for threshold rules and more tests for EQL rules
* Add API more tests for exceptions and value list exceptions
* Fix unit test and add EQL api test checking multiple signal generation
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Marshall Main <55718608+marshallmain@users.noreply.github.com>
* Adds helper to normalize legacy ML rule field to an array
This will be used on read of rules, to normalize legacy rules while
avoiding an explicit migration.
* Fix our detection-specific ML search function
Luckily this was just a translation layer to our anomaly call, and the
underlying functions already accepted an array of strings.
* WIP: Run rules against multiple ML Job IDs
We don't yet support creation of rules with multiple job ids, either on
the API or the UI, but when we do they will work.
Note: the logic was previously to generate an error if the underlying
job was not running, but to still query and generate alerts. Extending
that logic to multiple jobs: if any are not running, we generate an
error but continue querying and generating alerts.
* WIP: updating ml rule schemas to support multiple job IDs
* Simplify normalization method
We don't care about null or empty string values here; those were
holdovers from copying the logic of normalizeThreshold and don't apply
to this situation.
* Move normalized types to separate file to fix circular dependency
Our use of NonEmptyArray within common/schemas seemed to be causing the
above; this fixes it for now.
* Normalize ML job_ids param at the API layer
Previous changes to the base types already covered the majority of
routes; this updates the miscellaneous helpers that don't leverage those
shared utilities.
At the DB level, the forthcoming migration will ensure that we always
have "normalized" job IDs as an array.
* Count stopped ML Jobs as partial failure during ML Rule execution
Since we continue to query anomalies and potentially generate alerts, a
"failure" status is no longer the most accurate for this situation.
* Update 7.13 alerts migration to allow multi-job ML Rules
This ensures that we can assume string[] for this field during rule
execution.
* Display N job statuses on rule details
* WIP: converts MLJobSelect to a multiselect
Unfortunately, the SuperSelect does not allow multiselect so we need to
convert this to a combobox. Luckily we can reuse most of the code here
and remain relatively clean.
Since all combobox options must be the same (fixed) height, we're
somewhat more limited than before for displaying the rows. The
truncation appears fine, but I need to figure out a way to display the
full description as well.
* Update client-side logic to handle an array of ML job_ids
* Marginally more legible error message
* Conditionally call our normalize helper only if we have a value
This fixes a type error where TS could not infer that the return value
would not be undefined despite knowing that the argument was never
undefined. I tried some fancy conditional generic types, but that didn't
work.
This is more analogous to normalizeThresholdObject now, anyway.
* Fix remaining type error
* Clean up our ML executor tests with existing contract mocks
* Update ML Executor tests with new logic
We now record a partial failure instead of an error.
* Add and update tests for new ML normalization logic
* Add and update integration tests for ML Rules
Ensures that dealing with legacy job formats continues to work in the
API.
* Fix a type error
These params can no longer be strings.
* Update ML cypress test to create a rule with 2 ML jobs
If we can create a rule with 2 jobs, we should also be able to create a
rule with 1 job.
* Remove unused constant
* Persist a partial failure message written by a rule executor
We added the result.warning field as a way to indicate that a partial
failure was written to the rule, but neglected to account for that in the
main rule execution code, which caused a success status to immediately
overwrite the partial failure if the rule execution did not otherwise
fail/short-circuit.
Co-authored-by: Ryland Herrick <ryalnd@gmail.com>
* ES client : use the new type definitions (#83808)
* Use client from branch
* Get type checking working in core
* Fix types in other plugins
* Update client types + remove type errors from core
* migrate Task Manager Elasticsearch typing from legacy library to client library
* use SortOrder instead o string in alerts
* Update client types + fix core type issues
* fix maps ts errors
* Update Lens types
* Convert Search Profiler body from a string to an object to conform to SearchRequest type.
* Fix SOT types
* Fix/mute Security/Spaces plugins type errors.
* Fix bootstrap types
* Fix painless_lab
* corrected es typing in Event Log
* Use new types from client for inferred search responses
* Latest type defs
* Integrate latest type defs for APM/UX
* fix core errors
* fix telemetry errors
* fix canvas errors
* fix data_enhanced errors
* fix event_log errors
* mute lens errors
* fix or mute maps errors
* fix reporting errors
* fix security errors
* mute errors in task_manager
* fix errors in telemetry_collection_xpack
* fix errors in data plugins
* fix errors in alerts
* mute errors in index_management
* fix task_manager errors
* mute or fix lens errors
* fix upgrade_assistant errors
* fix or mute errors in index_lifecycle_management
* fix discover errors
* fix core tests
* ML changes
* fix core type errors
* mute error in kbn-es-archiver
* fix error in data plugin
* fix error in telemetry plugin
* fix error in discover
* fix discover errors
* fix errors in task_manager
* fix security errors
* fix wrong conflict resolution
* address errors with upstream code
* update deps to the last commit
* remove outdated comments
* fix core errors
* fix errors after update
* adding more expect errors to ML
* pull the lastest changes
* fix core errors
* fix errors in infra plugin
* fix errors in uptime plugin
* fix errors in ml
* fix errors in xpack telemetry
* fix or mute errors in transform
* fix errors in upgrade assistant
* fix or mute fleet errors
* start fixing apm errors
* fix errors in osquery
* fix telemetry tests
* core cleanup
* fix asMutableArray imports
* cleanup
* data_enhanced cleanup
* cleanup events_log
* cleaup
* fix error in kbn-es-archiver
* fix errors in kbn-es-archiver
* fix errors in kbn-es-archiver
* fix ES typings for Hit
* fix SO
* fix actions plugin
* fix fleet
* fix maps
* fix stack_alerts
* fix eslint problems
* fix event_log unit tests
* fix failures in data_enhanced tests
* fix test failure in kbn-es-archiver
* fix test failures in index_pattern_management
* fixing ML test
* remove outdated comment in kbn-es-archiver
* fix error type in ml
* fix eslint errors in osquery plugin
* fix runtime error in infra plugin
* revert changes to event_log cluser exist check
* fix eslint error in osquery
* fixing ML endpoint argument types
* fx types
* Update api-extractor docs
* attempt fix for ese test
* Fix lint error
* Fix types for ts refs
* Fix data_enhanced unit test
* fix lens types
* generate docs
* Fix a number of type issues in monitoring and ml
* fix triggers_actions_ui
* Fix ILM functional test
* Put search.d.ts typings back
* fix data plugin
* Update typings in typings/elasticsearch
* Update snapshots
* mute errors in task_manager
* mute fleet errors
* lens. remove unnecessary ts-expect-errors
* fix errors in stack_alerts
* mute errors in osquery
* fix errors in security_solution
* fix errors in lists
* fix errors in cases
* mute errors in search_examples
* use KibanaClient to enforce promise-based API
* fix errors in test/ folder
* update comment
* fix errors in x-pack/test folder
* fix errors in ml plugin
* fix optional fields in ml api_integartoon tests
* fix another casting problem in ml tests
* fix another ml test failure
* fix fleet problem after conflict resolution
* rollback changes in security_solution. trying to fix test
* Update type for discover rows
* uncomment runtime_mappings as its outdated
* address comments from Wylie
* remove eslint error due to any
* mute error due to incompatibility
* Apply suggestions from code review
Co-authored-by: John Schulz <github.com@jfsiii.org>
* fix type error in lens tests
* Update x-pack/plugins/upgrade_assistant/server/lib/reindexing/reindex_service.ts
Co-authored-by: Alison Goryachev <alisonmllr20@gmail.com>
* Update x-pack/plugins/upgrade_assistant/server/lib/reindexing/reindex_service.test.ts
Co-authored-by: Alison Goryachev <alisonmllr20@gmail.com>
* update deps
* fix errors in core types
* fix errors for the new elastic/elasticsearch version
* remove unused type
* remove unnecessary manual type cast and put optional chaining back
* ML: mute Datafeed is missing indices_options
* Apply suggestions from code review
Co-authored-by: Josh Dover <1813008+joshdover@users.noreply.github.com>
* use canary pacakge instead of git commit
Co-authored-by: Josh Dover <me@joshdover.com>
Co-authored-by: Josh Dover <1813008+joshdover@users.noreply.github.com>
Co-authored-by: Gidi Meir Morris <github@gidi.io>
Co-authored-by: Nathan Reese <reese.nathan@gmail.com>
Co-authored-by: Wylie Conlon <wylieconlon@gmail.com>
Co-authored-by: CJ Cenizal <cj@cenizal.com>
Co-authored-by: Aleh Zasypkin <aleh.zasypkin@gmail.com>
Co-authored-by: Dario Gieselaar <dario.gieselaar@elastic.co>
Co-authored-by: restrry <restrry@gmail.com>
Co-authored-by: James Gowdy <jgowdy@elastic.co>
Co-authored-by: John Schulz <github.com@jfsiii.org>
Co-authored-by: Alison Goryachev <alisonmllr20@gmail.com>
# Conflicts:
# package.json
# src/core/server/saved_objects/migrationsv2/integration_tests/migration.test.ts
# src/plugins/data/server/autocomplete/value_suggestions_route.ts
# src/plugins/discover/public/application/angular/doc_table/create_doc_table_react.tsx
# x-pack/plugins/apm/server/lib/services/get_service_dependencies/get_destination_map.ts
# x-pack/plugins/infra/server/lib/alerting/inventory_metric_threshold/evaluate_condition.ts
# x-pack/plugins/security/server/authentication/api_keys/api_keys.ts
# yarn.lock
* fix file broken during conflict resolution
* fix lint errors and test failure
Co-authored-by: Tomas Della Vedova <delvedor@users.noreply.github.com>
* fix for when search response yields 400 with missing timestamp override field
* prefer includes over strict equality
* adds integration test to check for this case
* adds a unit test and util function to ensure unit test executes properly and waits for rule to complete running
* remove comments from rebase
Co-authored-by: Devin W. Hurley <devin.hurley@elastic.co>
* removes usage of 'partial failure' status and replaces with a 'warning' status, also adds some logic to be backwards compatible with 'partial failure' statuses
* update integration tests from 'partial failure' to 'warning'
* fix integration test to warn and not error when no index patterns match concrete indices
* fix integration test
* removes outdated comments from the create_rules e2e test
# Conflicts:
# x-pack/test/detection_engine_api_integration/security_and_spaces/tests/create_rules.ts
## Summary
Adds e2e tests for https://github.com/elastic/kibana/pull/90326
* Adds e2 tests and backfills for updating actions and expected behaviors
* Adds two tests that would fail without the fix and if a regression happens this will trigger on the regression
* Adds two tests to the PATCH for exception lists even though there is no regression there. Reason is to prevent an accidental issue there.
* Adds tests to ensure the version number does not accidentally get bumped if PATCH or UPDATE is called on actions or exceptions for immutable rules.
* Adds utilities for cutting down noise.
### Checklist
- [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
* [Security Solution] [Detections] Multiple timestamp fields (#86368)
* query timestamp override and default @timestamp field, adds functional test for this
* fix logic for when to filter out timestamp override documents
* update the total hits field of the search result if we find hits within the secondary search. Without updating the total hits field, we could be finding events but not indexing them based on the bulk create logic
* update integration test, updates logic for performing second search and excluding documents with timestamp override field
* cleanup comments, remove commented out console logs, fix logic to break out of loop during secondary search after
* default param to 'succeeded'
* remove commented out code
* always perform a secondary search when timestamp override field is present
* perf improvement and fix bug where sortIds were being mixed between search after calls
* set sortIds to undefined when not present on search result
* exit loop and prevent extraneous searches from occurring if we exhaust sort ids
* skips test that was skipped in 8.0 / master
* [SecuritySolution][Detections] Adds SavedObject persistence to Signals Migrations (#85690)
* Adds new SO type for persisting our signals migrations
* WIP: Migration status SO client
Trying to forge a patterrn using io-ts to validate at runtime. I think
I've got it working but I want to refactor the pipeline out into a
reusable function(s).
* Implements our SavedObjects service for signals migrations
* Defines a simple client that delegates to the base SO client with
our SO type
* Defines a service that consumes the simpler client, adding validations
and data transforms on top.
* Refactoring migration code to work with saved objects
As opposed to the previous ephemeral, encoded tokens, we now retrieve migration
info from saved objects.
At the API level, this means that both the create and finalize endpoints
receive a list of concrete indices. No more passing around tokens.
As both endpoints are idempotent, users can hammer them as much as they
want with the same lists of indices. Redundant creates and finalizes
will be met with inline 400 messages, and as one continues to poll the
finalize endpoint they should see more and more indices respond with
"completed: true"
* Fixing integration tests first, and anything upstream breaking them
* Clean up API integration tests
* standardize assignment of responses (with types)
* deletes migration SOs as test cleanup
* Split API tests into separate files
This was getting big and unwieldy; this splits these into one file per
endpoint.
* Refactor: split existing migration service functionality into atomic functions
This will allow us to repurpose the service to compose more
functionality and be more specifically useful, while keeping the
component logic separate.
* WIP: moving logic into migrationService.create
* Splitting get_migration_status into component functions
getMigrationStatus was really two separate aggregations, so I split them
out and we recompose them in the necessary routes.
* Move finalization logic into function
* migrationService exposes this as .finalize()
* adds an error field to our migration SO
* We currently only have one error that we persist there, but it would
be very time-consuming to track down that information were it not
there.
* Adds function for migration "deletion" logic
* migrationService leverages this function
* adds new boolean to our savedObject
* deletes unused function (deleteMigrationSavedObject)
* Adds route for soft-deletion of migrations
* Updating tests related to migration status
* Adding/updating mocks/unit tests necessary to satisfy the things I
need to test
* I mainly wanted to test that the the status endpoint filtered out the
deleted migrations; this was accomplished with a unit test after
fleshing out some mocks/sample data.
* Move old migration service tests to the relevant function tests
This logic was previously moved out into component functions; this moves
the tests accordingly.
* Add some unit tests around our reindex call
* Fix create migration route tests
Mocks out our migration functions, rather than stubbing ES calls
directly.
* Updates finalize route unit tests
Addresses functionality that hasn't been moved to finalizeMigration()
* Unit tests our finalization logic
Fixes a bug where we weren't accounting for soft-deleted migrations.
ALso updates our test migration SO to have a status of 'pending' as
that's a more useful default.
* Fixes finalization integration tests
These were failing due:
* a change in the migration status API response
* a bug I introduced in the finalize route
* Adds tests for our migration deletion endpoint
* unit tests
* API integration tests
* Caught/fixed bug with deleting a successful migration
* Fixes types
Removes unused code.
* Prevent race condition due to template rollover during migration
If a user has an out of date index (v1) relative to the template (v2), but the
template itself is out of date (newest is v3), then it's possible that
the template is rolled over to v3 after the v1-v2 migration has been
created but before the new index has been created.
In such a case, the new index would receive the v3 mappings but would
incorrectl be marked as v2. This shouldn't necessarily be an issue, but
it's an unnecessary state that can easily be prevented with the guard
introduced here.
* Add real usernames to migration savedObjects
In addition to the SOs themselves giving us observability into what
migration actions were performed, this gives us the additional info of
_who_ performed the action.
* Index minimal migration SO fields needed for current functionality
* Add additional migration info to status endpoint
This will allow users to finalize a migration if they've lost the
response to their POST call.
* Finalize endpoint receives an array of migration IDs, not indices
This disambiguates _which_ migrations we were finalizing if you passed
an index (which was previously: the most recent migration).
* Fix type errors in tests after we threaded through username
* Update responsibilities of migration finalize/delete endpoints
Discussions with @marshallmain lead to the following refactor:
* finalize does not delete tasks
* finalize only applies cleanup policy to a failed migration
* delete takes an array of migration ids (like finalize)
* delete hard-deletes the SavedObject of a completed (failed or
successful) migration
This gives a bit more flexibility with the endpoints, as well as
disambiguates the semantics: it just deletes migrations!
* Fix tests that were broken during refactoring
* Fix type errors
I removed some logic here but forgot the imports :(
* Move outdated integration test
In the case of a successful migration, application of the cleanup policy
is done by the deletion endpoint. In the interest of data preservation,
we do not delete a sourceIndex unless it is explicitly deleted.
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* Relax test assertions
These 403 messages seem to be slightly different depending on the ES
version/configuration as this one just failed on CI.
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* WIP: basic reindexing works, lots of edge cases and TODOs to tackle
* Add note
* Add version metadata to signals documents
* WIP: Starting over from the ground up
* Removes obsolete endpoints/functions
* Adds endpoint for checking the migration status of signals indices
* Adds helper functions to represent the logical pieces of answering
that question
* Fleshing out upgrade of signals
* triggers reindex for each index
* starts implementing followup endpoint to "finalize" after reindexing
is finished
* Fleshing out more of the upgrade path
Still moving logic around a bunch.
* Pad the version number of our destination migration index
Instead of e.g. `.siem-signals-default-000001-r5`, this will generate
`.siem-signals-default-000001-r000005`.
This shouldn't matter much, but it may make it easier for users at a
glance to see the story of each index.
* Fleshing out more upgrade finalization
* Verifies that task matches the specified parameters
* Verifies that document counts are the same
* updates aliases
* finalization endpoint requires both source/dest indexes since we can't
determine that from the task itself.
* Ensure that new signals are generated with an appropriate schema_version
* Apply migration cleanup policy to obsolete signals indexes
After upgrading a particular signals index, we're left with both the old
and new copies of the index. While the former is unlinked, it's still
taking up disk space; this ensures that it will eventually be deleted,
but gives users enough time to recover data if necessary.
This also ensures that, as with the normal signals ILM policy, it is
present during our normal sanity checks.
* Move more logic into component functions
* Fix type errors
* Refactor to make things a little more organized
* Moves migration-related routes under signals/ to match their routing
* Generalizes migration-agnostic helpers, moves them to appropriate
folders (namely index/)
* Inlined getMigrationStatusInRange, a hyper-specific function with
limited utility elsewhere
* Add some JSDoc comments around our new functions
This is as much to get my thoughts in order as it is for posterity.
Next: tests!
* Adds integration tests around migration status route
* Adds io-ts schema for route params
* Adds es_archiver data to represent an outdated signals index
* Adds API integration tests for our signals upgrade endpoint
* Adds io-ts schema for route params
* Adds second signals index archive, updates docs
* Adds test helper to wait for a given index to have documents
* Adds test helper to retrieve the relevant index name from a call to
esArchive.load
* WIP: Fleshing out finalization tests
* Consolidate terminalogy around a migration
We're no longer making a distinction between an upgrade vs. an update
vs. a migration vs. a reindex: a migration is the concept that
encompasses this work. Both an index and individual documents can
require a migration, but both follow the same code path to migrate.
* Implement encoding of migration details
This will be a slightly better API: rather than having to pass all three
fields to finalize the migration, API users can instead send the token.
* Better transformation of errors thrown from the elasticsearch client
These often contain detailed information that we were previously
dropping. This will give better info on the migration finalization
endpoint, but should give more information across all detection_engine
endpoints in the case of an es client error.
* Finishing integration tests around finalization endpoint
This lead to a few changes in the responses from our different
endpoints; mainly, we pass both the migration token AND its constituent
parts to aid in debugging.
* Test an error case due to a reindexing failure
This would be really hard to reproduce with an integration test since
we'd need to generate a specific reindex failure. Much easier to stub
some ES calls to exercise that code in a unit test.
* Remove unnecessary version info from signals documents
We now record a single document-level version field. This represents the
version of the document's _source, which is generated by our rule
execution.
When either a mapping _or_ a transformation is added, this version will
be bumped such that new signals will contain the newest version, while
the index itself may still contain the old mappings.
The transformation pipeline will use the signal version to short-circuit
unnecessary transformations.
* Migrate an index relative to the ACTUAL template version
This handles the case where a user is attempting to migrate, but has not
yet rolled over to the newest template. Running rules may insert "new"
signals into an "old" index, but from the perspective of the app no
migration is necessary in that case.
If/when they roll over, the aforementioned index (and possibly older
ones) will be qualified as outdated, and can be migrated.
* Enrich our migration_status endpoint with an is_outdated qualification
This can be determined programatically, but for users manually
interpreting this response, the qualification will help.
* Update migration scripts
* More uniform version checking
* getIndexVersion always returns a number
* version comparisons use isOutdated
* Fix signal generation unit tests
We now generate a version field to indicate the version under which the
signal was created/migrated.
* Support reindex options to be sent to create_migration endpoint
Rather than having to perform a manual reindex, this should give API
users some control over the performance of their automated migration.
* Fix signal generation integration tests
These were failing on our new signal field.
* Add unit tests for getMigrationStatus
* Add a basic test for getSignalsIndicesInRange
Since this is ultimately just an aggregation query there's not much else
to test.
* Add unit test for the naming of our destination migration index
* Handle write indices in our migration logic
* Treat write indices as any other index in migration status endpoint
* Migration API rejects requests containing write indices
* Migration API rejects requests containing unknown/non-signals indices
* Add original hot phase to migration cleanup policy
Without this phase, ILM gets confused as it tries to move to the delete
phase and fails.
* Update old comment
The referenced field has changed.
* Delete task document as part of finalization
* Accurately report recoverable errors on create_signals_migration route
If we have a recoverable error: e.g. the destination index already
exists, or a specified index is a write index, we now report those
errors as part of the normal 200 response as these do not preclude other
specified indices from being migrated.
However, if non-signals indices are specified, we do continue to reject
the entire request, as that's indicative of misuse of the endpoint.
* bump version to 4.1.1-rc
* fix code to run kbn bootstrap
* fix errors
* DO NOT MERGE. mute errors and ping teams to fix them
* Address EuiSelectableProps configuration in discover sidebar
* use explicit type for EuiSelectable
* update to ts v4.1.2
* fix ts error in EuiSelectable
* update docs
* update prettier with ts version support
* Revert "update prettier with ts version support"
This reverts commit 3de48db3ec.
* address another new problem
Co-authored-by: Chandler Prall <chandler.prall@gmail.com>
# Conflicts:
# test/functional/services/remote/remote.ts
## Summary
Adds support to the end to end (e2e) functional test runner (FTR) support for rule runtime tests as well as 213 tests for the exception lists which include value based lists. Previously we had limited runtime support, but as I scaled up runtime tests from 5 to 200+ I noticed in a lot of areas we had to use improved techniques for determinism.
The runtime support being added is our next step of tests. Up to now most of our e2e FTR tests have been structural testing of REST and API integration tests. Basically up to now 95% tests are API structural as:
* Call REST input related to a rule such as GET/PUT/POST/PATCH/DELETE.
* Check REST output of the rule, did it match expected output body and status code?
* In some rare cases we check if the the rule can be executed and we get a status of 'succeeded'
With only a small part of our tests ~5%, `generating_signals.ts` was checking the signals being produced. However, we cannot have confidence in runtime based tests until the structural tests have been built up and run through the weeks against PR's to ensure that those are stable and deterministic.
Now that we have confidence and 90%+ coverage of the structural REST based tests, we are building up newer sets of tests which allow us to do runtime based validation tests to increase confidence that:
* Detection engine produces signals as expected
* Structure of the signals are as expected, including signal on signals
* Exceptions to signals are working as expected
* Most runtime bugs can be TDD'ed with e2e FTR's and regressions
* Whack-a-mole will not happen
* Consistency and predictability of signals is validated
* Refactoring can occur with stronger confidence
* Runtime tests are reference points for answering questions about existing bugs or adding new ones to test if users are experiencing unexpected behaviors
* Scaling tests can happen without failures
* Velocity for creating tests increases as the utilities and examples increase
Lastly, this puts us within striking distance of creating FTR's for different common class of runtime situations such as:
* Creating tests that exercise each rule against a set of data criteria and get signal hits
* Creating tests that validate the rule overrides operate as expected against data sets
* Creating tests that validate malfunctions, corner cases, or misuse cases such as data sets that are _all_ arrays or data sets that put numbers as strings or throws in an expected `null` instead of a value.
These tests follow the pattern of:
* Add the smallest data set to a folder in data.json (not gzip format)
* Add the smallest mapping to that folder (mapping.json)
* Call REST input related to exception lists, value lists, adding prepackaged rules, etc...
* Call REST input related endpoint with utilities to create and activate the rule
* Wait for the rule to go into the `succeeded` phase
* Wait for the N exact signals specific to that rule to be available
* Check against the set of signals to ensure that the matches are exactly as expected
Example of one runtime test:
A keyword data set is added to a folder called "keyword" but you can add one anywhere you want under `es_archives`, I just grouped mine depending on the situation of the runtime. Small non-gzipped tests `data.json` and `mappings.json` are the best approach for small focused tests. For _larger_ tests and cases I would and sometimes do use things such as auditbeat but try to avoid using larger data sets in favor of smaller focused test cases to validate the runtime is operating as expected.
```ts
{
"type": "doc",
"value": {
"id": "1",
"index": "long",
"source": {
"@timestamp": "2020-10-28T05:00:53.000Z",
"long": 1
},
"type": "_doc"
}
}
{
"type": "doc",
"value": {
"id": "2",
"index": "long",
"source": {
"@timestamp": "2020-10-28T05:01:53.000Z",
"long": 2
},
"type": "_doc"
}
}
{
"type": "doc",
"value": {
"id": "3",
"index": "long",
"source": {
"@timestamp": "2020-10-28T05:02:53.000Z",
"long": 3
},
"type": "_doc"
}
}
{
"type": "doc",
"value": {
"id": "4",
"index": "long",
"source": {
"@timestamp": "2020-10-28T05:03:53.000Z",
"long": 4
},
"type": "_doc"
}
}
```
Mapping is added. Note that this is "ECS tolerant" but not necessarily all ECS meaning I can and will try to keep things simple where I can, but I have ensured that `"@timestamp"` is at least there.
```ts
{
"type": "index",
"value": {
"index": "long",
"mappings": {
"properties": {
"@timestamp": {
"type": "date"
},
"long": { "type": "long" }
}
},
"settings": {
"index": {
"number_of_replicas": "1",
"number_of_shards": "1"
}
}
}
}
```
Test is written with test utilities where the `beforeEach` and `afterEach` try and clean up the indexes and load/unload the archives to keep one test from effecting another. Note this is never going to be 100% possible so see below on how we add more determinism in case something escapes the sandbox.
```ts
beforeEach(async () => {
await createSignalsIndex(supertest);
await createListsIndex(supertest);
await esArchiver.load('rule_exceptions/keyword');
});
afterEach(async () => {
await deleteSignalsIndex(supertest);
await deleteAllAlerts(supertest);
await deleteAllExceptions(es);
await deleteListsIndex(supertest);
await esArchiver.unload('rule_exceptions/keyword');
});
describe('"is" operator', () => {
it('should filter 1 single keyword if it is set as an exception', async () => {
const rule = getRuleForSignalTesting(['keyword']);
const { id } = await createRuleWithExceptionEntries(supertest, rule, [
[
{
field: 'keyword',
operator: 'included',
type: 'match',
value: 'word one',
},
],
]);
await waitForRuleSuccess(supertest, id);
await waitForSignalsToBePresent(supertest, 3, [id]);
const signalsOpen = await getSignalsById(supertest, id);
const hits = signalsOpen.hits.hits.map((hit) => hit._source.keyword).sort();
expect(hits).to.eql(['word four', 'word three', 'word two']);
});
});
```
### Changes for better determinism
To support more determinism there are changes and utilities added which can be tuned during any sporadic failures we might encounter as well as better support unexpected changes to other Elastic Stack pieces such as alerting, task manager, etc...
Get simple rule and others are now defaulting to false, meaning that the structural tests will no longer activate a rule and run it on task manger. This should cut down on error outputs as well as reduce stress and potentials for left over rules interfering with the runtime rules.
```ts
export const getSimpleRule = (ruleId = 'rule-1', enabled = false): QueryCreateSchema => ({
```
Not mandatory to use, but for most tests that should be runtime based tests, I use this function below which will enable it by default and run it using settings such as `type: 'query'`, `query: '*:*',` `from: '1900-01-01T00:00:00.000Z'`, to cut down on boiler plate noise. However, people can use whatever they want out of the grab bag or if their test is more readable to hand craft a REST request to create signals, or if they just want to call this and override where they want to, then 👍 .
```ts
export const getRuleForSignalTesting = (index: string[], ruleId = 'rule-1', enabled = true)
```
This waits for a rule to succeed before continuing
```ts
await waitForRuleSuccess(supertest, id);
```
I added a required array of id that _waits_ only for that particular id here. This is useful in case another test did not cleanup and you are getting signals being produced or left behind but need to wait specifically for yours.
```ts
await waitForSignalsToBePresent(supertest, 4, [id]);
```
I only get the signals for a particular rule id using either the auto-generated id or the rule_id. It's safer to use the ones from the auto-generated id but either of these are fine if you're careful enough.
```ts
const signalsOpen = await getSignalsById(supertest, id);
const signalsOpen = await getSignalsByIds(supertest, [createdId]);
const signalsOpen = await getSignalsByRuleIds(supertest, ['signal-on-signal']);
```
I delete all alerts now through a series of steps where it properly removes all rules using the rules bulk_delete and does it in such a way that all the API keys and alerting will be the best it can destroyed as well as double check that the alerts are showing up as being cleaned up before continuing.
```ts
deleteAllAlerts()
```
When not explicitly testing something structural, prefer to use the utilities which can and will do retries in case there are over the wire failures or es failures. Examples are:
```ts
installPrePackagedRules()
waitForRuleSuccess()
importFile() // This does a _lot_ of checks to ensure that the file is fully imported before continuing
```
Some of these utilities might still do a `expect(200);` but as we are and should use regular structural tests to cover those problems, these will probably be more and more removed when/if we hit test failures in favor of doing retries, waitFor, and countDowns.
### Checklist
Delete any items that are not applicable to this PR.
- [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
* Adds framework for replacing API schemas
* Update integration tests with new schema
* Fix response type on createRule helper
* Add unit tests for new rule schema, add defaults for some array fields, clean up API schema definitions
* Naming updates and linting fixes
* Replace create_rules_bulk_schema and refactor route
* Convert update_rules_route to new schema
* Fix missing name error
* Fix more tests
* Fix import
* Update patch route with internal schema validation
* Reorganize new schema as drop-in replacement for create_rules_schema
* Replace updateRulesSchema with new version
* Cleanup - remove references to specific files within request folder
* Fix imports
* Fix tests
* Allow a few more fields to be undefined in internal schema
* Add static types back to test payloads, add more tests, add NonEmptyArray type builder
* Pull defaults into reusable function
## Summary
Fixes: https://github.com/elastic/kibana/issues/82148
We have errors and do not generate a signal when a source index already has utilized and reserved the "signal" field for their own data purposes. This fix is a bit tricky and has one medium sized risk which is we also support "signals generated on top of existing signals". Therefore we have to be careful and do a small runtime detection of the "data shape" of the signal's data type. If it looks like the user is using the "signal" field within their mapping instead of us, we move the customer's signal into "original_signal" inside our "signal" structure we create when we copy their data set when creating a signal.
To help mitigate the risks associated with this critical bug with regards to breaking signals on top of signals I have:
* This adds unit tests
* This adds end to end tests for testing generating signals including signals on signals to help mitigate risk
The key test for this shape in the PR are in the file:
```
detection_engine/signals/build_event_type_signal.ts
```
like so:
```ts
export const isEventTypeSignal = (doc: BaseSignalHit): boolean => {
return doc._source.signal?.rule?.id != null && typeof doc._source.signal?.rule?.id === 'string';
};
```
Example of what happens when it does a "move" of an existing numeric signal keyword type:
```ts
# This causes a clash with us using the name signal as a numeric.
PUT clashing-index/_doc/1
{
"@timestamp": "2020-10-28T05:08:53.000Z",
"signal": 1
}
```
Before, this was an error. With this PR it now will restructure this data like so when creating a signal along with additional signal ancestor information, meta data. I omitted some of the data from the output signal for this example.
```ts
{
... Other data copied ...
"signal":
{
"original_signal": 1 <--- We "move it" here now
"parents":
[
{
"id": "BhbXBmkBR346wHgn4PeZ",
"type": "event",
"index": "your-index-name",
"depth": 0
},
],
"ancestors":
[
{
"id": "BhbXBmkBR346wHgn4PeZ",
"type": "event",
"index": "your-index-name",
"depth": 0
},
],
"status": "open",
"depth": 1,
"parent":
{
"id": "BhbXBmkBR346wHgn4PeZ",
type: "event",
"index": "your-index-name",
"depth": 0
},
"original_time": "2019-02-19T17:40:03.790Z",
"original_event":
{
"action": "socket_closed",
"dataset": "socket",
"kind": "event",
"module": "system"
},
}
```
### Checklist
- [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
## Summary
Fixes false positives that can be caused by empty records in the threat list. Previously I would drop a piece of data in an AND clause if it did not exist in the threat list rather than dropping the entire A clause.
* Adds unit tests
* Adds backend integration tests
* Reduces some boiler plate across the integration tests as suggested in earlier PR reviews
Example is if you create a threat list mapping and add records like so without a field/value such as `host.name`:
```json
"_source" : {
"@timestamp" : "2020-09-10T00:49:13Z",
"source" : {
"ip" : "127.0.0.1",
"port" : "1001"
}
```
And then you would create an "AND" relationship against the data like so using `host.name` which does not exist in your list:
<img width="1060" alt="Screen Shot 2020-10-16 at 7 29 45 AM" src="https://user-images.githubusercontent.com/1151048/96264530-8581b480-0f81-11eb-8ab9-16160d55c26b.png">
What would happen is that part of the AND would drop and you would match all the `source.ip` which gives us false positives or unexpected results. Instead, with this PR we now drop the entire AND clause if it cannot find part of a record.
This protection is per record level, so if you have N records where some M set is missing `host.name` only those M record sets would have this "AND" removed.
If you have 1 or more "OR"'s, it will still match the records against those OR's as long as their inner AND clauses have both records in your list match.
### Checklist
Delete any items that are not applicable to this PR.
- [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
## Summary
Fixes a bug where when you update your pre-packaged rules you could end up removing any existing exception lists the user might have already added. See: https://github.com/elastic/kibana/issues/80417
* Fixes the merge logic so that any exception lists from pre-packaged rules will be additive if they do not already exist on the rule. User based exception lists will not be lost.
* Added new backend integration tests for exception lists that did not exist before including ones that test the functionality of exception lists
* Refactored some of the code in the `get_rules_to_update.ts`
* Refactored some of the integration tests to use helper utils of `countDownES`, and `countDownTest` which simplify the retry logic within the integration tests
* Added unit tests to exercise the bug and then the fix.
* Added integration tests that fail this logic and then fixed the logic
### Checklist
Delete any items that are not applicable to this PR.
- [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
resolves https://github.com/elastic/kibana/issues/51099
This formalizes the concept of "alert status", in terms of it's execution, with
some new fields in the alert saved object and types used with the alert client
and http APIs.
These fields are read-only from the client point-of-view; they are provided in
the alert structures, but are only updated by the alerting framework itself.
The values will be updated after each run of the alert type executor.
The data is added to the alert as the `executionStatus` field, with the
following shape:
```ts
interface AlertExecutionStatus {
status: 'ok' | 'active' | 'error' | 'pending' | 'unknown';
lastExecutionDate: Date;
error?: {
reason: 'read' | 'decrypt' | 'execute' | 'unknown';
message: string;
};
}
```
* utlize schema.any() for validation on file in body of import rules request, adds new functional tests and unit tests to make sure we can reach and don't go past bounds. These tests would have helped uncover performance issues io-ts gave us with validating the import rules file object
* fix type check failure
* updates getSimpleRule and getSimpleRuleAsNdjson to accept an enabled param defaulted to false
* updates comments in e2e tests for import rules route
* fix tests after adding enabled boolean in test utils
## Summary
Found in 7.9.0, if you post a rule with an action that has a missing "meta" then you are going to get errors in your UI that look something like:
```ts
An error occurred during rule execution: message: "Cannot read property 'kibana_siem_app_url' of null"
name: "Unusual Windows Remote User" id: "1cc27e7e-d7c7-4f6a-b918-8c272fc6b1a3"
rule id: "1781d055-5c66-4adf-9e93-fc0fa69550c9" signals index: ".siem-signals-default"
```
This fixes the accidental referencing of the null/undefined property and adds both integration and unit tests in that area of code.
If you have an action id handy you can manually test this by editing the json file of:
```ts
test_cases/queries/action_without_meta.json
```
to have your action id and then posting it like so:
```ts
./post_rule.sh ./rules/test_cases/queries/action_without_meta.json
```
### Checklist
Delete any items that are not applicable to this PR.
- [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
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
* https://github.com/elastic/kibana/issues/69632
* Adds a retry loop in case of a network outage/issue which should increase the chances of success
* If there is still an issue after the 20th try, then it moves on and there is a high likelihood the tests will continue without issues.
* Adds console logging statements so we know if this flakiness happens again a bit more insight into why the network is behaving the way it is.
* Helps prevent the other tests from being skipped in the future due to bad networking issues.
The errors that were coming back from the failed tests are in the `afterEach` and look to be network related or another test interfering:
```ts
1) detection engine api security and spaces enabled
01:59:54 find_statuses
01:59:54 "after each" hook for "should return a single rule status when a single rule is loaded from a find status with defaults added":
01:59:54 ResponseError: Response Error
01:59:54 at IncomingMessage.response.on (/dev/shm/workspace/kibana/node_modules/@elastic/elasticsearch/lib/Transport.js:287:25)
01:59:54 at endReadableNT (_stream_readable.js:1145:12)
01:59:54 at process._tickCallback (internal/process/next_tick.js:63:19)
01:59:54
01:59:54 └- ✖ fail: "detection engine api security and spaces enabled find_statuses "after each" hook for "should return a single rule status when a single rule is loaded from a find status with defaults added""
01:59:54 │
01:59:54 └-> "after all" hook
01:59:54 └-> "after all" hook
01:59:54 │
01:59:54 │42 passing (2.0m)
01:59:54 │1 failing
```
So this should fix it to where the afterEach calls try up to 20 times before giving up and then on giving up they move on with the hope a different test doesn't fail.
### Checklist
- [x] [Unit or functional tests](https://github.com/elastic/kibana/blob/master/CONTRIBUTING.md#cross-browser-compatibility) were updated or added to match the most common scenarios
## Summary
Fixes a one liner bug where we were not using waitFor and could have stale views of data from the timeline. This removes that by adding a `waitFor` when setting the signals to be closed, open, in-progress, etc...
This also adds a new `waitFor` for the end to end tests and fixes other tests to use that rather than doing a wait for 5 seconds. This should keep the end to end backend tests fast.
Before this you could sometimes try to re-open 3 signals like below and it would not change the signals to being open but rather re-query the stale view and show the same signals as being closed when they are not closed:
Now with this PR, those signals will show as being re-opened and the closed signals will update correctly within the same UI on the same tab.
### Checklist
- [x] [Unit or functional tests](https://github.com/elastic/kibana/blob/master/CONTRIBUTING.md#cross-browser-compatibility) were updated or added to match the most common scenarios
* add babel support for export type
* bump ts version to 3.9.3
* rebuild kbn-pm
* bump typescript-eslint
* fix error in security plugin UI
* check export as works
* fix app migration type
* use correct test subj attribute
* fix errors from the old PR
* embeddable is already passed in props
* explicitly define type of fetch
* add some types for viz
* fix fetch type p.2
* add null to allow spreading without type errors due to override
* add type guard to fix type error
* cast to any, since cannot assign unknown
* add timestamp to known types
* fix type error in fetch
* fix type error. id is always defined in attibutes
* declare a type
* move ts-ignore to the lines with errors
* declare tuple type explicitly
* mute type error. cannot assign unknown
* fix errors. id is always defined
* fix error type
* fix override errors. id is always defined
* fix error. extends any doesn't work anymore
* fix type error. type is always defined
* env doesn't always contain values
* fix type error
* cast to string
* add: logs is already declared in getNodeLogsUrl
* state is already passed in props
* fix some errors in timelion
* number of fragments is always defined
* 'absolute' is not just string, but value
* TEMP: option is always defined
* always true if cast to promise manually
* both props are always defined
* explicitly define returned SO type
* workaround type
* bump tslib to be compatible with ts v3.9
* test private property
* rebuild kbn-pm
* Fix ts errors for beats management
* Fix type inference broken by the TS 3.9 upgrade
* Fix ingest manager saved object attributes typings
* Fix TS errors in cross_cluster_replication and index_management.
* Fix TS error in Watcher.
* roll back colorRange wrong type
* fix security plugin types
* TypeScript 3.9 fixes for APM
* Fix ColorRange types.
* fix actions & alerts errors. ByGidi
* fix lists error
* More APM fixes
* Remove paramaterization from `removeEmpty in agent config SettingsPage component (it's only used there and doesn't need to be parameterized.)
* Add option chain for case in registerTransactionDurationAlertType
* Cast `overallValue` in transform_metrics_chart
* Use more specific type for custom link filters
* Add more option chaining for local UI filters buckets response
* Remove unused parameters from routes
* Fix getProjection type parameter
* Use destructuring in serviceNodesLocalFiltersRoute to hide `never` error
* Revert `UnionToIntersection` change in `AggregationResponseMap`
Fixes#67804.
* fix platform type error
* Fix visualizations types.
* Fix data plugin types.
* bump TS version to 3.9.5
* Fix telemetry TS errors
* Fix dashboard code
* Adding Canvas Fixes for TS 3.9
* Fix case and security_solution types
* roll back to the old export syntax. new one might cause problems in api-extractor
* update docs
* Fix timelion code
* Fix meta
* Fix types
* fix type errors om ingest_manager
* bump babel deps
* enable private props & methods syntax
* update kbn-pm dist
* whitelist 0BSD license
* use @babel/plugin-proposal-private-methods in default set as well
* disable new babel plugins
* Revert "disable new babel plugins"
This reverts commit 04d959431d.
* cleanup security_solution types
* Fixes type error for newer TypeScript
* update docs
Co-authored-by: Nicolas Chaulet <nicolas.chaulet@elastic.co>
Co-authored-by: Felix Stürmer <stuermer@weltenwort.de>
Co-authored-by: CJ Cenizal <cj@cenizal.com>
Co-authored-by: Larry Gregory <larry.gregory@elastic.co>
Co-authored-by: Nathan L Smith <smith@nlsmith.com>
Co-authored-by: Walter Rafelsberger <walter@elastic.co>
Co-authored-by: Luke Elmers <luke.elmers@elastic.co>
Co-authored-by: Alejandro Fernández Haro <alejandro.haro@elastic.co>
Co-authored-by: Tim Roes <tim.roes@elastic.co>
Co-authored-by: Clint Andrew Hall <clint.hall@elastic.co>
Co-authored-by: Patryk Kopycinski <contact@patrykkopycinski.com>
Co-authored-by: FrankHassanabad <frank.hassanabad@elastic.co>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Nicolas Chaulet <nicolas.chaulet@elastic.co>
Co-authored-by: Felix Stürmer <stuermer@weltenwort.de>
Co-authored-by: CJ Cenizal <cj@cenizal.com>
Co-authored-by: Larry Gregory <larry.gregory@elastic.co>
Co-authored-by: Nathan L Smith <smith@nlsmith.com>
Co-authored-by: Walter Rafelsberger <walter@elastic.co>
Co-authored-by: Luke Elmers <luke.elmers@elastic.co>
Co-authored-by: Alejandro Fernández Haro <alejandro.haro@elastic.co>
Co-authored-by: Tim Roes <tim.roes@elastic.co>
Co-authored-by: Clint Andrew Hall <clint.hall@elastic.co>
Co-authored-by: Patryk Kopycinski <contact@patrykkopycinski.com>
Co-authored-by: FrankHassanabad <frank.hassanabad@elastic.co>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
* Smaller follow ups and bug fixes from: https://github.com/elastic/kibana/pull/68127
* Added unknown to `findDifferencesRecursive`
* Added linter rule to catch NodeJS code in the common folders for both `lists` and `security_solution`
* Removed the Hapi server type from the common folder of lists
### Checklist
* Added unknown to the correct locations
- [x] [Unit or functional tests](https://github.com/elastic/kibana/blob/master/CONTRIBUTING.md#cross-browser-compatibility) were updated or added to match the most common scenarios
* rename siem to security_solution
* rename siem to security solution inside of code
* rename translation keys
* fix snapshot
* replace siem for security solution in tutorial
* missing translation to be renamed
* fix types for api test integration
* updates runner file to match the new path
* change category for kibana settings
* miss renaming in advance settings
* fixes cypress tests
* fix api integration test
* fix new translation
* fix unit test
* update translation i18n
* update translation i18n II
Co-authored-by: Gloria Hornero <snootchie.boochies@gmail.com>
Co-authored-by: Gloria Hornero <snootchie.boochies@gmail.com>
## Summary
Adds backend e2e basic license type tests for the detection engine API. Previously we only had tests for full security space that was platinum based licensing. These tests now cover the basic license test cases. This covers test cases for machine learning to ensure you cannot create machine learning based detection rules under the basic license. Instead those tests will return the expected 403 forbidden.
Testing just the subset of the tests from this PR locally:
```sh
node scripts/functional_tests --config x-pack/test/detection_engine_api_integration/basic/config.ts
```
You do want to go to the jenkins tests on CI and ensure you can see some of the strings such as the newer forbidden messages showing up as passing.
### Checklist
- [x] [Unit or functional tests](https://github.com/elastic/kibana/blob/master/CONTRIBUTING.md#cross-browser-compatibility) were updated or added to match the most common scenarios
2020-05-12 11:03:20 -06:00
Renamed from x-pack/test/detection_engine_api_integration/security_and_spaces/tests/utils.ts (Browse further)
