Add ability to share a saved-object in all current and future spaces

[jportner]

This feature is based on the outcome of our investigation in #58756.

Overview

#27004 is an enhancement to allow Kibana's saved objects to be shared to multiple spaces. This feature is currently in the process of being implemented in multiple phases. In the current approach, consumers are required to specify each space explicitly.

We want to support the ability to share a saved object to all current and future spaces (defined as '*'). This supports several use cases, for example, importing Observability dashboards once that are visible in all spaces.

Terminology

• Space: A special type of saved object. This has a name, id, and a few other attributes. A space itself is namespace-agnostic.
• Namespace: An implementation detail of saved objects that allows them to be linked to one or more space. Each multi-namespace (shareable) saved object has a namespaces array. For each string in an object's namespaces array, the object is said to exist in that namespace (even if there is no space with a matching ID).

Technical Approach

A multi-namespace saved object has a namespaces array which contains a list of explicitly-defined namespaces. Each namespace string correlates to the space with the same ID.

If a saved object exists in the '*' namespace, this will supersede all other namespaces, and the object is treated as if it exists in all spaces. Primarily this affects the SavedObjectsRepository (responsible for CRUD operations to Elasticsearch) and the SecureSavedObjectsClientWrapper (responsible for authorization checks).

When using the UI to edit a saved object's shared spaces, the addToNamespaces API is always called before the deleteFromNamespaces API. This process will remain unchanged.

Example of sharing to all spaces

Kibana has two spaces: the Default space, and the Other space. A dashboard exists in the Default space:

{ type: 'dashboard', id: 'foo', namespaces: ['default'] }

A user wants to share this dashboard to All Spaces. The client makes two API calls:

savedObjectsClient.addToNamespaces('dashboard', 'foo', ['*']);
// { type: 'dashboard',  id: 'foo', namespaces: ['default', '*'] }
savedObjectsClient.deleteFromNamespaces('dashboard', 'foo', ['default']);
// { type: 'dashboard',  id: 'foo', namespaces: ['*'] }

Later, the user is working in the Other space, and decides to unshare the dashboard from All Spaces. The client makes two more API calls:

savedObjectsClient.addToNamespaces('dashboard', 'foo', ['other']);
// { type: 'dashboard',  id: 'foo', namespaces: ['*', 'other'] }
savedObjectsClient.deleteFromNamespaces('dashboard', 'foo', ['*']);
// { type: 'dashboard',  id: 'foo', namespaces: ['other'] }

Changes

The changes that will need to be made to implement this feature are as follows.

Server-side changes

• getQueryParams and SavedObjectsRepository namespace handling: These need to be modified to handle the '*' appropriately, treating it as if it is all namespaces.
• SavedObjectsRepository.delete behavior: Currently, if you delete an object that exists in multiple namespaces, it will just remove the object from the current namespace. Otherwise, if the object only exists in one namespace, it will delete the object. To make this more consistent, we'll change this to always delete an object, but throw an error if the object exists in multiple namespaces or all spaces (this error can be overridden with a new force parameter).
• SavedObjectsRepository.create and SavedObjectsRepository.bulkCreate: Currently, when you create an object, it is transparently added to the current namespace. We'll change this so consumers can specify namespaces when an object is created.
• HTTP routes for '/api/saved_objects/_create' and '/api/saved_objects/_bulk_create': To expose the changes to create and bulkCreate to external consumers.
• copySavedObjectsToSpaces and resolveCopySavedObjectsToSpacesConflicts: These need to be changed to throw an error for any object that exists in all spaces, and omit any referenced objects that exist in all spaces. Update: we don't need to throw an error (this is an experimental API, the consumer just needs to be aware this is not allowed), and we don't need to omit any referenced objects (this has been added as a task in Phase 3 where we will support referential integrity).
• HTTP routes for '/api/spaces/_share_saved_object_add' and '/api/spaces/_share_saved_object_remove': These currently do not allow using the '*' character in a space ID argument.

Note: regardless of what operation is occurring, the user must be authorized to take the appropriate action in the current space. In theory you could attempt to create an object that exists in the Other space while in the context of the Default space; in that case you would need 'create' privileges in both spaces.

Client-side changes

• 'Saved Objects' management table ('Shared spaces' column): This will need to be changed slightly to reflect when an object is shared to all spaces.
• 'Share to space' flyout: This will need to be changed to handle the option to share to all spaces:
  • A "Share to all" option should be present that is mutually exclusive from other options
  • If a user has global permissions, the "Share to all" option should be enabled; otherwise, it should be disabled.
  • If a user does not have global permissions, they should not be able to change shares for an object that is already shared to all spaces.
• 'Copy to space' flyout: This will need to be changed to display a "disabled" message when an object is shared to all spaces.

[elasticmachine]

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