[RAC] Turn off RAC features for those using multi tenancy

[Kerry350]

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.

[elasticmachine]

Pinging @elastic/logs-metrics-ui (Team:logs-metrics-ui)

[jasonrhodes]

Note: the way to access the kibana.index value is to look at context.config.legacy.get().kibana.index -- this is a legacy deprecated API that will likely go away in 8.0.0 but since multi-tenancy will also go away at that point, this is the perfect fit for our use case.

[jasonrhodes]

Suggestion for the unsafe flag:
xpack.ruleRegistry.unsafe.legacyMultiTenancy.enabled: true (defaults to false)

[banderror]

Sorry for being late with this question, but if kibana.index is set to a custom value, xpack.ruleRegistry.unsafe.legacyMultiTenancy.enabled: true and quote

the user would receive the behaviour as it stands now, in a non segmented form

what's the plan for https://kibana.siem.estc.dev? Are we completely moving away from multi-tenant envs, there is a plan for rebuilding https://kibana.siem.estc.dev and there is (will be) a guideline for users how to do a similar migration for their own environments?

[Kerry350]

what's the plan for https://kibana.siem.estc.dev? Are we completely moving away from multi-tenant envs, there is a plan for rebuilding https://kibana.siem.estc.dev and there is (will be) a guideline for users how to do a similar migration for their own environments?

It's a good question, but I don't think I have a good answer 😬 In Observability we similarly have shared clusters, and we've historically used kibana.index to facilitate this. We know that moving forward this won't be possible, and we'll be moving away from multi tenant environments, but the last I heard a solution hadn't been agreed upon. When I spoke with @jasonrhodes last week there was talk of people potentially running their own clusters and using CCS (although I think that still doesn't solve things 100%).