[Search] Background sessions feature controls

[lukasolson]

With the upcoming background search/sessions feature, we'd like to allow admins the ability to control access to running searches/sessions in the background. There are a few ways to allow this:

1. Add background sessions as a top-level feature control
2. Add background sessions as a sub-feature under applications that implement them (discover, dashboard, SIEM, etc.)
3. Add an advanced setting that toggles the feature

While (1) is probably the easiest implementation, and the easiest way for admins to turn the feature on/off entirely for a set of users, it is awkward because there are no other top-level feature controls that are not applications (with a corresponding icon in the app list). It also interacts awkwardly with the "all/read/none" mechanism we currently have. (What does "read" mean?)

(2) allows for fine-grain control over the feature for different applications, and intuitively seems to make the most sense, but makes it more difficult for admins to entirely turn on/off the feature. We'd also need to decide where "background sessions" as a sub-feature is enabled per application (only when "all" is turned on? or "read" too?).

(3) is also a simple implementation to turn the entire feature on/off, but we don't generally use advanced settings to control application features.

I'd like to discuss the possible solutions and come to an agreement on what we should implement moving forward. See also #73281 (comment).

[lukasolson]

/cc @kobelb @lizozom @elastic-jb @alexh97 @legrego

[legrego]

Hey @lukasolson, thanks for opening this. I'd like to better understand this from an administrator's perspective. I apologize if this is something I should have gleaned from the RFC!

I get that we want to allow admins to control access to the background search/sessions feature, but why would administrators want this ability? What is it about background sessions that makes them a securable entity? If an administrator does want to restrict access, do we envision them doing so on a per-role basis, or would this be more of a per-space or per-instance decision? I understand that per-role gives you the most granularity. I'm just trying to figure out what problem we're solving by restricting access.

If we do in fact need to secure this on a role-by-role basis, then my gut reaction is to configure this as a sub-feature privilege. This is consistent with how Short URLs work today, and this feels like a similar ancillary/additive feature.

If we don't need this to be securable, then an advanced setting would allow administrators to configure this on a per-space basis. We already secure access to advanced settings, so administrators could configure their instance so that this can't be toggled by non-admins.

The advanced setting could also be overwritten via the uiSettings.overrides feature of kibana.yml, in the event that admins wanted to enable/disable for the entire installation without worrying about a misconfigured Space somewhere.

[lukasolson]

What is it about background sessions that makes them a securable entity?

Admins may want to restrict the ability to run many concurrent, potentially expensive long-running queries that use resources that could be allocated to other searches.

Do we envision them doing so on a per-role basis, or would this be more of a per-space or per-instance decision?

That's a great question. @elastic-jb, do we have any idea about how this would ideally be configured?

[lukasolson]

Closed by #85846.