-
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
[ResponseOps][Alerting] Decouple rule producer/consumer settings from Kibana feature ID #181559
Comments
Pinging @elastic/response-ops (Team:ResponseOps) |
@xcrzx Can you add more details about why migrating rules is not an option? Either a summary in this ticket or a link to where a reader can find more information. |
@marshallmain The producer/consumer fields are used for RBAC, and migrating them without downtime is not possible in Serverless. The upgrade process in Serverless works in such a way that there might be several Kibanas of different versions running simultaneously, all consuming data from a single Elasticsearch cluster. When a newer version of Kibana starts up, it begins migrating saved objects, including changing the producer/consumer fields in this case. As a result, older versions of Kibana will encounter access errors when attempting to read the migrated data. |
Hey @cnasikas, I was told today in a sync meeting with the ResponseOps team that this is going to be taken into work around the 8.16 release cycle, but without a commitment to ship in 8.16. Just double-checking here to confirm. |
Hey @banderror, this is correct. I am still working on a POC (#183756) for this. We are confident that is feasible but we need to finalize some edge cases. I will post our findings on the issue soon. The next step is to make it production-ready but as you said without a commitment to ship in 8.16. |
@xcrzx @banderror @kobelb @marshallmain I finished working on the POC. The idea is to change the way we define the alerting privileges when registering a feature privilege as shown in the pseudo-code below. After the schema changes the alerting authorization class changed to accommodate the new privilege schema without breaking changes. Rules created with the Before
After
Technical analysisThe Kibana security uses Elasticsearch's application privileges. This way Kibana can represent and store its own privilege models within Elasticsearch roles. To do that, Kibana security creates actions that are granted by a specific privilege. Alerting uses its own RBAC model and is built on top of the existing Kibana security model. Alerting creates its own custom actions. For example ConclusionsWe are confident that this approach will accommodate the needs of the Security Solution team without introducing breaking changes assuming the roles can be migrated. Given the impact of the new changes across all rule types and alerts and the widespread use of the |
Blocker for: https://github.com/elastic/security-team/issues/9533 (internal), https://github.com/elastic/security-team/issues/8799 (internal)
Summary
As part of the RBAC changes in the Security Solution (see this issue for more details), we need to extract rule management into a standalone Kibana product feature.
This involves transferring security rule types from the
siem
feature (current configuration here) to a newruleManagement
feature. This will require changing the producer and consumer rule settings to a new value, as feature IDs currently serve as the producer/consumer identifiers.As we discussed previously, migrating rules is not an option (see this comment). Therefore, we need to find out how to make the Alerting RBAC work with the new feature ID while keeping the current rule producer/consumer
siem
value.The text was updated successfully, but these errors were encountered: