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 Feature Controls - Feature privileges besides all and read #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

[bmcconaghy]

1 seems better to me as it would involve less ongoing work, but it also might take a while to land.

[kobelb]

Ignoring the technical implementation and what's currently possible, which of the following would be the ideal use experience:

1. Uptime and Stack Monitoring themselves have a sub-feature of Alerting.
2. The Alerting feature has sub-features for Uptime and Stack Monitoring.
3. Both of the above.

If we pursue option 1, when the user is granted "All" access to Uptime and Stack Monitoring, it'd make the most sense for users to automatically get the Alerting sub-feature and be able to create and view alerts for the specific feature.

Where-as with option 2, when the user is grated "All" access to Alerting, they'd be able to use Alerts in every application.

There's also an option 3 where we support both. This gets somewhat confusing, as roles and privileges in the ES model are additive. So if the user is granted "All" access to Stack Monitoring and "None" access to Alerting, they'd still be able to use Stack Monitoring alerts.

[mikecote]

In regards to @kobelb's suggestions, I was thinking option 1.

Could this get interesting when determining if we show the alerting app or not? Since there won't be a single privilege to look for? Unless we can do an or between privileges to give access to the alerting UI.

[legrego]

Could this get interesting when determining if we show the alerting app or not? Since there won't be a single privilege to look for?

Is it possible that the alerting app is its own feature, distinct from creating in-app alerts themselves? Similar to how users create various saved objects within the discover, visualize, and dashboard applications today, but there is a separate "Saved Objects Management" feature which exposes that management app to end users.

[mikecote]

@legrego The alerting app would be the same scenario so we could do it that way. That resolves my concern.

[kobelb]

I don't know if we should be mirroring the "Saved Object Management" experience entirely.

If we want for users to be able to create alerts from within Uptime when they're given the Uptime "All" privilege, I assume that these alerts themselves will then show-up within the "alerting app" itself. If we always treat "Alerting" as a sub-feature of the applications in which it's integrated, are there additional privileges which need to be granted. If so, what are they?

[mikecote]

I can't think of any extra privileges that would have to be granted. A new privilege to "show" the alerting UI would pretty much be it unless we can compute the capability.

Also, I guess alerting wouldn't be much of a feature for users without read access to actions 🤔

[kobelb]

I can't think of any extra privileges that would have to be granted. A new privilege to "show" the alerting UI would pretty much be it unless we can compute the capability.

We can derive this from the sub-feature privileges. If the user has any access to alerting, we can then display the alerting application.

Is there a generic "create user defined alert" which we'll want to allow, similar to being able to free-form specify the Watcher job definitions?

Also, I guess alerting wouldn't be much of a feature for users without read access to actions 🤔

This becomes somewhat complicated, since actions are used outside of Alerting.

[mikecote]

Had a quick chat with @kobelb, adding an update below.

Is there a generic "create user defined alert" which we'll want to allow, similar to being able to free-form specify the Watcher job definitions?

In the future yes with kibana expressions. Users would be able to create alerts from the alerting app. We can register a separate feature for those.

This becomes somewhat complicated, since actions are used outside of Alerting.

Providing a tooltip indicating alerts require read on actions should be sufficient.

[alexfrancoeur]

Is there a generic "create user defined alert" which we'll want to allow, similar to being able to free-form specify the Watcher job definitions?

As Mike mentioned above, this is functionality we will want at some point. Whether it's through expressions or even forms for simple generic alert types. Does this mean we go down the route of @kobelb's option 3? Or provide an experience similar to saved object management?

The saved object management approach sounds more applicable, especially if we end up introducing views for alert history and state. I could see a scenario (though I'm not sure how common it'd be) where users might want an overview of all alerts but admins do not want to provide CRUD permissions. Basically, a role that provides read only access to an alerting app with state / history and nothing else.

This becomes somewhat complicated, since actions are used outside of Alerting.

This will also be relevant for "Kibana Actions" (#32371) available in future dashboard panels. Dashboard end users will want the ability to add an action / interaction to a dashboard panel that sends to slack, email, etc. or fire off a webhook but may not have write access to actions.

[peterschretlen]

Technical implications aside, alerting is a service provided by Kibana, I think access should be controlled in the context of the consumer of that service (the app or solution). That would favour the 1st option Brandon described.

Even if sub-features were added though, it seems the problem with alerting isn't providing more granular control to the list of "privilege actions" associated with a privilege. It seems like the issue is filtering data for a certain type of saved object? I'm not clear how sub-features would address that problem.

[peterschretlen]

It looks like this is the current set of "privilege actions" we have for alerting:

        "saved_object:8.0.0:alert/bulk_get",
        "saved_object:8.0.0:alert/get",
        "saved_object:8.0.0:alert/find",
        "saved_object:8.0.0:alert/create",
        "saved_object:8.0.0:alert/bulk_create",
        "saved_object:8.0.0:alert/update",
        "saved_object:8.0.0:alert/delete",

Am I understanding right the problem - these privilege actions right now provide access to all alerts, and we need to figure out how to restrict access to only a subset?

[legrego]

Am I understanding right the problem - these privilege actions right now provide access to all alerts, and we need to figure out how to restrict access to only a subset?

Yep, that's correct. If each alert type had its own corresponding saved object type, then the existing privilege model would "just work" once sub-features are implemented. If all alerts share a common saved object type, then we'll need to figure out a way to restrict access to only a subset.

[mikecote]

It seems like the issue is filtering data for a certain type of saved object? I'm not clear how sub-features would address that problem.

Up until now, I was under the impression the sub-features issue would automatically filter data on an object type based on access (subType = "apm" || "uptime"). This isn't the case.

Now that I am on the same page. The issue will diverge into "what technical challenges are we facing to implement feature controls" and discuss how we should solve them.

1. If creating a saved object type per consumer (apm, stack monitoring, uptime, etc). What developer experience can we provide? The saved object types get created before any plugin initializes.
2. How will having a saved object type per solution impact event logging? (event logging feature controls?, event logging saved object types? etc)
3. Is there a better alternative?

I will add more questions over time.

[peterschretlen]

I wonder if this needs to be solved at the Saved Objects level?

It seems like anytime we have one feature (alerting) that intersects with other features (uptime, stack monitoring, apm, ...) we are going to encounter this problem.

Maybe event/audit logging is another instance of this. Having an alerting saved object type per feature might work but feels like the wrong long term approach, especially as we add more types and more stack services features.

[peterschretlen]

@rudolf would be curious to hear your thoughts on this issue - some way to extend Saved Objects namespaces (or filtering) beyond just type? Wondering if this has ever come up before ( I looked through GH but there was nothing obviously similar). If the idea has merit I'll open a separate issue we can continue discussion there.

[kobelb]

We should be able to extend the saved-object authorization logic to allow validation using a field in addition to type, or in-place of type. This would likely fall into something the @elastic/kibana-security team would be responsible for.

Do we intend for all consumers of alerting to abide by the same "schema" and have the same attributes as each other? Or is there perhaps additional justification for using discrete saved-object-types, but allowing these to be dynamically specified by the alerting plugin and its registered consumers?

[rudolf]

@peterschretlen I'm not aware of a similar requirement coming up in the past.

Telemetry is somewhat similar but doesn't require the special authorization needs of actions. Here we use the saved object per consumer model but there is a specific requirement that the "schema" be customizable per consumer.

It seems to me the discussion boils down to do we want (a) saved objects types per consumer or (b) one actions saved object type for all actions. If (b) we need to discuss how the security team can make the authorization model sufficiently powerful. I don't see a strong argument for going with either one, so if authorization seems easier in (a) that seems like the desired way to go.

In my own head I got a bit tripped up by saved object "ownership", the dashboard plugin owns the dashboard type and associated data. But this really is only because the dashboard plugin was the one who declared this mapping. If another plugin created a dashboard_action type that data wouldn't belong to the dashboard plugin, it would belong to the plugin that created that mapping.

Assuming alerting doesn't have the need for custom schemas per solution, we would want actions to "own" all actions saved objects. All this means is in the context of solution (a) is the actions plugin would be responsible for creating the saved object mappings (and possibly future migrations) required to use this plugin.

I haven't investigated this in depth, so there might be some technical challenges, but in the New Platform I imagine that Plugins would "register" Saved Object mappings during setup lifecycle instead of statically defining all mappings upfront. This would allow the actions plugin to register new Saved Object types/mappings on behalf of action consumers. So in the dashboard plugin's setup() lifecycle, it declares it's intent to use actions, the actions plugin would then "register" a 'dashboard_action' Saved Object type/mapping.

I think this would solve the developer experience problem @mikecote brought up, a consumer just has to call the right actions API's, no need to define mappings or schemas. These types are fully owned/controlled by the actions plugin.

Are there big advantages in going with option (b) that I'm missing?

@mikecote Can you explain what you mean with the following, what is event logging in this context?:

How will having a saved object type per solution impact event logging?

[mikecote]

@kobelb

Do we intend for all consumers of alerting to abide by the same "schema" and have the same attributes as each other?

Yes. Where the attributes start differentiating is within alertTypeParams attribute that is specific per alert type. This attribute is marked as enabled: false within Elasticsearch so the mappings within aren't defined. (Note: one plugin can define multiple alert types). By having everything within alertTypeParams we do lose the searchability within it, but have no requirement at this time.

@rudolf

Just changing terminology from actions to alerts. Action saved objects won't be restricted by application and will also be managed separately (by admins for example).

I haven't investigated this in depth, so there might be some technical challenges, but in the New Platform I imagine that Plugins would "register" Saved Object mappings during setup lifecycle instead of statically defining all mappings upfront.

We may have a chicken and egg problem with this if ever the alerting plugin "setup" creates / registers the mappings. The alerting "setup" function is called before the plugins that dependent on it. Only at the other plugins "setup" we would be able to register mappings and the alerting plugin would have to expose its mappings on "start" for it to possibly work?

Are there big advantages in going with option (b) that I'm missing?

This is more a disadvantage of option (a) but I can see the index.mapping.total_fields.limit (1000 default fields) eventually getting hit. I'm not sure how big deal this may be. If we have 13 fields in the alerting mappings and 8 fields for event logs X 10 solutions using alerting, we'd be adding 210 fields ((13 + 8) * 10) to the .kibana index. Again not sure if this is really a problem or not but wanted to take note.

This is also assuming we repeat object types for even logs (apm-alerting-event-log, uptime-alerting-event-log, etc) in order to follow the same privilege model as alerts.

Can you explain what you mean with the following, what is event logging in this context?:

How will having a saved object type per solution impact event logging?

This is something @pmuellr is working on to capture events from task manager, alerting and actions plugin. It's similar to audit but captures different kind of information (when a task started, finished, when an alert type executed, when an alert type failed to execute, etc). You can find the WIP here: #45081.

[kobelb]

Yes. Where the attributes start differentiating is within alertTypeParams attribute that is specific per alert type. This attribute is marked as enabled: false within Elasticsearch so the mappings within aren't defined. (Note: one plugin can define multiple alert types). By having everything within alertTypeParams we do lose the searchability within it, but have no requirement at this time.

This sounds like a different "schema", and we're just working around this by not mapping it in Elasticesearch. Would we have one to many alert-types per "consumer of alerting"?

[mikecote]

Would we have one to many alert-types per "consumer of alerting"?

Yes. Though they can be shared across applications as well. (Ex: SIEM using an ML alert type that would call SIEM actions). Down the road we'll try to provide some alert types out of the box (threshold alert type to begin).

[peterschretlen]

Aside from the chicken-egg problem @mikecote described ( alerting needing the mappings before dependent plugins can create them), and potential for large mappings …. are there any drawbacks to having a large number of saved object types? Does it add any complexity to the alerting plugin, having to be aware of or manage those types? Does this fall in the bounds of proper use of Saved Object types or are we abusing it.

If we take the extreme of one saved object type per alert type, it sounds like might have to double that for history/audit log (for similar security reasons). Say we have 100 alert types, that would give us 200 saved object types. We won't get there overnight, but across solutions that's a reasonable number to expect.

[kobelb]

I think that's a great question to ask, @peterschretlen. I think it'd be good if we came up with general guidelines for when we should be using a different saved-object type, while ignoring the complications that it introduces from the security perspective. We can definitely add the ability to secure sub-sets of saved-objects with the same type; however, it is a reasonable amount of work.

[rudolf]

@mikecote

We may have a chicken and egg problem with this if ever the alerting plugin "setup" creates / registers the mappings. The alerting "setup" function is called before the plugins that dependent on it. Only at the other plugins "setup" we would be able to register mappings and the alerting plugin would have to expose its mappings on "start" for it to possibly work?

When a plugin exposes an API, other plugins can keep on using that API in their relevant lifecycle. So if plugin A exposes an API method registerNewType(name: string) which uses Core's Saved Object Mapping API, plugin B can call registerNewType() in it's own setup lifecycle. So by exposing API's plugins can indirectly continue to do setup work even after they return from their setup function.

I think this dynamism is really valuable in some cases, but the downside is it becomes really hard to track where a mapping comes from, you can no longer search the code base for static mappings.json files.

@peterschretlen I agree that exploding the field count might have some undesired consequences. We will probably have to benchmark the performance. We shouldn't go over ES's 1000 field default limit, but assuming that the Kibana index doesn't have more than an order of magnitude of 10^2 or 10^4 documents performance might be acceptable.

It's hard for me to comment on the "proper" use of Saved Object types without knowing the history that led us to the current design. I suspect having a single index for operational simplicity has been the biggest design goal above performance or ES data-modelling best practices.

@epixa I think your input would be valuable in this discussion.

[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: #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: #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 (Adds Role Based Access-Control to the Alerting & Action plugins based on Kibana Feature Controls #67157) and Actions (Adds Role Based Access-Control to the Actions framework based on Kibana Feature Controls #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).