Open MadameSheema opened 1 month ago
Pinging @elastic/security-solution (Team: SecuritySolution)
Pinging @elastic/response-ops-cases (Feature:Cases)
Pinging @elastic/security-detection-engine (Team:Detection Engine)
Pinging @elastic/response-ops (Team:ResponseOps)
@cnasikas @yctercero can you please take a look at this issue? Thanks!
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.
@yctercero I think the question is, from the product/UX standpoint, what needs to happen with such rules on downgrade to essentials:
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.
@approksiu @ARWNightingale could you please confirm what the intended behavior should be here?
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?
Originally reported by @dhurley14
Describe the bug:
Preconditions:
Steps to reproduce:
Current behavior: