[Alerting] Restricting alerting health API to users with access to rules

[ymao1]

Addresses part of #102100

Summary

Added a check to the alerting framework health API to ensure that users have access to at least one rule type before providing health information. Takes advantage of the existing list_rule_types API which returns all rule types that a user has access to.

To Verify

• Create a role that does not have access to any rule type. Create a user for that role
• Verify that when accessing /api/alerting/_health as user, user receives 403 Forbidden response
• Update role to allow access to one or more rule types
• Verify that user with updated role can successfully access /api/alerting/_health

Checklist

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

[elasticmachine]

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

[ymao1]

@elasticmachine merge upstream

[ymao1]

@elasticmachine merge upstream

[chrisronline]

LGTM!

[YulNaumenko]

Changes LGTM, but I didn't find any comment under the related issue, which will lead to this solution. As I understood, this is just a partial restriction (for the users which do not have access to any rule type) and it doesn't answer all the questions from the related issue. I assume it was a verbal discussion, but it would be nice to provide the comment or document it somewhere.

[ymao1]

Changes LGTM, but I didn't find any comment under the related issue, which will lead to this solution. As I understood, this is just a partial restriction (for the users which do not have access to any rule type) and it doesn't answer all the questions from the related issue. I assume it was a verbal discussion, but it would be nice to provide the comment or document it somewhere.

@YulNaumenko Thanks for the review! Can you clarify why you consider this just a partial restriction and which questions it doesn't answer from the related issue? Believe there were several discussions during triage where it was discussed that having this API open to all users was considered a bug and that this should be restricted to users of alerting. Is there something more that this PR can do to address the issue?

[YulNaumenko]

@YulNaumenko Thanks for the review! Can you clarify why you consider this just a partial restriction and which questions it doesn't answer from the related issue? Believe there were several discussions during triage where it was discussed that having this API open to all users was considered a bug and that this should be restricted to users of alerting.

I think current PR is an elegant solution for the problem with a public access to the health API. Only one concern I had is about loosing track about agreement on the approach. Basically I was confused by the last comment #102100 (comment) which proposed to do something different.

Is there something more that this PR can do to address the issue?

I don't know if something is needed to be addressed. This telemetry PR #119349 is also related to the issue, so I'm wonder if something more is needed in the future.

[ymao1]

@YulNaumenko Gotcha. Sorry for the confusion. This PR was meant to address Should the alerting framework health API work only for users who access the alerting APIs?, which was not discussed in the issue due to it being a straightforward answer (Yes) and a straightforward approach. The discussion in the issue and the last comment was surrounding the task manager health API, where we decided not to add the restriction for now and instead add telemetry to determine how many users would be affected.

[ymao1]

@elasticmachine merge upstream

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: b016d92
• Storybooks Preview

Metrics [docs]

✅ unchanged

History

• 💚 Build #8343 succeeded f116a0b
• 💚 Build #8127 succeeded 85cf5a5
• 💛 Build #7478 was flaky 2295986

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

cc @ymao1