Allow plugins to register default saved objects that will be created for every space.

[stacey-gammon]

What

Support the ability to create a default saved object in every space.

Why

This is a blocker for SIEM to use embedded dashboards, which gives them background search capabilities for free, along with features like custom overview pages.

Every user, in every space, needs to be able to navigate to SIEM and see the overview page dashboard, that is backed by a saved object.

cc @elastic/kibana-security @elastic/kibana-platform

[legrego]

I'm wondering if this is something that should be provided by OSS Kibana. If Spaces is disabled, should a fresh Kibana installation have these default objects created on startup?

I admittedly don't know a whole lot about the embeddable actions plan/roadmap, but it seems to me like we would want this capability to exist regardless of Spaces being in the mix. I think that spaces can definitely leverage these default saved objects when creating a space, but I don't know if the Spaces plugin should own the concept itself.

[stacey-gammon]

that makes sense @legrego. fwiw we worked around this so it's no longer a blocker. We are just having users dynamically create saved objects, but also having a registry of items that developers can use to register global items. Downside is that now two sources need to be merged when for instance someone wants all actions, the logic needs to grab actions from the registry and actions from the kibana index. So I suspect this will now go on the back burner as there is no pressing need for it. I can just close too, and if someone else wants the feature they can re-open.

[stacey-gammon]

Re-opening this for the SIEM team, they would like to embed default dashboards in their solution that are editable, as well as the visualizations inside the dashboard to be editable. So the "load embeddable by value" instead of by saved object reference id, doesn't really work in their use case.

cc @andrew-goldstein

[stacey-gammon]

Just want to add that if we decide not to support passing down indices as strings for things like Lens and Visualize Embeddables (as opposed to index pattern objects), many teams will need this.

[andrew-goldstein]

Note: The SIEM team must (in the short term) seed spaces with Detection Engine rules, which are saved objects. These rules must be versioned, to support updates in future releases.

Versioning requirements (and handling updates) should also be considered when populating spaces with saved objects for embeddable:

