Users in the alerting context

[rylnd]

I started this discussion with #62886, but I believe that there's a broader need for user information within alerting. The simplest use case is retrieving user information for auditing purposes.

User retrieval is (to my knowledge) only accessible via security.authc.getCurrentUser, which itself requires a KibanaRequest object, so we're back to where we were with #62886, where alerting must either provide a request or its own interface to accomplish the same.

Another aspect of this issue: in the auditing scenario, the distinction between "user-initiated request" and "alert-initiated request" may be a meaningful one worth codifying (although it could also be done downstream).

[elasticmachine]

Pinging @elastic/kibana-alerting-services (Team:Alerting Services)

[rylnd]

After talking with @jgowdyelastic it sounds like ML is intending to add capabilities checks to all of their plugin's services. In the current implementation, that would require a KibanaRequest in addition to the scoped client provided by #62886.

TL;DR this is about to become a blocker on either the ML capabilities work, or SIEM's integration with ML and Alerting.

[mikecote]

Note for alerting team:

Based on the menton here: #39430 (comment), this issue will expose the fake request object to alert and action executors and have clear documentation what breaking changes are coming that will remove the fake request and explain why its exposed in the meantime. This should help developers understand possible debt they're taking on with the usage of the fake request.

This issue should also remove the getScopedCallCluster service from alert and actions.

[mikecote]

cc @arisonl

[mikecote]

@rylnd the alerting team is doing some 7.12 release planning and I was wondering if SIEM was still waiting on this issue to integrate with ML? We will work on it in 7.12 if that is the case 🙏 but wanted to make sure

[mikecote]

Moving from 7.12 - Candidates to 7.x - Candidates.

[mikecote]

Moving from 7.x - Candidates to 8.x - Candidates (Backlog) after the latest 7.x planning session.

[mikecote]

Closing due to lack of request. Let's re-open if we have some recent use cases and we can explore exposing the request object.