[Kibana] Add a separate privilege under "Management" for allow/disallow "Saved Query"

[ninoslavmiskovic]

Describe the feature:

Add a separate privilege under "Management" for allowing admins to control which users are able to utilize "Saved Queries"

Describe a specific use case for the feature:

If you have a user that has "read" only access to the Dashboard, but you want the user to be able to utilize the "Saved Query" feature, that is not possible today. Having "Saved Query" as a separate privilege, the admin will be able to set up a role that can utilize "Saved Query" on a Dashboard, even though the user only has "read" privilege for the Dashboard app.

[elasticmachine]

Pinging @elastic/kibana-data-discovery (Team:DataDiscovery)

[Danouchka]

Hi @ninoslavmiskovic
Customer is willing to have this one released 1st.
it becomes critical for their operations.
Would you be open for a customer call so that they can show on their own dashboards and data but explain the impacts of not having this ?
Also do you have an approximate date of when that would be available (Plan of intent) ?

[ninoslavmiskovic]

@Danouchka We had the call - Please share it internally.

[Danouchka]

Sure !

[kertal]

Adding the blocked label there, because we need security migrations to implement this feature, there's no way currently to implement it without a breaking change for existing users and their roles #68814

[mwtyang]

cc @arisonl @legrego

[arisonl]

"Security migrations" is a substantial piece of work and this is why it has not been picked up until now (we were unsure whether there is enough justification for the effort). We will revive this conversation internally and circle back.

cc @mwtyang @ninoslavmiskovic

[arisonl]

@ninoslavmiskovic Quick question: In the wireframe you attached, why is this not a sub-privilege under dashboards (and Discover -I remember they wanted it in Discover as well?) but rather under Management?

@kertal Is it a breaking change both as a sub-feature and alternatively as a separate feature privilege?

cc @mwtyang

[kertal]

@arisonl as a sub privilege it's a smaller breaking change, e.g. for rules like this, because the addition of a sub privilege will disallow this sub privilege for users with this role by default (given the role has "Customize sub privileges" on)

I'm very aware that security migrations is a lot of work, but given the fact that we just added significant changes when switching between majors. But when there are no servers involved and the upgrade is more frequently, I guess any security rule add-on is blocked in the future?

[ninoslavmiskovic]

As I see it the impact and the risk are lowest with continuing with adding 2 x sub privileges for Dashboard and Discover since it is only affecting users that have turned on the "Customize sub-feature privileges"

Therefore it is a smaller breaking change than adding it as a privilege of its own.

For the future migration effort, I recommend we still prioritize migration since it will help us in several cases, and tackle any challenges that are related to migration when we start developing it.

WDYT: @timductive , @mwtyang , @kertal , @arisonl

[Danouchka]

Hi

I remind the functional need:
be able to save 'saved queries' (I think loading is already ok) from read-only Dashboards
be able to save 'saved queries' (I think loading is already ok) from a read-only Discover

This way, a user can go back and forth from discover to dashboards loading, saving his saved queries

Thank you very much, Dan

[arisonl]

We have no doubt that this is useful. We will discuss how this stacks up with the priority big items (mainly serverless) of the security team on Monday with @mwtyang and on Tuesday with the team.

On a high level, the problem is that if we split a set of privilege definitions to subsets, we do not currently have a way to map the privileges that a role is given from the previous situation to the new one. Without this piece of logic, we would break users currently assigned privileges and this piece of logic needs to be airtight and ideally to not require admins' actions.

[davismcphee]

I want to point out that by introducing saved query only as a sub privilege of Dashboard and Discover, we would not be addressing the following areas (not an exhaustive list) which also allow users to create/load saved queries. We would need to introduce dedicated sub privileges for every single one of them in order to provide similar functionality:

• Lens
• Maps
• TSVB
• Vega
• Aggregation based editor
• Security Timelines
• Security Alerts
• Elasticsearch query rule
• ...

Another thing to consider is that if we introduce saved query sub privileges now, we won't be able to migrate from many sub privileges to a single top-level privilege later once security migrations exists without introducing another breaking change, since there wouldn't be a way to reliably map from any combination of sub privileges to a single top-level privilege.

[arisonl]

I understand that and this is your decision, our Analytics friends (our team will deliver the backend), but: first not all of these objects are a priority, e.g. TSVB is not, is Vega? Timelines don't even appear having separate controls I think (but that may be due to the fact that they cannot easily split them). My three cents:

• It looks to me that we end up having a long list of heterogeneous things under "management" because basically we don't know where else to put them?
• If there is an applicable MVP approach (e.g. dash and discover first like the initial ER asks for), we should go for it (I understand that this is not a straight line due to... well security being security, and an MVP may require to think about "everything" now)
• I am hoping that with the security migrations we'll be able to allow you to move things without breaking them both directions, i.e. be able to resolve that missing mapping up or down level (TBC by our engineering)

[Danouchka]

@davismcphee

There's a real and practical problem of data governance and usage by hundreds customer operators that must be addressed in read-only Discover and Dashboards.... What you say is very wise indeed. However, we should not try to address everything and every hypothetical use cases that were not required by customers yet. (since Dashboards are read only, they wont be allowed to create visualizations with Lens, TSVB, maps ....etc)
And the "saved queries" sub privileges for this ER should be initialized with the parent privilege current permissions.

[Danouchka]

Question: if the KQL bar is always accessible in Discover and Dashboards and that people can input any search, why not allowing them to always save and reload their saved queries ? This way, no sub privilege to code. What would be your take on that @ninoslavmiskovic @arisonl @davismcphee ?

I am going to test customer as well on that idea to see if it makes sense for them.

[Danouchka]

Customer is favorable to the idea of having saved queries always on , ie without the need of controlling it necessarily via a sub privilege.

[davismcphee]

Hey @Danouchka, just acknowledging that I saw your recent comments. We've been discussing this internally and should be able to provide an update here soon.

[kertal]

I was removing the blocked label, because we figured out a way forward without a breaking changes. The way it works is pretty close like mentioned in the issue description. We won't introduce a sub privilege, but a dedicated global privilege for having saved queries "always on", while when this is not set, we keep the handling of the saved query privilege like it was before, on plugin level.

[mwtyang]

cc @timductive @thomasneirynck @teresaalvarezsoler

[ninoslavmiskovic]

Thank you for pulling this together @kertal and @davismcphee . 👏