-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
[Alerting] Alerting authorization should always exempt alerts
consumer
#108220
[Alerting] Alerting authorization should always exempt alerts
consumer
#108220
Conversation
alerts
consumer
Pinging @elastic/kibana-alerting-services (Team:Alerting Services) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
changes LGTM
Only thing I'm wondering about is if we would want a FT for this, but not quite sure how it would work. Wouldn't need to be part of this PR, and we're getting some implicit testing with the rule registry anyway.
I agree! We have this issue open for adding tests under user with limited role and I think functional tests for this stuff in that test suite would make a lot of sense! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Is it documented for plugin devs somewhere how to use our authorization client?
I don't think so but it definitely should be! I'll make an issue for it, thanks! |
💚 Build SucceededMetrics [docs]
History
To update your PR or re-run it, just comment with: cc @ymao1 |
…mer (elastic#108220) * Reverting changes to genericize exempt consumer id * Adding unit test for find auth filter when user has no privileges
💚 Backport successful
This backport PR will be merged automatically after passing CI. |
…mer (#108220) (#108258) * Reverting changes to genericize exempt consumer id * Adding unit test for find auth filter when user has no privileges Co-authored-by: ymao1 <[email protected]>
Resolves #108206
Summary
Reverts some the changes from this PR, specifically the changes to the alerting authorization client.
Previously the alerting authorization client always special-cased the
alerts
consumer when checking authorization, so that rules created in the Stack Rules Management UI would only be subject to producer based RBAC. I assumed this exemption was something only needed by the alerting framework, which is true for the way rules are used now, but not true for alerts derived from rules, so during the refactor, the rules client would specify this exemption when using the authorization client but any external users of the client would not be able to specify this exemption. With this revert, this exemption is applied to all users of the authorization client so rules created in Stack Rules Management and their derived alerts are only subject to producer based RBAC.Checklist
Delete any items that are not applicable to this PR.