Summary
When a user has the kibana.index config value set a custom index is written to. We originally wanted to support multi tenancy for RAC via the xpack.ruleRegistry.index setting.
However, it has become hard to reason about this with three methods of accessing data (the rule data client, the alerts data client, and the timeline search strategy), and RBAC layered on top.
Various discussions have happened, e.g. #106432 and #104958 but it's still unclear how to provide this in a non-buggy / bulletproof way. @jasonrhodes and I had discussed a temporary workaround, but it would only fix things for the rule data client and the search strategy. There is work planned to land in 7.15 which uses the alerts data client.
This ticket would instead implement the following:
- Check if
kibana.index is set
- If so, check if there is another flag, something like
UNSAFE_multi_tenancy_alerting
- If that unsafe flag isn't set and
kibana.index is set, we turn everything off
With both settings the user would receive the behaviour as it stands now, in a non segmented form.
Summary
When a user has the
kibana.indexconfig value set a custom index is written to. We originally wanted to support multi tenancy for RAC via thexpack.ruleRegistry.indexsetting.However, it has become hard to reason about this with three methods of accessing data (the rule data client, the alerts data client, and the timeline search strategy), and RBAC layered on top.
Various discussions have happened, e.g. #106432 and #104958 but it's still unclear how to provide this in a non-buggy / bulletproof way. @jasonrhodes and I had discussed a temporary workaround, but it would only fix things for the rule data client and the search strategy. There is work planned to land in 7.15 which uses the alerts data client.
This ticket would instead implement the following:
kibana.indexis setUNSAFE_multi_tenancy_alertingkibana.indexis set, we turn everything offWith both settings the user would receive the behaviour as it stands now, in a non segmented form.