[Security Solution] Bulk actions and Custom rules got disabled when custom user have "NONE" access of actions and connectors.

[ghost]

Describe the bug:
Bulk actions and Custom rules got disabled when custom user have "NONE" access of actions and connectors.

Build Details:

VERSION: 8.5.0 Snapshot
BUILD: 56410
COMMIT: 189196181c975b620ab18ea9d7662aa38d0e9294

Preconditions:

1. Elasticsearch should be up and running
2. Kibana should be up and running
3. Custom rules should be created with actions.

Steps to Reproduce:

1. Navigate to Stack management --> Roles.
2. Create a Role with below configurations:

3. Navigate to Stack management-->Users.
4. Create custom User and assign above created role.
5. Login with a custom user.
6. Navigate to Security-->Manage-->Rules.
7. Select the above custom created rules.
8. Click on "Bulk Actions"

Expected Result:
Bulk actions should be enabled and rule also should be enabled.

Actual Result:
Bulk actions and rule are disabled.

Screenshots:

[elasticmachine]

Pinging @elastic/security-solution (Team: SecuritySolution)

[elasticmachine]

Pinging @elastic/security-detections-response (Team:Detections and Resp)

[banderror]

Great catch @karanverma-qasource, thank you! Some other observations made under a user with the mentioned privileges:

Enable/disable switch is disabled on the Details page because You do not have Kibana Actions privileges. This is probably expected behavior (if so, on the Rules page it would be expected too):

The Edit rule settings button is disabled because You do not have Kibana Actions privileges. This looks like a bug - I'd expect the user to still be able to edit other fields:

A rule without any actions can't be enabled/disabled from the Details page, while can be from the Rules page:

[banderror]

As we figured out with @XavierM, the root cause of this bug is related to Alerting Framework's RBAC.

In particular, it relates to the fact that Alerting Framework updates the API key of a rule on every rule modification (except enable/disable since 8.3 (#131581)). The regenerated API key corresponds to the user that initiated this rule modification. In turn, if this user has different privileges than the user that this rule was associated with before the modification, this can lead to unintended consequences:

• After the modification, the rule may get more privileges than before (e.g. it may get access to new indices) which can cause more (unintended) alerts to be generated
• After the modification, the rule may get less privileges than before (e.g. it may lose access to some indices) which can cause fewer alerts to be generated

Now, this specific UI behavior looks to be intentional. We disable all the bulk actions and also single actions if the user doesn't have Actions and Connectors privileges, because if this user modifies any rule which happens to have any actions, these actions will start failing during their execution (they will be executed on behalf of this user that doesn't have the required privileges to run actions).

We could try to add more checks to our code and handle some of the cases on our side, but it would be workarounds that we decided not to introduce at this point.

We should instead address the fundamental problem with API keys on the Framework side, e.g. execute rules on behalf of service accounts instead of user accounts, so that user modifications don't change the rules' privileges.

UPD: mentioned that since 8.3 enabling or disabling a rule does not regenerate the rule's API key: #131581

[sophiec20]

Since 8.3, I believe you can bulk enable / disable rules without it regenerating the API Key. However if no API Key exists, for example directly after a bulk import of new disabled rules, then one will be assigned the first time the rule is enabled.

It is existing behaviour that the API Key will be regenerated on every rule edit and the ability to edit rules is expected to be restricted to users who are also authorized to execute them.

Use of "Service Accounts" is appealing, however this is a larger piece of work as it also requires the ability to manage, maintain and audit service accounts. This would be a useful platform feature and not limited to rule execution. There are several areas discussing this but afaik this is not yet in development. (cc @bytebilly for visibility)

In the short term, it would be advisable to limit the ability to edit rules to users who are also authorised to execute them. -- the comment above seems to contradict this wrt to bulk disable/enable. Is this a regression?

[banderror]

Since 8.3, I believe you can bulk enable / disable rules without it regenerating the API Key. However if no API Key exists, for example directly after a bulk import of new disabled rules, then one will be assigned the first time the rule is enabled.
the comment above seems to contradict this wrt to bulk disable/enable. Is this a regression?

@sophiec20 Oh, I was not aware of the improvement made in 8.3. That's great! I don't think we have a regression.