Alerting feature controls

[mikecote]

Feature controls is designed to give a role access to features within Kibana. The access to a feature can be none, read or all at this time. This would then apply to alerts (none, read or all) and actions (none, read or all).

The problem we encounter is alerting spans different applications within Kibana that themselves may be set to none. When set to none, the user shouldn't see the alerts for the disabled application.

There is an issue on the security team roadmap to allow implementing sub features (#35616). Until it's implemented, I have opened a discuss issue to see what we should do until then (hopefully in a migratable way to it, if anything).

Example

Uptime: None Stack Monitoring: All Alerts: All Actions: All

As you can see, the user shouldn't be able to see Uptime alerts. With the current implementation, they would.

Possible solutions

1. We do nothing until #35616 is implemented. This would allow users to see and edit alerts for applications they don't have access to.

2. Split alert saved objects by solution (Ex: uptime_alert, stack_monitoring_alert, etc). This would leave actions as a generic group but alerts would then automatically get enabled by the application whenever enabled. (Ex: turning read access to Uptime would give you read access to uptime_alert as well). The downside of this is we'll have to do the same for history, like uptime_alert_history.

3. Other solution??

cc @elastic/kibana-stack-services @elastic/kibana-security @alexfrancoeur @peterschretlen

[gmmorris]

I'm struggling to think of a concrete example which requires the producer part of the authorization check. Do we have a situation already which requires this?

This is to address this requirement: Users can only use alert types provided by the applications they have access to

You shouldn't be able to create a siem alert if you don't have access to siem.

Also, is there any situation where plugin a produces an alert-type 1 while plugin b consumes it and we'd like for the user to be able to access the alert-type 1 when they only have access to privileges defined by plugin b? Is this supported?

If I understand the question correctly then - to read the alert they'd need read privileges in both plugins. If they want to modify or create, they'd need all in both.

[gmmorris]

Following a sync up between @elastic/kibana-alerting-services and @legrego we came to the conclusion that the initial model where all access is granted by default to Built-In Alert types to all users opens up a series of security problems that we don't feel comfortable with.

To address this we've now introduced a Kibana Feature called "Built-In Alerts" which grants privileges over these alert types (currently this is only Index Threshold as all other types are solution based). It's important to note that we chose not to call it Alerting as this only applies to the Built-in Alerts. To contract, Alerts Management, will still behave as we originally planned - where access to it is dictated by the user's access to the solutions which provide the Alert Types. This means access to any one of these solutions will grant the user access to alerts management, but they'll only be able to see and interact with the alerts they're privileged to.

@mdefazio I've used the Bell for now, but once we introduce the Action feature this will become confusing. We probably need another icon for 7.9

[gmmorris]

It is still up to solutions to check whether a user is privileged to interact with alerts before opening the flyout, but if they forget to do so, the user is shown the Flyout without the ability to save and the following call out:

Ideally we wouldn't show the Alert fields at all, but sadly this will require some broader changes in the Alerting UI and I'd really like to keep this PR from going any larger than it already is. It'\s also worth noting this is aligned with how the UI currently behaves - as we show the flyout without a Save button if users don't have the alerting:save UI capability in 7.7 & 7.8. We can try and fit in a follow up PR for this in 7.9 (where we'll hide all the fields), assuming the initial PR makes it in soon enough.

[gmmorris]

Encountered an interesting UX question.

If a user has All privileges over a plugin which provides alerts (such as the Built-In Alerts feature) and the Read privilege to Actions, then that user can create the alert types provided by that plugin and is allowed to attach actions to these alerts (as Read grants both the get and execute operations). This means the user will see the list of actions, whether there's a connector or not. This means they can click on an action and, if there's a connector, they can use it.

But, if they click on an action that doesn't yet have a connector (such as PD in this example) they'll see the following:

Now, if a user had *All for Actions, then they could create a connector, but as this user has Read they can't.

There are three options here and this is where the question is:

1. We can hide the actions that have no connectors if the user doesn't have the permissions to create them.
2. We could keep it as is.
3. We could keep it as is but add a callout that says these actions are available, but some kind of administrator will have to be contacted to configure them. This could aid in onboarding usage of actions that have not yet been configured.

I vote for option 3, but wanted to run this past y'all.. and I guess if we do go with option 3, then @gchaps 's help with the copy would be highly appreciated :)

You can see the current behaviour in this draft PR which has both the Alerting and Actions RBAC working side by side: https://github.com/elastic/kibana/pull/70734

[mdefazio]

I agree as well with option 3.

[gmmorris]

I agree as well with option 3.

🙏

Gone with this until we have clearer copy.

[mdefazio]

Working on the icons at the moment. Here are some options to consider:

Alerts-opt2 is used in Security I believe, so we may want to stay away from that. I think the bell (at the moment) still works best based on our usage elsewhere. But I agree we should try and move away from it to something better.

Here it is in the permissions list

Another thing to consider is that with the new navigation setup, we could think about setting the permissions layout up to align with it. So have items grouped under Kibana, Observability, Management. Then we don't need icons for every line item, only the larger grouping.

[gmmorris]

This issue is now blocked on the following: https://github.com/elastic/kibana/issues/70851 Please let me know if you have any thoughts on this issue.

Thanks

[gchaps]

@gmmorris Here is my suggestion:

No PagerDuty connectors Only authorized users can configure a connector. Contact your administrator.

Also note that there is no ending period after "No PagerDuty connectors" because it is a title.

[gmmorris]

Thanks @gchaps!

[gmmorris]

The @elastic/kibana-alerting-services team had a catch up today to discuss the viability of reaching confidence with the RBAC PR by 7.9. We've decided to hold off until 7.10 (meaning we wait until after FF to merge it... possibly a week or so after) as we have a few concerns around the breadth of the impact and have a fear of holding up the 7.9 release.

To make sure we don't keep the PR longer lived than needed and to address the concerns that we have we've decided to do the following:

1. We'll merge the Alerting (https://github.com/elastic/kibana/pull/67157) and Actions (https://github.com/elastic/kibana/pull/70304) PRs into a single PR.
2. The whole team will ring fence time to do broader exploratory testing of the single PR
3. We'll flag to the solution teams (all of whom have already reviewed and approved the existing Alerting PR) that we've included the Actions RBAC in this PR and ask them to run their own broad testing of how alerting is working within their solutions with RBAC in mind to feel more confident about merging these changes.

[gmmorris]

We had a discussion today to assess whether we feel ready to merge the RBAC PR but came to the conclusion that we don't yet feel confident enough to merge.

Broadly speaking the team seems comfortable with the idea of gating the Built-In AlertTypes on a feature, the final blocker we have is that there are concerns around which feature we'll gate on.

In the PR as it stand we gate on a new feature called Built-In Alerts which simply grants privileges to the Index Threshold alert type. We chose not to name it Alerting or Alerts Management as it does not gate the access to alerts management, and we felt that it would be confusing when a user gains access to alerts management (via a solution) and yet doesn't have access to this feature.

The concern raised in the meeting was this: In the case where a new requirement is introduced that requires us to introduce an Alerts Management feature, we'll end up with two features (both Built-In Alerts and Alerts Management) and that isn't ideal and addressing this duplication would be a breaking change.

Discussing the different options we realised that in the case that such a requirement is introduced, we would be able to address it as part of v8.0.0 and the main question we need to answer is this: How likely are we to need an Alerts Management feature before v8.0.0 and can we live with two features existing side by side if we do?.

Our feeling is that:

1. If it's unlikely to happen before v8.0.0 - then we can move forward with the Built-In Alerts feature (possibly renaming it to User Defined Alerts).
2. If it's likely to happen, then we need to decide whether we can live with two features until v8.0.0., and if not we'll likely change the feature to be Alerts Management with some sub-feature privileges or something along those lines

We'll schedule a sync with the team to try and find an answer to that question.

[gmmorris]

We've sent out an email to Kibana Contributers notifying them of the upcoming merge of this PR. For reference, here it is:

Hi all, 👋

If you're supporting customers using the Kibana Alerting framework or leveraging it as part of your solution, you'll probably want to read this. Otherwise - feel free to skip.

---

As we inch closer to the General Availability release of Alerting, we're about to merge a major piece of work into master (aimed at version 7.10) and we wanted to give y'all a heads up beforehand, as it affects a broad cross section of teams.

TLDR (a 3 paragraph TLDR? 😳)

You can think of every Alert in Kibana as the intersection between The Thing I'd Like To Detect and The Context In Which I'd Like To Detect It, and these two things are controlled by Kibana top-level Features. When an Alert is created we assign it a producer, which is the Feature describing the detection and a consumer, which is the Feature defining the context in which the alert will try to detect things. In order to access this alert, a user must be granted privileges to both of these Features: Read privileges will enable them to view the alert, and All privileges will allow them to modify it.

For example, we have the Index Threshold Alert Type, produced by the Built-In Alerts Feature (a new Feature introduced in this PR), which could be leveraged by the Visualize Feature to enable their users to alert when the data feeding a certain visualization hits a threshold value. In order for a user to create such an Alert, they would need the All privilege to both the Visualize and Built-In Alerts Features. Additionally, once that Alert has been created, it will be available to any user with (at least) the Read privilege to both these Features, but hidden from users lacking the Read privilege to either one of them.

In addition we're introducing an Actions Feature, which is used to control the privileges to Actions and Connectors. In order to execute an Action, a user requires the Read privilege to Actions, and in order to create or modify a Connector, they must have All.

The Detailed Explanation 🤓

As you may have noticed in versions 7.7 through to the upcoming 7.9, the security model around Alerting has been a relatively permissive one. Under the existing model, as soon as you have been granted access to a feature which leverages the Alerting Framework, you gain access to all alerts in the system, no matter the context in which those alerts were created. This was always meant to be the starting point from which we would gain real world feedback which would help us figure out what permissions model made sense for Alerting.

Thanks to this initial model we've learned a lot about how users expect an alerting feature to behave and about the relationship between this feature and the host solutions leveraging it. The implementation that we're about to merge is the culmination of these lessons (and dozens of long discussions over zoom & Github Issues) and I'd like to describe the model that we have decided to adopt as it differs slightly from the approach adopted by other features in the stack (though we wouldn't be surprised if a similar approach might be adopted in the future by other cross-solution features).

Who can access an Alert? 💂‍♂️

When a solution wishes to leverage the alerting framework, they register what we refer to as an Alert Type. You can think of an Alert Type as the instructions for detecting whether a certain thing has happened (typically by running some kind of search over data, as we do, you know, search). From that moment on we think of that Alert Type as being produced by that solution.

When a new Alert is created in the framework, it will always be based on one such Alert Type, and it is bound to the context in which it is created within Kibana, which is what we will then refer to as the alert's consumer.

Broadly speaking, the pairing of a producer with a consumer dictates the ownership of this Alert, and by extension, the privileges needed to access, and operate on, this Alert. A user with Read privileges to both Features will be able to view any Alert which is owned by them, and the All privilege would grant the ability to create new Alerts or modify existing ones. Keep in mind though that we default to the lowest common denominator, so Read to one Feature, and All to the other, will be treated as though the user only has Read in such a case.

Below are a couple of examples of how this would work in the real world:

Example # 1: A current use case The Metrics and Logs Solution has registered a Metric Threshold Alert Type which detects when a certain metric has exceeded a certain threshold. As the Alert Type has been registered under the Metrics Feature, it is assigned Metrics as its producer. When a user navigates to the Metrics UI and creates a new Metric Threshold Alert, it is assigned Metrics as its consumer as it was created within the Metrics Feature.

