Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Convert security solution -> cases sub feature to a top-level feature #109158

Closed
2 tasks done
legrego opened this issue Aug 18, 2021 · 5 comments
Closed
2 tasks done

Convert security solution -> cases sub feature to a top-level feature #109158

legrego opened this issue Aug 18, 2021 · 5 comments
Assignees
Labels
Breaking Change impact:low Addressing this issue will have a low level of impact on the quality/strength of our product. loe:small Small Level of Effort required-for-8.0 This work is required to be done before 8.0 lands, bc it relates to a breaking change or similar. Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more! Team: SecuritySolution Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc. v8.0.0

Comments

@legrego
Copy link
Member

legrego commented Aug 18, 2021

Currently, the security solution "cases" feature is a sub-feature privilege.

We would like to convert this to become a top-level feature in the 8.0 release, since this is a breaking change. This will allow us to align the Cases features for Observability and Security Solution, and allow for cases to take advantage of sub-feature privileges themselves in the future.

Tasks:

  • Create new top-level Cases feature under the Security category
  • Create an Upgrade Assistant automated fix to rewrite roles that are granting access to the Cases sub-feature to use the new top-level Cases feature
@legrego legrego added Team: SecuritySolution Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc. Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more! labels Aug 18, 2021
@elasticmachine
Copy link
Contributor

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

@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-security (Team:Security)

@legrego legrego added Breaking Change required-for-8.0 This work is required to be done before 8.0 lands, bc it relates to a breaking change or similar. v8.0.0 labels Aug 18, 2021
@XavierM
Copy link
Contributor

XavierM commented Sep 8, 2021

@jportner and @watson, if you both do not mind it, I can take this one and you can review it. what do you think?

@jportner
Copy link
Contributor

jportner commented Sep 8, 2021

@jportner and @watson, if you both do not mind it, I can take this one and you can review it. what do you think?

That would be great, thanks!

As mentioned in the linked meta issue (#111160), we need to do separate things for 7.x and master:

  • 7.x branch: Ensure that the 8.0 upgrade assistant accurately reflects all of the deprecations

    • Each deprecation should be set at the appropriate level (critical if it blocks the upgrade, warning if not)
    • Each deprecation should correctly describe when the breaking change will take effect (8.0, or a future version)
    • The copy (text) should be reviewed with the docs team
    • Any automation to fix the problem (correctiveActions.api registered in the DeprecationsService) should be implemented and tested
  • master branch: Ensure that, for breaking changes that take effect in 8.0, all appropriate code is removed

We discussed this particular issue with Platform leadership, and decided that the upgrade assistant in 7.x should provide an automated remediation to "fix" existing roles that are impacted.

Here's how I think we should approach that:

Each role with Custom Privileges that grants the Cases sub-feature privilege should surface as a separate warning in the Upgrade Assistant. Each warning should provide a button to automatically fix the problem (via correctiveActions.api). This should call PUT /api/security/role/{name} to update the role. The updated role should grant both the existing sub-feature privilege and the new feature privilege -- the latter will only have any effect when the user actually upgrades to 8.0.

Let me know if that makes sense or if you think it should be handled differently.
The actual deprecations should probably be added in the Security Solution plugin.

CC @legrego if you have any input.

@jportner jportner assigned XavierM and unassigned watson Sep 8, 2021
@exalate-issue-sync exalate-issue-sync bot added impact:low Addressing this issue will have a low level of impact on the quality/strength of our product. loe:small Small Level of Effort labels Sep 10, 2021
@legrego
Copy link
Member Author

legrego commented Oct 14, 2021

Resolved via #112980

@legrego legrego closed this as completed Oct 14, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Breaking Change impact:low Addressing this issue will have a low level of impact on the quality/strength of our product. loe:small Small Level of Effort required-for-8.0 This work is required to be done before 8.0 lands, bc it relates to a breaking change or similar. Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more! Team: SecuritySolution Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc. v8.0.0
Projects
None yet
Development

No branches or pull requests

5 participants