[ResponseOps][Alerting] Research of exposing alerting filtering controls

[cnasikas]

The Alerts page in the stack management page shows controls that users can use to filter the alerts in the alerts table. O11y is interested in using the same controls for their alerts table. Controls use data views. However, our alerting RBAC model and the difference between the security solution and the rest of the solutions regarding RBAC make it difficult to use data views. Therefore, we need to be able to export controls that work with our RBAC model that the solutions can use.

Requeriments

• Rely only on rule type IDs to get the authorized indices
• Users should not get fields from indices they do not have access
• Users who do not have ES privileges to the alerting indices should be able to see the fields they can access based on the Kibana privilege model. This should apply only to non-security solution rule types
• Security solution rule types still work with their ES authorization model along with the Kibana privilege model
• Mixing security solution types with other rule types should work out of the box, and consumers should not have to be aware of this implementation detail
• Value autocompletion (stretch)
• Move the alerting filtering controls from the @kbn/alerts-ui-shared package to a dedicated @kbn/@kbn/response-ops-alert-filter-controls

Some of the above requirements may not be feasible, or the complexity of satisfying them is unjustified. For this reason, we should first research the feasibility of the requirements and think about how we want to approach the issues. It is worth mentioning that we can move a lot of the work to the backend, where an API can return to the UI all the needed information related to alerting, for example, authorized indices and fields, and hide all the complexity related to the differences of the RBAC model.

DoD

• Gather requirements of how solutions want to be used by solutions
• Research the feasibility of the requirements and propose a solution

Related: https://github.com/elastic/kibana/issues/206711

cc @maryam-saeidi

[elasticmachine]

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

[jasonrhodes]

Thanks for explaining this, @cnasikas -- just so I'm clear, the problem this would solve is that an observability user might be given access to alerting but, for some reason, not given access to read from .alerts- indices, yes? I am wondering if that's a case we should solve for, as it seems to add a lot of custom auth logic into the app. Worth talking through, probably.

[cnasikas]

Hey, @jasonrhodes. The current RBAC alerting model is that o11y users need to configure only their Kibana privileges and not any ES privileges to use alerting features throughout the o11y application. The alerting controls depend on the Kibana controls, which work with data views and are unaware of our RBAC model. @maryam-saeidi tried to use our component as it is right now, but because the Kibana controls query the alerting indices directly (authorized as the current user), we get permission errors because even if the user has access to o11y, it did not have ES privileges to access the alerting indices. This effort is to figure out ways to bypass this problem and enable solutions to consume our alerting controls component without bothering with all the nuances of the alerting RBAC model.