• Kibana dashboards
• Kibana visualizations
• Kibana Index Patterns (see also: the Synchronization Issues With Kibana Index Patterns Referenced by Embeddables comment in #16917 - Dashboard level index patterns)

[stacey-gammon]

@legrego - Syncing back around to this.

Could a simple solution be possible to use the kibana_system user to check for and create these default saved objects every time the app is rendered? It wouldn't work using the logged in user because we want people with read only capabilities to still have a SIEM overview page in a new space.

[legrego]

@legrego - Syncing back around to this.

Could a simple solution be possible to use the kibana_system user to check for and create these default saved objects every time the app is rendered? It wouldn't work using the logged in user because we want people with read only capabilities to still have a SIEM overview page in a new space.

Yes, this could be viable.

It's possible to create an instance of the SavedObjectsClient without the security wrapper applied. This will give you a client that is still space-aware, but will NOT ENFORCE any access checks (so you have to be extremely careful when using it). The Alerting team is working through a PR which leverages this in order to layer their own security model on top of what we're providing:

https://github.com/gmmorris/kibana/blob/80fe0fd030ccca07110004f69277525ed1a41e2c/x-pack/plugins/alerts/server/alerts_client_factory.ts#L77-L80

With this client created, you can expose an endpoint (secured by an access: tag via feature controls) which your app can call when rendered to ensure that your requisite objects exist in the current space.

[stacey-gammon]

@andrew-goldstein Copying your comment over here from #43879

---

The pattern of creating things on demand when a user visits a page in an app (like the Detections page) is associated with open issues, community posts, and bugs:

• There's still an open issue for how to handle read-only users when they visit the Detections page

• This community post is an example of this pattern producing a less-than ideal OOTB experience. Novice users, who may not be familiar with Elasticsearch security privileges, must navigate the following documentation, which again, is less than ideal.

• This recent fix in another part of the SIEM app was necessary because there's no guarantee a user with proper permissions visited the Detections page before using another part of the app. When there are no guarantees that things exist, branching logic must exist throughout the app to compensate.

---

Have you looked into doing something similar to what the alerting team is doing to avoid permission issues when seeding the default saved objects using the logged in user's credentials?

If you put this logic in the setup or start method of your plugin, could you avoid the issue with the user not visiting the right page to trigger the creation?

[mikecote]

Just jumping in to add a +1 for a feature like this. The alerting team is also exploring the possibility to have pre-configured alerts which would translate to saved objects created and space-agnostic (#59813). We may be able to benefit from some or all of this feature to solve our problem.

We also now have pre-configured connectors (https://www.elastic.co/guide/en/kibana/7.8/pre-configured-action-types-and-connectors.html) that aren't saved objects at this time but could be in the future.

We're not blocked by this as we can do as mentioned above and get an instance of the saved objects client w/o security wrapper and create our saved objects on startup.

[legrego]

Thanks for adding your use case, @mikecote. Since your saved objects are space-agnostic, it sounds like you need them created on startup, rather than whenever a space is created? If I'm understanding correctly, then I think this is a +1 for my earlier comment about core/platform owning this base functionality

[mikecote]

Yeah, that's correct. For the alerting team, it would make sense for it to be a core/platform feature because our use case is space-agnostic.

[chrisronline]

One possible way to handle this to create this default saved objects that are read-only, but allow a way in the UI to "copy" the SO to the users space and then they can edit it and have the appropriate permissions established. This would work well for Stack Monitoring and our concept of "out of the box alerts" - something that is there by default and functional for all users/spaces, but an option in the UI to "copy" into another space (or even "cut" where it disables/deletes the default one). For us, we really just need to provide the safety net of alerts without users needing to know or do anything and I have to imagine other solutions will want this too.

[ppisljar]

what about using non-persisted object for the default usecase ? so we don't need to have a saved object in every space (that we don't allow deleting) but rather not have a saved object at all for that case and provide it in code ?

[legrego]

One possible way to handle this to create this default saved objects that are read-only, but allow a way in the UI to "copy" the SO to the users space and then they can edit it and have the appropriate permissions established. This would work well for Stack Monitoring and our concept of "out of the box alerts" - something that is there by default and functional for all users/spaces, but an option in the UI to "copy" into another space (or even "cut" where it disables/deletes the default one). For us, we really just need to provide the safety net of alerts without users needing to know or do anything and I have to imagine other solutions will want this too.

Support for read-only saved objects is being discussed here: #70461

what about using non-persisted object for the default usecase ? so we don't need to have a saved object in every space (that we don't allow deleting) but rather not have a saved object at all for that case and provide it in code ?

Would non-persisted objects be accessed via the existing saved objects service, or handled within application code directly?

[ppisljar]

I think they should be used directy. I may not have the full context, but this is how this could work:

• when user gets to SIEM overview page, on-the-fly index pattern (no saved object, everything is defined in code) is used to show the default view
• we also present user with a dropdown where he can choose any of the saved index patterns
• user can add runtime fields to the on-the-fly index pattern (as well as any existing index patterns if those were selected)
• when user adds runtime field to on-the-fly pattern we show a warning that changes are not persisted and give user an option to save this configuration as his own index pattern (backed by saved object at this point)
• we could also always show default view in the index pattern dropdown, which would allow user to get back to this on-the-fly pattern that is defined in code

benefits:

• index pattern is defined from code so noone can change it or delete it
• when someone wants to change something all he needs is to persist the changes (create a saved object)
• we don't need to worry about migrations (as its defined in code)
• no needed changes to our infrastructure to achieve above usecase ?

[legrego]

Direct use makes sense to me as well. I was initially concerned about the lack of security controls and audit logging we would have with direct use, but it's probably not an issue in practice because they won't be persisting anything, or querying for anything that's specific to their deployment.

[alexfrancoeur]

Related request from the ingest team (system generated immutable SO's): #70461

[ppisljar]

Thank you for contributing to this issue, however, we are closing this issue due to inactivity as part of a backlog grooming effort. If you believe this feature/bug should still be considered, please reopen with a comment.