[ResponseOps][Alerts] Fix stack alerts plugin API and page permissions

[umbopepato]

Summary

• Adds the rac api privilege to stackAlerts plugin's Kibana feature registration (done in [ResponseOps][Alerting] Fix stackAlerts plugin missing rac API auth scope #193948)
• Extends the fetchAlertsIndexNames API to return a boolean flag that indicates if the end user (not Kibana user) has (at least) read index privileges on the alert index name returned by the API, regardless of the alerting authorization
• Uses the flag mentioned in the previous point to only render the alert filter controls bar if the user has personal read access to the indices targeted by the current feature ids
• Only uses feature ids the user has access to for the stack alerts page (shouldn't be necessary, but it restricts the resulting index pattern, which is helpful to better identify when to show/hide the filter controls)
• Fixes a small issue that caused useAlertsDataView to return an intermediate empty data view object while loading

To verify

1. Create rules that fire alerts in Stack management, Observability and Security
2. Wait for alerts to be created
3. Check that the stack alerts page renders correctly and shows alerts coherent with the feature filter and other KQL bar filters
4. Create a role with only Stack Management > Rules : Read privilege
5. Create a user with that role
6. In another window, open Kibana with the newly created user
7. Check that the Stack Management > Alerts page renders correctly, only showing alerts from stackAlerts rule types and without the filter controls bar
8. Add read privilege to the .alerts-* index to the role
9. Reload the alerts page as unprivileged user and check that the filter controls are now visible
10. Gradually add other solution permissions and check that the alerts shown in the page change accordingly

References

Fixes #186451

Checklist

Delete any items that are not applicable to this PR.

• Unit or functional tests were updated or added to match the most common scenarios

[umbopepato]

/ci

[umbopepato]

/ci

[umbopepato]

/ci

[umbopepato]

/ci

[umbopepato]

/ci

[umbopepato]

/ci

[umbopepato]

/ci

[elasticmachine]

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

[JiaweiWu]

question about this field, shouldn't we do this implicitly on the backend based on the request user? Seems a bit odd to expose a field like this to the client.

[umbopepato]

The main use case is authorizing views like the filter controls bar that are unaware of the alerting RBAC and directly work with the indices. In these cases we don't have a way to know if the end user (besides their alerting permissions) has direct read access to the alerting indices. Since this is particularly useful for unprivileged users, checking the index permissions directly on the client seems a bit fragile: the user should have access to the plugin(s) that expose the privilege check functionality, which is unlikely in this case.
I could be missing a more straightforward way to check this so please if you have any ideas let me know 🙂

[JiaweiWu]

Right but this means anyone could "spoof" the read index privilege by passing this field? At that point you might as well just always assume the user has privilege

In these cases we don't have a way to know if the end user (besides their alerting permissions) has direct read access to the alerting indices.

Since we have the request, we'll have the user, can't we check the user's index privilege? unless we're someone making a request on behalf of another user or something.

the user should have access to the plugin(s) that expose the privilege check functionality

Then how does the client know of the user's index privilege but not the server? The client had to get it's data from somewhere.

[umbopepato]

Right but this means anyone could "spoof" the read index privilege by passing this field? At that point you might as well just always assume the user has privilege

Not sure I follow you here. This is set by the server, not the client, (I assume) similarly to how the capabilities object informs the client on what the user has access to for example.

Since we have the request, we'll have the user, can't we check the user's index privilege? unless we're someone making a request on behalf of another user or something.

This privilege is not instrumental to authenticating the alerts/_index request itsefl, but to tell the client if the user has access to the ES alerts index itself. Unprivileged users might not have a direct access but still be able to indirectly access them through the alerting APIs.

The controls embeddable thought works directly with the ES indices, not through the alerting APIs. That's why we need to check if the user has "direct" access to those indices: to hide the controls and avoid 403 errors.

[umbopepato]

If you create a Role with only Security read capabilities without access to the indices and try to open the Security > Alerts page, you'll see a missing authn prompt that pretty much exemplifies this situation. We'd have to do something similar with the controls embeddable

[kibana-ci]

💛 Build succeeded, but was flaky

• Buildkite Build
• Commit: 2306660

Failed CI Steps

• FTR Configs #75

Test Failures

• [job] [logs] FTR Configs #75 / Reporting Functional Tests with Security enabled Access to Management > Reporting Download report "before all" hook for "user can access download link"

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
alerting	234	235	+1
cases	807	808	+1
observability	1045	1046	+1
securitySolution	5654	5655	+1
triggersActionsUi	790	791	+1
total			+5

Async chunks

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

id	before	after	diff
alerting	92.4KB	92.7KB	+271.0B
cases	480.1KB	480.4KB	+269.0B
observability	460.1KB	460.3KB	+269.0B
securitySolution	17.9MB	17.9MB	+279.0B
triggersActionsUi	1.6MB	1.6MB	+92.0B
total			+1.2KB

Page load bundle

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

id	before	after	diff
triggersActionsUi	121.7KB	122.0KB	+279.0B

History

• 💛 Build #230339 was flaky b367327
• 💛 Build #230184 was flaky c0ca606
• 💚 Build #230144 succeeded c0ca606
• 💔 Build #230053 failed e504d0e3f81c8006bdc4a5b910006b250c2b4f1f
• 💔 Build #230024 failed 2ede3c681fd02d9fd159bc06ca854c5d179c1d89
• 💔 Build #230010 failed e57eca25c4dc0a8571ce1fd4733bdf6a84970c9a

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

[js-jankisalvi]

Verified locally for stack and observability rules. Works as expected. 👍

[js-jankisalvi]

Nice 😄

[js-jankisalvi]

If we are going to use this field at the end, could you please add some tests for hasReadIndexPrivilege: true behaviour?

[kdelemme]

obs-ux-management code change lgtm