[Response Ops][Alerting] Adding new alerting actions to allow more fine grained rule privileges#237526
Merged
ymao1 merged 13 commits intoelastic:mainfrom Oct 27, 2025
Merged
[Response Ops][Alerting] Adding new alerting actions to allow more fine grained rule privileges#237526ymao1 merged 13 commits intoelastic:mainfrom
ymao1 merged 13 commits intoelastic:mainfrom
Conversation
ymao1
changed the title
Contributor
Author
|
@elasticmachine merge upstream |
Contributor
Contributor
Author
|
@nkhristinin This PR splits the privileges for manual run and enable/disable out at the security level so the privilege check that already exists in the rules client should be sufficient. It is expected that security solution would add some subfeature privileges to their roles that allow users read+ access to the alerting rules. There is an example of this subfeature privilege in the functional test setup in this PR here: https://github.com/elastic/kibana/pull/237526/files#diff-820d9257549da78d552581e78b6f5fa1229d82c958312de5e880f110d11a75b2. Let me know if I've misunderstood the issue! Happy to iterate |
Contributor
Author
|
@elasticmachine merge upstream |
Contributor
Author
|
@elasticmachine merge upstream |
denar50
reviewed
Oct 22, 2025
denar50
reviewed
Oct 22, 2025
Contributor
|
I have used our RBAC PR which contains the new Then I created a role with |
ymao1
added
Feature:Alerting
release_note:skip
Contributor
|
Pinging @elastic/response-ops (Team:ResponseOps) |
ersin-erdal
approved these changes
Oct 22, 2025
Contributor
There was a problem hiding this comment.
LGTM
Tested locally by adding enable and manual_run to Stack Rules read privileges.
Created a user with Stack Rules read privilege.
Even though the enable/disable button was not active on the UI, I was able to enable/disable a stack rule via curl.
It didn't work (403) for the same user after removing enable and manual_run from the privilege definition.
SiddharthMantri
approved these changes
Oct 24, 2025
Contributor
SiddharthMantri
left a comment
SiddharthMantri
left a comment
There was a problem hiding this comment.
Feature privilege changes LGTM.
gsoldevila
approved these changes
Oct 24, 2025
Member
gsoldevila
left a comment
gsoldevila
left a comment
There was a problem hiding this comment.
Core changes LGTM (code review only)
Contributor
Author
|
@elasticmachine merge upstream |
Contributor
Author
|
@elasticmachine merge upstream |
Contributor
💚 Build Succeeded
Metrics [docs]
History
cc @ymao1 |
Contributor
|
@elasticmachine merge upstream |
denar50
added a commit
that referenced
this pull request
Mar 6, 2026
…252703) # If you're here because your Kibana feature suddenly changed... That is happening because this PR is extracting features from `alerting.rule.all`, namely `enable`, `manual_run` and `manage_rule_settings` (see [this change](https://github.com/elastic/kibana/pull/252703/changes#diff-dc097e1e414af2ca21196b12c7d901373108da58de4dd7505cc169b0e62ec2d3L75)). Your role had `alerting.rule.all`, so I added the rest of the features to it to ensure backwards compatibility. If you think your Kibana feature doesn't need any of those, you're welcome to remove them in a follow up PR. # Summary ResposneOps previously created two alerting features on rules SOs in [this PR](#237526): `enable` and `manual_run`, in order to enable the RBAC efforts in the Detection Engine. Now we are introducing a sub feature within the Rules feature inside the security solution to grant access to "rule settings management" which comprises the ability to manage the gap fill schedulers (see the ticket [here](elastic/security-team#15244)). However we encountered that there is no alerting privilege for rules that matches this new Kibana sub feature. Additionally we found that the existing `alerting.rule.all` feature does not allow us to toggle privileges off once it is granted (see the video below where we are able to bypass rules rbac permissions by calling an endpoint that performs authorization using only alerting privileges) https://github.com/user-attachments/assets/de2a38cd-259e-48aa-b1f2-a38c88f2de88 Therefore this PR : - introduces a new feature called `manage_rule_settings` feature for rule SOs in the alerting framework based on the previous PR. - fixes the issue where users with `alerting.rule.all` will always have all permissions of subfeatures even when they are explicitly toggled off through the Kibana Security role management UI. This is done by extracting the new alerting features from `alerting.rule.all` into their own features. This triggers a change in all existing Kibana features that previously included `alerting.rule.all` since now we will have to explicitly add `enable`, `manual_run` and `manage_rule_settings` in those places. # How was this tested? I put these commits on top of my branch where I have the "Rules management settings" sub feature which is using the alerting feature provided in this PR. ## `manage_rule_settings` I create a role with read only access to the rule feature and only this sub feature enable. I am then able to create operate the gap fill scheduler. See the video below 👇 https://github.com/user-attachments/assets/2bc285a4-d35a-412c-a9fd-2153fdec1b9e ## Issue with `alerting.rule.all` I created a role that has all the permissions for rules, I toggled off `enable` and then tried to reproduce the issue I previously recorded. https://github.com/user-attachments/assets/42d47fbf-5dd0-47ff-8f04-2a8f1c0591f9 --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
kapral18
pushed a commit
to kapral18/kibana
that referenced
this pull request
Mar 9, 2026
…lastic#252703) # If you're here because your Kibana feature suddenly changed... That is happening because this PR is extracting features from `alerting.rule.all`, namely `enable`, `manual_run` and `manage_rule_settings` (see [this change](https://github.com/elastic/kibana/pull/252703/changes#diff-dc097e1e414af2ca21196b12c7d901373108da58de4dd7505cc169b0e62ec2d3L75)). Your role had `alerting.rule.all`, so I added the rest of the features to it to ensure backwards compatibility. If you think your Kibana feature doesn't need any of those, you're welcome to remove them in a follow up PR. # Summary ResposneOps previously created two alerting features on rules SOs in [this PR](elastic#237526): `enable` and `manual_run`, in order to enable the RBAC efforts in the Detection Engine. Now we are introducing a sub feature within the Rules feature inside the security solution to grant access to "rule settings management" which comprises the ability to manage the gap fill schedulers (see the ticket [here](elastic/security-team#15244)). However we encountered that there is no alerting privilege for rules that matches this new Kibana sub feature. Additionally we found that the existing `alerting.rule.all` feature does not allow us to toggle privileges off once it is granted (see the video below where we are able to bypass rules rbac permissions by calling an endpoint that performs authorization using only alerting privileges) https://github.com/user-attachments/assets/de2a38cd-259e-48aa-b1f2-a38c88f2de88 Therefore this PR : - introduces a new feature called `manage_rule_settings` feature for rule SOs in the alerting framework based on the previous PR. - fixes the issue where users with `alerting.rule.all` will always have all permissions of subfeatures even when they are explicitly toggled off through the Kibana Security role management UI. This is done by extracting the new alerting features from `alerting.rule.all` into their own features. This triggers a change in all existing Kibana features that previously included `alerting.rule.all` since now we will have to explicitly add `enable`, `manual_run` and `manage_rule_settings` in those places. # How was this tested? I put these commits on top of my branch where I have the "Rules management settings" sub feature which is using the alerting feature provided in this PR. ## `manage_rule_settings` I create a role with read only access to the rule feature and only this sub feature enable. I am then able to create operate the gap fill scheduler. See the video below 👇 https://github.com/user-attachments/assets/2bc285a4-d35a-412c-a9fd-2153fdec1b9e ## Issue with `alerting.rule.all` I created a role that has all the permissions for rules, I toggled off `enable` and then tried to reproduce the issue I previously recorded. https://github.com/user-attachments/assets/42d47fbf-5dd0-47ff-8f04-2a8f1c0591f9 --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
qn895
pushed a commit
to qn895/kibana
that referenced
this pull request
Mar 11, 2026
…lastic#252703) # If you're here because your Kibana feature suddenly changed... That is happening because this PR is extracting features from `alerting.rule.all`, namely `enable`, `manual_run` and `manage_rule_settings` (see [this change](https://github.com/elastic/kibana/pull/252703/changes#diff-dc097e1e414af2ca21196b12c7d901373108da58de4dd7505cc169b0e62ec2d3L75)). Your role had `alerting.rule.all`, so I added the rest of the features to it to ensure backwards compatibility. If you think your Kibana feature doesn't need any of those, you're welcome to remove them in a follow up PR. # Summary ResposneOps previously created two alerting features on rules SOs in [this PR](elastic#237526): `enable` and `manual_run`, in order to enable the RBAC efforts in the Detection Engine. Now we are introducing a sub feature within the Rules feature inside the security solution to grant access to "rule settings management" which comprises the ability to manage the gap fill schedulers (see the ticket [here](elastic/security-team#15244)). However we encountered that there is no alerting privilege for rules that matches this new Kibana sub feature. Additionally we found that the existing `alerting.rule.all` feature does not allow us to toggle privileges off once it is granted (see the video below where we are able to bypass rules rbac permissions by calling an endpoint that performs authorization using only alerting privileges) https://github.com/user-attachments/assets/de2a38cd-259e-48aa-b1f2-a38c88f2de88 Therefore this PR : - introduces a new feature called `manage_rule_settings` feature for rule SOs in the alerting framework based on the previous PR. - fixes the issue where users with `alerting.rule.all` will always have all permissions of subfeatures even when they are explicitly toggled off through the Kibana Security role management UI. This is done by extracting the new alerting features from `alerting.rule.all` into their own features. This triggers a change in all existing Kibana features that previously included `alerting.rule.all` since now we will have to explicitly add `enable`, `manual_run` and `manage_rule_settings` in those places. # How was this tested? I put these commits on top of my branch where I have the "Rules management settings" sub feature which is using the alerting feature provided in this PR. ## `manage_rule_settings` I create a role with read only access to the rule feature and only this sub feature enable. I am then able to create operate the gap fill scheduler. See the video below 👇 https://github.com/user-attachments/assets/2bc285a4-d35a-412c-a9fd-2153fdec1b9e ## Issue with `alerting.rule.all` I created a role that has all the permissions for rules, I toggled off `enable` and then tried to reproduce the issue I previously recorded. https://github.com/user-attachments/assets/42d47fbf-5dd0-47ff-8f04-2a8f1c0591f9 --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
9 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Resolves https://github.com/elastic/response-ops-team/issues/459
Summary
In order to support allowing users to enable/disable rules and trigger manual rule with alerting rule read privilege, we're adding two new alerting privileges that can be used to add subfeature privileges to existing features. This PR adds those privileges and adds functional tests for them but they are currently unused by any feature privilege.
manual_run- when added as a subfeature privilege, this allows users to schedule/delete backfill rule runs and fill gapsenable- when added as a subfeature privilege, this allows users to enable, disable, bulk enable and bulk disable rules.