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

Solutions cannot limit who can execute their action types #70303

Open
gmmorris opened this issue Jun 30, 2020 · 6 comments
Open

Solutions cannot limit who can execute their action types #70303

gmmorris opened this issue Jun 30, 2020 · 6 comments
Labels
enhancement New value added to drive a business result estimate:medium Medium Estimated Level of Effort Feature:Alerting/RulesFramework Issues related to the Alerting Rules Framework Feature:Alerting response-ops-ec-backlog ResponseOps E&C backlog Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)

Comments

@gmmorris
Copy link
Contributor

This is a follow up issue to the RBAC work done for Alerting and Actions #43994.

RBAC for Actions is implemented at feature level - so the all/read/none privileges can be assigned to roles using Feature Controls and thus it can be controlled who can create Connectors, whjo can execute actions based on these connectors etc.

This does not address the requirement to provide control at solution level.
This means that if, for example, the observability solution were to provide an APM specific action type, it would be available to anyone who has been granted access to the Actions plugin as a whole.
But in such a case, it's possible the solution would want to limit this access to just users who have access to the Observability solution, in a similar manner to how we provide solution & alertType specific RBAC in Alerting - this issue should address that.

@gmmorris gmmorris added Feature:Alerting Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) labels Jun 30, 2020
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-alerting-services (Team:Alerting Services)

@mikecote
Copy link
Contributor

This will unblock #82502. We should re-schedule that issue once this issue is resolved.

@mikecote
Copy link
Contributor

cc @arisonl

@mikecote
Copy link
Contributor

mikecote commented Dec 8, 2020

I had a chat with @XavierM on this issue and this won't be needed until case moves out of the security solution. In the meantime, the case connector will only be visible in the security solution (hidden from connectors UI) and the executor should be running as the user already. This means it should handle proper RBAC at execution time if someone was to trying to use the _execute endpoint.

@mikecote
Copy link
Contributor

Some input on the expectations for limiting who can create / edit / execute action types: #94498.

@gmmorris gmmorris added the Feature:Alerting/RulesFramework Issues related to the Alerting Rules Framework label Jul 1, 2021
@gmmorris gmmorris added the loe:large Large Level of Effort label Jul 14, 2021
@gmmorris gmmorris added the estimate:medium Medium Estimated Level of Effort label Aug 18, 2021
@gmmorris gmmorris removed the loe:large Large Level of Effort label Sep 2, 2021
@kobelb kobelb added the needs-team Issues missing a team label label Jan 31, 2022
@botelastic botelastic bot removed the needs-team Issues missing a team label label Jan 31, 2022
@mikecote
Copy link
Contributor

mikecote commented May 4, 2023

cc @cnasikas

@mikecote mikecote added the response-ops-ec-backlog ResponseOps E&C backlog label Nov 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New value added to drive a business result estimate:medium Medium Estimated Level of Effort Feature:Alerting/RulesFramework Issues related to the Alerting Rules Framework Feature:Alerting response-ops-ec-backlog ResponseOps E&C backlog Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)
Projects
No open projects
Development

No branches or pull requests

4 participants