Kibana alerting RBAC - impact on detection rules' actions

[dhurley14]

With the introduction of RBAC in kibana alerting (#67157, #67157 (comment)), users who wish to create or edit or view rules will need to set permissions for alerting and actions if:

1. The user wants to create alerts, that role will require "all" permissions for "alerting" and either "read" or "all" for actions.
2. The user wants to create alerts and custom action connectors for a rule, that role will require "all" permissions for alerting and "all" permissions for actions.
3. The user wants to view alerts, that role will require "read" permissions for "alerting and either "read" or "none" for actions.
4. If a user does not have "all" or "read" for actions, but they have "all" for alerting, then we will need to hide the UI section for creating actions or disable the actions step during rule creation.

In general the suggestion will be to set alerting and actions permissions to be whatever the permissions are for the security solution in that given role.

[elasticmachine]

Pinging @elastic/siem (Team:SIEM)

[tonymeehan]

@dhurley14 thanks for putting this together. I had a few questions.

If I've created a detection rule with an action to send to an external system anytime there's a new alert, and then I upgrade to 7.10:

1. What, if anything, breaks and how will a user know it's broken?
2. If anything is broken, can that be fixed by setting alerting and actions permissions to be whatever the permissions are for the security solution in that given role?

[tonymeehan]

I'm also curious what work we need to do in order to address #67157 (comment)

[dhurley14]

@tonymeehan I spoke with @gmmorris and we discussed at a high level the changes that this introduces.

My initial understanding was these changes would only affect the process of creating new rules with actions and not have an effect on previously created rules. That assumption was incorrect. This will have an effect on rules with actions that were previously created and will require those rules to be enabled / disabled manually. I will summarize the changes to the best of my ability below and I invite Gidi to add / correct anything I miss:

What, if anything, breaks and how will a user know it's broken?

Any rule rule with an action created before 7.10 will need to be disabled / enabled by a user with either "Read" or "All" permissions for "Actions" without which the action will never fire. There is no way for us or the kibana alerting team to migrate actions and update the api key for the action / rule (alert). The end user (while logged in as a user with the necessary permissions for actions) must disable / re-enable all rules with actions.

If anything is broken, can that be fixed by setting alerting and actions permissions to be whatever the permissions are for the security solution in that given role?

This will help with the creation of new rules with actions. I don't believe we can do this automatically though. Also, this will not alleviate issues around rules with actions which are migrated from 7.9, 7.8 etc.. to 7.10 failing to fire when triggered. New API keys must be generated for the rules via manually re-enabling the rules (by a user with the permissions listed above). Gidi and the kibana security team discussed this further here.

I'm also curious what work we need to do in order to address #67157 (comment)

That situation will occur if the user creating the rule (in 7.10) does not have, at a minimum "Read" permissions for actions. If that is the case, we need to hide the actions step. Or develop some UX. Maybe display to the user "hey you don't have permissions to setup actions for a rule. Talk to your kibana admin about getting those permissions or skip this step" etc.

[dhurley14]

#75563 fixes the issues around actions not firing for rules created before 7.10, but we still have some decisions to make around permissions for creating new rules in 7.10.

In order for a user to create a rule in 7.10, the user will need “All” permissions for Alerts. In addition to this, we need to determine what the requisite (if any) permissions for the "Actions" setting will be for creating a rule. There are four options as far as I see:

1. Require “All” permissions on “Actions” to create rules (the user will then be able to view the actions section of the create rules form and will be able to create their own connectors)
2. Require “Read” permissions on actions (the user will be able to view the actions section of the create rules form and select from previously created connectors for rules, but cannot create their own connectors)
3. Don’t require any permissions for actions and then the user will not see the “actions” section of the create rule form.
4. Don't require any permissions and just leave this error popup as-is Adds Role Based Access-Control to the Alerting & Action plugins based on Kibana Feature Controls #67157 (comment) (I think this option is not really an option but more of "this is what happens if we don't do anything right now")

What’s everyones opinion on this?