This Alert would now be available to every user who has been granted access to Metrics (and to the Space in which the alert was created), but would be hidden from all other users. Any user with Read to Metrics would be able to see the Alert, while all users with All will be able to modify it.

Example # 2: An upcoming use case On the Alerting Services team's roadmap there is the plan to release a Search Alert Type which detects whenever a certain query against Elasticsearch exceeds a threshold of expected results (this is a simplification obviously, feel free to read about and chime-in with your thoughts over here). This Alert Type will be registered by a new Feature called Built-In Alerts, alongside the existing Index Threshold Alert Type.

When a user navigates to Discover and constructs an intricate query revealing a certain failure case in their system, they can then create a Search Alert which triggers whenever this failure case occurs.

In this case, this new Alert would be assigned Built-In Alerts as its producer, and Discover as its consumer. This means that the Alert would be accessible to every user who has been granted access to both the Discover Feature and Built-In Alerts Feature, but would be hidden from all other users. By extension, users who have been granted only Discover but not User Defined Alerts would not have access to this Alert, and vice versa.

What about Actions & Connectors? 💃🕺🏿

When a user creates an Alert they will often want to attach certain Actions to this Alert which are fired whenever the Alert is triggered. In order to execute an Action, a user must first configure a Connector which provides the executed actions with certain configurations and credentials.

We tend to think of the Connectors as the privileged entity, which would be created by an administrator or power user, and of Actions as the usage of the Connector, which we'd like to see most users have access to.

Up to and including version 7.9, the ability to create Connectors and execute Actions, was granted to any user who has been granted access to any feature leveraging the Alerting framework (just like the Alerts). This too will change as part of the 7.10 release.

We are introducing a new Actions top-level Feature in Kibana, which can be used to grant privileges to roles. If a user needs to create and modify Connectors, then they'll need the All privilege to the Actions Feature. If, on the other hand, all the user needs is the ability to attach actions to Alerts and execute them, then they'll only need the Read privilege to the Actions Feature.

Who can access Alerts & Actions Management? 👩🏽‍🔧

Access to Alerts & Actions management UI is "a first" for us, when compared to other features in Kibana, as it is granted implicitly, rather than explicitly. When a user is granted access to any top-level Feature, we evaluate the privileges provided by that feature, and if they include an Alerting capability, or an Actions capability, then the user will gain access to the management UI.

This allows solutions to leverage the Alerting framework freely without relying on an external feature. This model feels right to us and we're hoping it will make adoption of alerting throughout the Stack and Solutions easier.

What should you do next? 🧗🏼‍♀️

We held off on merging this before the 7.9 FF incase we introduced some regression, but as we're now right at the start of work on 7.10, we hope this will give the teams time to iron out any kinks introduced by these changes and once the PR is merged all you'll have to do is pull. 😬

We've done our best to make the required changes in the Solutions' code ourselves, and have had teammates from across the Stack and Solutions review and support our work throughout, but it's always possible we've missed some things. Feel free to reach out to us in the #kibana-alerting Slack channel if you encounter any odd behaviour * .

• Odd behaviour that relates to RBAC and Alerting only please, other odd behaviour is best referred to #watercaller

[mikecote]

Closing issue now that the work is complete and part of the 7.10 release 🎉 There is a follow up issue to apply the same to the connectors which will happen once we have our first connector provided by a different Kibana plugin (most likely the case action type).