-
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
[RAC] [RBAC] MVP RBAC for alerts as data #100705
[RAC] [RBAC] MVP RBAC for alerts as data #100705
Conversation
f4c0190
to
498e4c0
Compare
Pinging @elastic/security-solution (Team: SecuritySolution) |
Pinging @elastic/security-detections-response (Team:Detections and Resp) |
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.
Stack Monitoring changes look good 👍
Pinging @elastic/apm-ui (Team:apm) |
x-pack/plugins/alerting/server/authorization/alerting_authorization.ts
Outdated
Show resolved
Hide resolved
x-pack/plugins/rule_registry/server/utils/create_lifecycle_rule_type_factory.ts
Outdated
Show resolved
Hide resolved
dec3d22
to
e3c3821
Compare
* force any plugin registering rules to register the feature id into the master list which maps feature id to index names * javascript is not python * favor keyof instead of typeof as const, removes ts-expect-error * updates typedocs * adds rbac utils to utils folder and updates typedocs * featureIds is already string[] and do not trust input for type guard
… integration coverage (#21) * updated method to getAugmentedRuleTypesWithAuthorization and updated to use APM_SERVER_FEATURE_ID const instead of string * abstract inferred return type in rule registry start plugin contract * updated tests and resolved PR comments * working on debugging integration tests, certain roles returning 403 * got it to 12 failing from 30+ - yay? * missing rac api privileges in security solution feature registration * restrict index level privileges in scripts roles and adds test script for security solution alerts * forgot to add rac privilege to read section of security solution feature registration * mismatch of test case and user/roles for two tests * audit before executing update call * security is an optional dependency, should be typed out as such * remove unused / unrealistic roles + users from test cases, fix type check failures * cleanup trial license roles + users Co-authored-by: Devin Hurley <[email protected]>
…n alert that does not exist || an index name that does not exist
…ript runner where we added ... instead of ..
…re duplicate tests and puts them at the higher basic/ dir.
* adds spaces only tests * remove unused imports * remove auth section of request since security is disabled for these tests * rename basic to trial for spaces only tests
…nges were merged into master regarding naming conventions for alerts as data index
c22e179
to
220a8e9
Compare
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.
Security solution changes LGTM! I just skimmed over the rest of the PR. This is a huge step forward for RAC, thanks!
|
||
#### Defined in | ||
|
||
[rule_registry/server/alert_data_client/alerts_client.ts:59](https://github.com/dhurley14/kibana/blob/d2173f5090e/x-pack/plugins/rule_registry/server/alert_data_client/alerts_client.ts#L59) |
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.
These links all lead to a personal repo, should update to lead to elastic repo eventually
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.
good catch
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.
we pulled this from cases and it looks like they have the same problem too.. I'll poke around at this
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.
Seems we'll need to regenerate the docs once it's in master.
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.
Fixed in here: #104975
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.
@dhurley14 @yctercero Thank you for pointing it out! We will regenerate the docs also.
* in a new plugin will require updating the below data structure | ||
* to include the index name where the alerts as data will be written to. | ||
*/ | ||
export const mapConsumerToIndexName = { |
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.
It would be great if we could make a mechanism to register these feature ID - index name pairs in plugin setup instead of hardcoding them. Ideally we would integrate that registration with the index template creation and RuleDataClient initialization so when a plugin registers alerts-as-data it automatically sets up RBAC and provides the necessary client(s). The overall goal would be to keep the entire definition for a particular solution's alerts-as-data index inside the plugin that owns it. Right now the index names are specified in multiple places that have to be kept in sync.
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.
Def agree. This is an ongoing conversation. As the ruleRegistry right now is a library and meant to be stateless, we didn't have a "home" to store this data we needed in. We're opening up a ticket to discuss where best this all might live.
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.
💚 Build Succeeded
Metrics [docs]Public APIs missing comments
Async chunks
Public APIs missing exports
Page load bundle
Unknown metric groupsAPI count
History
To update your PR or re-run it, just comment with: |
* [RAC] [RBAC] MVP RBAC for alerts as data (#100705) 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. Co-authored-by: Yara Tercero <[email protected]> Co-authored-by: Yara Tercero <[email protected]> * fixes failed integration test Co-authored-by: Yara Tercero <[email protected]> Co-authored-by: Yara Tercero <[email protected]> Co-authored-by: Kibana Machine <[email protected]>
++ in collaboration with @yctercero && @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
Alerts as data client
Alerts as data can be interacted with using the AlertsClient api found in
x-pack/plugins/rule_registry/server/alert_data_client/alerts_client.ts
This api includes public methods such as
Migrate away from
_source
and utilizefields
apis.Checklist