Kibana: Allow creating read-only assets

[ph]

Describe the feature:

Allow certain assets like dashboard to be read-only in Kibana. It should not allow the user to modify them and ask them to make a copy instead when making changes. They can manage these assets through Ingest Manager.

Describe a specific use case for the feature:

In the Ingest manager, we plan to take care of installing and upgrading assets like dashboards for the user when they activate an integration. They can also remove the integration to remove the assets. Thus, the lifecycle of the assets is controlled at the system level by Ingest Manager.

If the user is allowed to modify an installed dashboard, those changes may be overwritten when the package assets are manually or automatically upgraded. If dashboard would be set to read-only we would be free to upgrade the canonical dashboard and let people customize their own copies.

[elasticmachine]

Pinging @elastic/kibana-app (Team:KibanaApp)

[ruflin]

A bit more details on the expected the behaviour. If a users wants to modify a dashboard, it would copy the dashboard and all its related assets like the visualisations / searches etc so the user has a copy. This ensures we can update / remove read only assets without breaking user dashboards. Also users should not be able to include read only visualisations in there dashboard but instead a copy of it.

[mostlyjason]

@alexfrancoeur Are you the right PM for this request? We recently added this to the top asks spreadsheet.

[mostlyjason]

I renamed this to read-only assets because our end goals is to also apply this to dashboards, visualizations, API keys, etc. Is it better to have separate issues for each of those? If so, I'd rename this back to dashboards.

[alexfrancoeur]

This _feels_ like Object Level Security (OLS) as defined in thttps://github.com/elastic/kibana/issues/39259, so I'll tag a few more folks. At the moment, we do not have the ability to set permissions on a specific object. That being said, a dashboard is made up of multiple saved objects - one or multiple index patterns, one or multiple visualizations, one or multiple maps, etc. There are plans to simplify this in the future so a dashboard does not use this reference model but instead, persists all visualizations within the same json object. I'd imagine that will come into play with this proposal, regardless of security requirements. @mostlyjason I know this has been an issue with beats modules for quite some time, but what's the priority from Ingest Manager? Top asks is a good place to start the discussion. I do not believe we have plans to tackle this type of request in the 7.x series, but if we view it as a requirement for GA we should probably meet soon to discuss. I wonder if there are some alternative ways to support outside of a full OLS implementation.

cc: @arisonl @kobelb @legrego @AlonaNadler @VijayDoshi

[mostlyjason]

Thanks @alexfrancoeur I think OLS could potentially work. Another option is to treat them as system objects of some kind. but I'm not sure if Kibana supports that or will sooner than OLS.

Adding @andresrc @exekias to comment on whether dashboards should be made of multiple saved objects. We are doing a clean start on packages so this might be an opportunity to reconsider how Beats modules handled it.

[kobelb]

OLS is a significant undertaking, and it hasn't been started yet. Also, OLS is rather coupled to Kibana's authorization model, which we really shouldn't be relying upon here. Even when users aren't utilizing the Stack's security, we'd want these Dashboards, Visualization, etc. to be read-only so they can be automatically updated without fear of losing the end-users changes. This seems like a net-new request which I haven't heard from elsewhere.

[timroes]

Thanks for filing this. I agree with @kobelb here, that OLS is not really the solution here. I think if we want this, we need "machine created" saved objects, that are not editable by the user. I am not sure if this is some extension we need in the saved object core to make this happen, across all saved objects (cc @joshdover), or if we need to implement this on a per application level. Even with a central infrastructure we still need to have some parts (like copying dashboards and copying assets) on a per application level.

I just want to raise awareness here, that this is not a small request, and designing and implementing this, will take quit some time, so it's nothing you should be expecting to be around within the next minor version(s).

[arisonl]

How do these assets play with spaces? I presume they should be space agnostic?

[kobelb]

How do these assets play with spaces? I presume they should be space agnostic?

Unfortunately, it's not currently possible to have a subset of Dashboards, Visualizations, etc be "space agnostic". The @elastic/kibana-security team is exploring the complexities of allowing a Dashboard, Visualization, etc to be available at * spaces, but it's not possible yet. Assuming this is possible, it will also require the assets opt-in to being shareable in multiple spaces to take advantage of this.

[mostlyjason]

I'll just mention there is an another proposal to implement tagging https://github.com/elastic/kibana/issues/74571. One alternative solution is to show a warning to users when they attempt to change assets with a specific tag. This is not as strong of a control as making them read-only, but it might still help prevent users from making changes to assets that will be overwritten.

[ruflin]

@mostlyjason I like your idea as a "low hanging fruit" to at least indicate users something is read-only. I would assume it is just a tag, no errors / warnings show. But I don't think it will replace the feature requested here as read-only will also have some features like users can easily copy all dependencies etc.

[mostlyjason]

@ruflin a deep copy/clone feature could be separate from marking assets read-only. Would it make sense to split into two issues?

[ruflin]

@mostlyjason Happy to have it split out if needed. Agree that it might become a feature of its own.

[elasticmachine]

Pinging @elastic/kibana-platform (Team:Platform)

[kobelb]

Ingest Manager packages don't only contain Kibana assets, they also contain Elasticsearch assets. As such, I don't think we should be planning on implementing a Kibana-specific solution without ensuring that it's compatible with the solution to protect Elasticsearch assets.

[rudolf]

I wonder if the problem here isn't more about the user experience and UI than real security on the API / Elasticsearch level.

If dashboards added a readonly field and adapted the UI to display a "clone and edit" button instead of "edit" that would provide a nicer user experience than editing, pressing "save" and then perhaps getting a read-only object error.

Even though users could theoretically circumvent this UI by using the Saved Objects API or even editing objects in the ES index this might be sufficient 99% of the time. To prevent data loss for the other 1% ingest manager can compare the existing dashboard to known previous versions. If it detects that a dashboard has been altered by a user it can log an error and refuse to override it, or maybe create a new dashboard object and rename the old one with "[backup] Ingest manager dashboard".

One day when we have OLS we can then come back to this again.

[roncohen]

I wonder if the problem here isn't more about the user experience and UI than real security on the API / Elasticsearch level.

Absolutely. This is not about security. It's to protect people from accidentally editing dashboards that will then get replaced by a new version of the dashboard when the package gets upgraded. I was hoping we could do something simple for this.

[rudolf]

We should probably apply a Neededfor: label. I'm not 100% sure where ingest manager fits in, would Neededfor:endpoint be the correct one?

[ruflin]

@rudolf I guess we need a new one here: Neededfor:fleet.