Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
stacey-gammon opened this issue Mar 19, 2019 · 18 comments
Labels
enhancement New value added to drive a business result Feature:Data Views Data Views code and UI - index patterns before 8.0 Feature:Security/Spaces Platform Security - Spaces feature impact:low Addressing this issue will have a low level of impact on the quality/strength of our product. loe:small Small Level of Effort Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more!

Comments

@stacey-gammon
Copy link
Contributor

stacey-gammon commented Mar 19, 2019

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

@stacey-gammon stacey-gammon added Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more! enhancement New value added to drive a business result Feature:Security/Spaces Platform Security - Spaces feature :AppArch labels Mar 19, 2019
@legrego
Copy link
Member

legrego commented Apr 2, 2019

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor

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
Copy link
Contributor Author

@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
Copy link
Member

legrego commented Jun 16, 2020

@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
Copy link
Contributor Author

@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
Copy link
Contributor

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
Copy link
Member

legrego commented Jun 17, 2020

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
Copy link
Contributor

mikecote commented Jun 18, 2020

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
Copy link
Contributor

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
Copy link
Member

ppisljar commented Jan 26, 2021

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
Copy link
Member

legrego commented Jan 26, 2021

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
Copy link
Member

ppisljar commented Jan 27, 2021

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
Copy link
Member

legrego commented Feb 3, 2021

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
Copy link

alexfrancoeur commented Feb 4, 2021

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

@ppisljar ppisljar added impact:needs-assessment Product and/or Engineering needs to evaluate the impact of the change. Feature:Data Views Data Views code and UI - index patterns before 8.0 loe:needs-research This issue requires some research before it can be worked on or estimated labels May 4, 2021
@exalate-issue-sync exalate-issue-sync bot added impact:low Addressing this issue will have a low level of impact on the quality/strength of our product. loe:small Small Level of Effort and removed impact:needs-assessment Product and/or Engineering needs to evaluate the impact of the change. loe:needs-research This issue requires some research before it can be worked on or estimated labels Jun 21, 2021
@ppisljar
Copy link
Member

ppisljar commented Aug 9, 2022

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.

@ppisljar ppisljar closed this as not planned Won't fix, can't repro, duplicate, stale Aug 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New value added to drive a business result Feature:Data Views Data Views code and UI - index patterns before 8.0 Feature:Security/Spaces Platform Security - Spaces feature impact:low Addressing this issue will have a low level of impact on the quality/strength of our product. loe:small Small Level of Effort Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more!
Projects
None yet
Development

No branches or pull requests

7 participants