Allow individual privileges to be configured for Saved Objects CRUD operations

[jagriffiths999]

Finer Grained Control of Saved Object Management:

I would like to allow users the ability to delete saved searches. From what I see this needs to be done via the Saved Object Management Screen, is there a way to limit them to be able to just delete search saved objects it looks if I give them permissions to Saved object management they will be able to delete any type of saved object i.e. index patterns/dashboards

[elasticmachine]

Pinging @elastic/kibana-security (Team:Security)

[legrego]

Hey @jagriffiths999, thanks for opening this issue.

You're right, at this point, the only way to do this from the user interface is via the Saved object management screen, and there isn't a way to restrict access here to just saved searches.

If the user has the ability to create saved searches, then they are also authorized to delete them, but we don't expose this in the UI on its own. They can use the Saved Objects API to delete the saved searches as well, but I understand that's not a great user experience.

[AndrewMcQuerry]

The 2 built-in application privileges for Saved Objects are definitely at the extreme opposite ends of the spectrum.

• read (can't Import anything)
• all (can Import anything-- not to mention delete, modify, update, etc any saved object)

In an attempt to create a custom application privilege that removes the privileges from "all" that we don't want our users to have, we've discovered that this breaks the Saved Object Import in non-graceful ways. For example, if we remove index-pattern privileges, but keep visualizations, dashboards, searches, an Export that contains "related objects" will fail to import entirely since our custom application privilege denies the included index-pattern. This means that we then have to instruct our users to 1) don't export "related" objects, or 2) surgically remove index-patterns from your export before attempting to Import. Neither of which are a good user experience.

With the evolution of Kibana moving to more and more and more saved objects inside of .kibana, the need to have specific controls over each type of saved object (dashboards, visualizations, etc) AND each action (create, delete, update, etc) for that saved object is greater than ever.

Furthermore, the "custom application privilege" process would require us to maintain and update that privilege for every single upgrade, given that the action names all have the Kibana version included, saved_object:7.16.3:....

[AndrewMcQuerry]

For us, this issue primarily surfaced when it was discovered that a role with the following Kibana feature-level privileges, results in a user being able to modify the Custom Labels and Formatting for fields within an Index Pattern by using the "Discover -> Field -> Pencil Edit -> Edit field" workflow --- even though that same user is prevented from editing the Custom Label or Formatting of a given field within the "Stack Management -> Index Patterns" UI.

• feature_indexPatterns.read
• feature_savedObjectsManagement.all

In this case, the feature_savedObjectsManagement.all is allowing the user to modify the Index Pattern, even though the feature_indexPatterns is explicitly set to read.

I realize this specific issue is possibly it's own issue to be reported, but figured it may help provide additional justification to this issue which targets more granular control over all savedObject privileges in general.

[jportner]

In this case, the feature_savedObjectsManagement.all is allowing the user to modify the Index Pattern, even though the feature_indexPatterns is explicitly set to read.

This is not necessarily intuitive, but it is by design. If you have All access to the Saved Objects Management feature, Elasticsearch grants you All privileges for all registered saved object types, because that's what you need for the page to function.

We could do a better job making this clear in the UI and in the docs, but it is functioning as intended and we don't provide a way to make this more granular. Saved Objects Management is designed for administrators to use.

[AndrewMcQuerry]

Saved Objects Management is designed for administrators to use.

Just to be sure I understand.. the basic functionality of a user exporting their dashboard/objects that they created and importing them into another cluster. (ie: test -> prod, or cluster a -> cluster b) is intended to be for administrators only?

Does that include the Saved objects API's offered by Kibana? (I'm honestly not sure what privileges/permissions govern a user's ability to use this API... and I can take this part of the topic over to discuss.elastic.co if necessary.)

[jportner]

Just to be sure I understand.. the basic functionality of a user exporting their dashboard/objects that they created and importing them into another cluster. (ie: test -> prod, or cluster a -> cluster b) is intended to be for administrators only?

Yes, that's correct! Not to say that satisfies all use cases, or that we intend to keep it this way for all of time -- just that this is how it was designed.

Note that this level of administration is done on a per-space basis, see below...

Does that include the Saved objects API's offered by Kibana? (I'm honestly not sure what privileges/permissions govern a user's ability to use this API...

That does include Saved Object APIs, yes.

and I can take this part of the topic over to discuss.elastic.co if necessary.)

No need, these are good questions and they are relevant to this issue, IMO.

I might suggest a workaround: if you want to restrict this based on index patterns, you can create a separate space for each group of users that are working with a particular index pattern. Then each user can have "Kibana Admin" access (All privileges for all features) in that space, with full ability to export their dashboards/etc, without worrying about them accidentally mucking up other users' index patterns.

Note that Elasticsearch index privileges are separate from Kibana privileges, so you'd want to set up your roles accordingly, like:

role "team-a": read access to "index-a", `All` access to all features in Space A
role "team-b": read access to "index-b", `All` access to all features in Space B

Users would be able to create new index pattern saved objects, but only for the indices that they are able to access.

---

We have another feature coming down the pike, Object Level Security #39259, which would allow you to assign privileges to users for specific saved objects. It sounds like this could come in handy for your use case too, and paired with Shareable Data Views* (released in 8.2) you could create a data view that is accessible in all spaces but can only be modified by one individual user, for example.

* "index patterns" were renamed to "data views" with the 8.0 release

[AndrewMcQuerry]

Thanks. Spaces is definitely an option, but we've been hesitant for the other items you mention, specifically the fact that "Index Patterns" (which we, as admin's control) would need to be individually created, maintained, curated for each Space created. -- Shareable Data Views appears to be directly addressing that concern and will be a key component to how we implement Spaces once we're ready.

As for Object Level Security, 🤯 . Sounds great... and I really hope that's something that'll be available sooner than later.