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

[Cases] Add cases information to the alert's schema #147013

Merged
merged 7 commits into from
Dec 15, 2022

Conversation

cnasikas
Copy link
Member

@cnasikas cnasikas commented Dec 5, 2022

Summary

This PR adds case information to the alerts' schema. More information here: #146864.

Checklist

Delete any items that are not applicable to this PR.

For maintainers

@cnasikas cnasikas added Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) Feature:Cases Cases feature labels Dec 5, 2022
@cnasikas cnasikas self-assigned this Dec 5, 2022
@cnasikas cnasikas marked this pull request as ready for review December 13, 2022 18:10
@cnasikas cnasikas requested review from a team as code owners December 13, 2022 18:10
@elasticmachine
Copy link
Contributor

Pinging @elastic/response-ops (Team:ResponseOps)

@elasticmachine
Copy link
Contributor

Pinging @elastic/response-ops-cases (Feature:Cases)

@cnasikas cnasikas added release_note:skip Skip the PR/issue when compiling release notes v8.7.0 labels Dec 13, 2022
@cnasikas
Copy link
Member Author

@elasticmachine merge upstream

@cnasikas cnasikas mentioned this pull request Dec 14, 2022
8 tasks
Copy link
Contributor

@ymao1 ymao1 left a comment

Choose a reason for hiding this comment

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

LGTM

@marshallmain
Copy link
Contributor

This PR adds the field to the schema, but where/when are we going to populate this field in the alert documents? Is this field written at some point after alert creation?

@cnasikas
Copy link
Member Author

Hey @marshallmain! When a user attaches an alert to a case, the cases plugin will update the alert's data to include the case ID it is attached to. The goal is to show in the alerts table, for each alert, the cases the alert is attached to. This work will be done in subsequent PRs. You can read more about it at #146864.

@@ -51,6 +51,9 @@ const ALERT_SUPPRESSION_START = `${ALERT_SUPPRESSION_META}.start` as const;
const ALERT_SUPPRESSION_END = `${ALERT_SUPPRESSION_META}.end` as const;
const ALERT_SUPPRESSION_DOCS_COUNT = `${ALERT_SUPPRESSION_META}.docs_count` as const;

// Fields pertaining to the cases associated with the alert
const ALERT_CASES_IDS = `${ALERT_NAMESPACE}.cases_ids` as const;
Copy link
Contributor

Choose a reason for hiding this comment

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

Sorry to be annoying but we did agree on case_ids

Copy link
Member Author

Choose a reason for hiding this comment

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

Done!

@elastic elastic deleted a comment from XavierM Dec 15, 2022
@cnasikas cnasikas requested a review from XavierM December 15, 2022 08:02
Copy link
Contributor

@CoenWarmer CoenWarmer left a comment

Choose a reason for hiding this comment

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

LGTM

@kibana-ci
Copy link
Collaborator

💚 Build Succeeded

Metrics [docs]

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id before after diff
@kbn/rule-data-utils 93 94 +1

Async chunks

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

id before after diff
observability 502.7KB 502.7KB +54.0B
securitySolution 10.1MB 10.1MB +269.0B
triggersActionsUi 690.4KB 690.5KB +45.0B
total +368.0B

Page load bundle

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

id before after diff
apm 30.7KB 30.8KB +25.0B
cases 127.1KB 127.2KB +25.0B
infra 85.9KB 85.9KB +25.0B
observability 80.1KB 80.1KB +64.0B
synthetics 25.3KB 25.4KB +25.0B
triggersActionsUi 110.2KB 110.2KB +64.0B
total +228.0B
Unknown metric groups

API count

id before after diff
@kbn/rule-data-utils 96 97 +1

ESLint disabled in files

id before after diff
osquery 1 2 +1

ESLint disabled line counts

id before after diff
enterpriseSearch 19 21 +2
fleet 61 67 +6
osquery 109 115 +6
securitySolution 445 451 +6
total +20

Total ESLint disabled count

id before after diff
enterpriseSearch 20 22 +2
fleet 70 76 +6
osquery 110 117 +7
securitySolution 521 527 +6
total +21

History

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

cc @cnasikas

Copy link
Contributor

@XavierM XavierM left a comment

Choose a reason for hiding this comment

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

Super, let's go!

@cnasikas cnasikas merged commit 9fcb5d5 into elastic:main Dec 15, 2022
@cnasikas cnasikas deleted the cases_alert_schema branch December 15, 2022 13:56
@kibanamachine kibanamachine added the backport:skip This commit does not require backporting label Dec 15, 2022
cnasikas added a commit that referenced this pull request Feb 11, 2023
… to a case (#147985)

## Summary

PR #147013 extended the alert's
schema to be able to store the case id an alert is attached to. This PR
adds the ability to update the `case_ids` field of the alert when an
alert is attached to a case. It also limits the number of cases an alert
can be attached to ten.

### Permissions

A user to attach an alert to a case needs a) to have read access to the
solution via the kibana feature privileges and b) to have write access
to the case. The user that did the request should not need to have
written access to the alert for Cases to add the case ID to the alert's
data. For that reason, the alert data client is extended to cover this
particular need: update an alert even if the user has read access.

## Alerts client aside

For future reference, the alerts client uses the request to check the
kibana feature authorization but uses the internal system user to
perform any write and get operations on the alert indices themselves.
For security solution this means that a user with only read access to
the security solution kibana feature, write access to cases, and no read
or write access to the alert indices could attach an alert to a case and
have the case id stored in the alert.

For observability, users intentionally do not have access to the alert
indices so we want to bypass the authorization check on the indices
which is why the current alerts client uses an es client that is an
internal system user.

Related issue: #146864

### 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

### For maintainers

- [x] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
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 Feature:Cases Cases feature release_note:skip Skip the PR/issue when compiling release notes Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) v8.7.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants