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.

Sign up for GitHub

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

Jump to bottom

[Response Ops][Alerting] Enhance AlertsClient to support AAD payload #156443

Closed
ymao1 opened this issue May 2, 2023 · 1 comment · Fixed by #158404
Closed

[Response Ops][Alerting] Enhance AlertsClient to support AAD payload #156443

ymao1 opened this issue May 2, 2023 · 1 comment · Fixed by #158404
Assignees
@ymao1
Labels
Feature:Alerting/Alerts-as-Data Issues related to Alerts-as-data and RuleRegistry Feature:Alerting Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)

Comments

@ymao1
Copy link
Contributor

ymao1 commented May 2, 2023

Part 2 of Phase 2 of FAAD:

This issue covers enhancing the AlertsClient created in #156442 to support rule type specific information in the alert document.

In this step we will:

  • create a public API for reporting alerts back to the framework
  • update the AlertsClient to process the reported alerts instead of proxying the alert factory processing
  • at the end of rule execution, alert documents with rule type specific payloads (in addition to the framework fields) will be written to the appropriate index if the rule type has opted in.
  • thorough functional tests

Reference: #149375
@ymao1 ymao1 mentioned this issue May 2, 2023
Closed
@botelastic botelastic bot added the needs-team Issues missing a team label label May 2, 2023
@ymao1 ymao1 added Feature:Alerting Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) Feature:Alerting/Alerts-as-Data Issues related to Alerts-as-data and RuleRegistry labels May 2, 2023
@elasticmachine
Copy link
Contributor

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

@botelastic botelastic bot removed the needs-team Issues missing a team label label May 2, 2023
@ymao1 ymao1 moved this from Awaiting Triage to Todo in AppEx: ResponseOps - Execution & Connectors May 2, 2023
@ymao1 ymao1 mentioned this issue May 17, 2023
Merged
@ymao1 ymao1 self-assigned this May 18, 2023
@ymao1 ymao1 moved this from Todo to In Progress in AppEx: ResponseOps - Execution & Connectors May 23, 2023
@ymao1 ymao1 mentioned this issue Jun 1, 2023
Merged
1 task
@ymao1 ymao1 moved this from In Progress to In Review in AppEx: ResponseOps - Execution & Connectors Jun 5, 2023
@ymao1 ymao1 mentioned this issue Jun 5, 2023
Closed
ymao1 added a commit that referenced this issue Jun 7, 2023
@ymao1
[Response Ops][Alerting] Update FAAD AlertsClient to support AAD pa…
3aa3f04 
…yload (#158404)

Resolves #156443,
#156445

## Summary

- Updates `AlertsClient` with `create` API that allows rule executors to
report alerts with AAD payload, along with the values for `actionGroup`,
`context` and `state`. This proxies the `LegacyAlertsClient` to create
alerts via the alerts factory but also saves the reported payload
- When the alert doc is bulk written at the end of rule execution, the
AAD payload (if specified) is included in the alert document
- Deprecates the alert factory that is passed into the rule executors,
but this PR does not remove or replace usages of the alert factory
- Expose `AlertsClient` services to the rule executors. Note that this
PR does not migrate any rule type to use this service.

This PR does not opt any rule types into writing the AAD payload or
using the AlertsClient API but updates the AAD functional test to do so.
To test it out with the ES query rule type, use the following commit:
1b1e139

## Followup issues
- This PR does not add a recovery API to the FAAD AlertsClient so alerts
reported via the new alerts client currently do not have a way of
specifying recovered payload.

## To Verify
- Verify that rule registry rule types still work as expected
- Verify that non rule-registry rule types still work as expected
- Check out [this
commit](1b1e139)
which onboards the ES query rule type onto FAAD. Create an ES query rule
that alerts and then recovers and verify that the alert documents look
as expected. Alternatively, you can modify your own rule type to
register with FAAD and write alerts and verify that the alert documents
look as expected.

### 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@ymao1 ymao1

Labels
Feature:Alerting/Alerts-as-Data Issues related to Alerts-as-data and RuleRegistry Feature:Alerting Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)
Projects
No open projects
AppEx: ResponseOps - Execution & Connectors
Status: Done
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

[Response Ops][Alerting] Update FAAD AlertsClient to support AAD payload ymao1/kibana
2 participants
@ymao1 @elasticmachine