-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
[RAC][RBAC] - Alerts as data RBAC MVP #100527
Conversation
…horization client on plugin start contract
…ing/refactor-alerts-authorization
…ing/refactor-alerts-authorization
…ing/refactor-alerts-authorization
…ing/refactor-alerts-authorization
…dd-subfeature-privilege
…9819) * Passing additional rule fields to rule executor * Fixing types check * Api docs * Adding enabled and actions * Api docs * Encapsulating rule information into RuleConfig type * Functional tests * Functional tests * Adding producer, ruleTypeId and ruleTypeName * Api docs Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* lists to ts incremental builds * security_solution to ts incremental * import ResizeObserver explicitly as it is not declared in dom types
* docs(NA): [dev docs] Add how to build a Kibana distributable tutorial * docs(NA): including last step about building a kibana distributable tutorial * docs(NA): add dev docs images * docs(NA): include image for target folder with os packages and distributable * docs(NA): apply feedback received on the PR review * chore(NA): add rpm to brew * chore(NA): update dev_docs/tutorials/building_a_kibana_distributable.mdx Co-authored-by: Jonathan Budzenski <jon@budzenski.me> * chore(NA): update dev_docs/tutorials/building_a_kibana_distributable.mdx Co-authored-by: Jonathan Budzenski <jon@budzenski.me> * docs(NA): update docker names to capitalized Co-authored-by: Jonathan Budzenski <jon@budzenski.me> Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
…horization client on plugin start contract
…rk with new registry
* WIP - creating alerting authorization client factory and exposing authorization client on plugin start contract * Updating alerting feature privilege builder to handle different alerting types * Converting to es query if requested * first pass at getting everything working again * working update function * fix rebase conflicts * fixes index mapping to add owner field * fixes update route, previously using wrong ruleTypeId and not building the correct index * fix getIndex function Co-authored-by: Ying Mao <ying.mao@elastic.co>
c26f42c
to
dc0b04b
Compare
💔 Build Failed
Failed CI Steps
Test FailuresKibana Pipeline / jest / Jest Tests.x-pack/plugins/features/server/feature_privilege_iterator.featurePrivilegeIterator ignores sub features when `augmentWithSubFeaturePrivileges` is falseStandard Out
Stack Trace
Kibana Pipeline / jest / Jest Tests.x-pack/plugins/features/server/feature_privilege_iterator.featurePrivilegeIterator ignores sub features when `includeIn` is none, even if `augmentWithSubFeaturePrivileges` is trueStandard Out
Stack Trace
Kibana Pipeline / jest / Jest Tests.x-pack/plugins/features/server/feature_privilege_iterator.featurePrivilegeIterator includes sub feature privileges into both all and read when`augmentWithSubFeaturePrivileges` is true and `includeIn: read`Standard Out
Stack Trace
and 41 more failures, only showing the first 3. Metrics [docs]Module Count
Public APIs missing comments
Any counts in public APIs
Async chunks
Public APIs missing exports
Page load bundle
Saved Objects .kibana field count
Unknown metric groupsAPI count
async chunk count
References to deprecated APIs
History
To update your PR or re-run it, just comment with: |
++ in collaboration with @dhurley14 && @angorayc
An MVP of the RBAC work required for the "alerts as data" effort. An example of the existing implementation for alerts would be that of the security solution. The security solution stores its alerts generated from rules in a single data index -
.siem-signals
. In order to gain or restrict access to alerts, users do so by following the Elasticsearch privilege architecture. A user would need to go into the Kibana role access UI and give explicit read/write/manage permissions for the index itself.Kibana as a whole is moving away from this model and instead having all user interactions run through the Kibana privilege model. When solutions use saved objects, this authentication layer is abstracted away for them. Because we have chosen to use data indices for alerts, we cannot rely on this abstracted out layer that saved objects provide - we need to provide our own RBAC! Instead of giving users explicit permission to an alerts index, users are instead given access to features. They don't need to know anything about indices, that work we do under the covers now.
An example of what a user will see in the UI:
The alerting plugin, from which rules and alerts are generated (kinda - there's also a rule registry plugin, different convo) already had an RBAC infrastructure based on a rule producer, consumer, and rule type
id
. In an effort to keep things consistent (and given that alerts flow from corresponding rules), we are reusing the alerting plugin authorization client. The authorization client provides methods that interact with the security plugin API to provide the necessary authentication checks.The MVP deals with the following use cases.
As a user, I would like to:
As an admin, I would like to:
The MVP also includes the work necessary to create alerts with the proper fields, however, alerts are created using the internal Kibana user.
Resources
Open discussions
Checklist