[Security Solution] Rule with cases connector after downgrading to essentials cannot be edited

[MadameSheema]

Originally reported by @dhurley14

Describe the bug:

• Rule with cases connector after downgrading to essentials cannot be edited

Preconditions:

• To have a rule with cases connector in complete tier
• Downgrade to essentials

Steps to reproduce:

1. Edit the rule with the cases connector

Current behavior:

• The cases connector is displayed
• When the user edits the rule and clicks on the save button an error is displayed

[elasticmachine]

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

[elasticmachine]

Pinging @elastic/response-ops-cases (Feature:Cases)

[elasticmachine]

Pinging @elastic/security-detection-engine (Team:Detection Engine)

[elasticmachine]

Pinging @elastic/response-ops (Team:ResponseOps)

[MadameSheema]

@cnasikas @yctercero can you please take a look at this issue? Thanks!

[yctercero]

This is likely an issue we'll run into when we break exceptions out into it's own subprivelege as well. We don't have a good way of saying you can edit this portion of the rule schema and not another. @banderror @marshallmain correct me here if I'm wrong, but I think we need to think through how to design such changes.

[banderror]

@yctercero I think the question is, from the product/UX standpoint, what needs to happen with such rules on downgrade to essentials:

• Do we want to remove from rules all the actions referencing cases connectors?
• Do we want to disable these connectors?
• Do we want to let those rules/actions and connectors continue to work?

I guess, in any case, we want the rules to continue to be editable.

When we have this understanding, we could think about what needs to be done technically.

@yctercero Not sure I understand what is being asked with regards to exceptions and RBAC.

[yctercero]

@approksiu @ARWNightingale could you please confirm what the intended behavior should be here?

[cnasikas]

When a rule is created an API key is also created and connected to the rule. The API key represents the user that created the rule. This is needed to execute the rule and the actions under the user's permission. When someone edits a rule, the API key is updated to represent the user who updated the rule. So, if we let the user update the rule without having access to cases the case action will start to fail due to permission errors. As @yctercero said we do not have a way to have different permissions per portions of the rule's schema. The downgrade scenario is interesting though because it means that no user has access to cases. Does the rule fail either way by downgrading to essentials?

Related: #191681.

[yctercero]

@cnasikas cold we do something where we disable the action? Users would be able to delete the action, but we could still maintain it there in case they upgrade. How difficult would the concept of enabled/disabled actions be to introduce?

[yctercero]

@MadameSheema does this occur with the other actions that are only present for higher tiers or is this specific behavior to cases?

[cnasikas]

@yctercero I tested and for the other connectors we allow to save the rule but we do not execute the actions. We also show a warning in the rule's flyout. For the system actions, we perform extra authorization checks this is why the update of the rule fails. We could skip the authorization if the license is not sufficient, allow the rule to be saved as with the other actions, and disable the action as you suggested. I prioritized it but I am not sure if we can make it for 8.16.

[MadameSheema]

@MadameSheema does this occur with the other actions that are only present for higher tiers or is this specific behavior to cases?

@yctercero specific for cases connector/action.

[yctercero]

@cnasikas Thanks so much! That sounds like a great way forward.