[Fleet] Fleet should allow an integration to be installed/reinstalled into another space

[kpollich]

Today, the only mechanism for sharing integration assets between spaces is manually copying the assets to another space. We should investigate the feasibility of Fleet allowing integrations to be installed in multiple spaces, where assets would be fully duplicated in each space.

This would be a stop-gap solution until #167901 is implemented. Once shareable analytics are fully supported, Fleet could install assets in any number of spaces by sharing them across the spaces instead of duplicating the assets.

Implementation plan

• Add new additional_asset_spaces[] property to Installation saved object type
• Add additional logic to integration details page e.g.
  • When installed_kibana_space_id !== current_space_id AND !additional_asset_spaces.includes(current_space_id), e.g. the assets are not installed in the current space at all, but the integration is installed in another space
    • Show a button to install assets in the current space
    • Clicking this button initiates a request to POST /api/fleet/epm/packages/:pkgName/:pkgVersion with two new parameters: additional_space_id and kibana_assets_only that will add the current space to additional_asset_spaces and only attempt to install Kibana assets
  • When installed_kibana_space_id !== current_space_id AND additional_asset_spaces.includes(current_space_id), e.g. the assets are installed in the current space, but the integration itself is installed in another space
    • Show a button to reinstall assets in the current space
    • Button behavior is same as above, but with the force parameter added to reinstall
  • When installed_kibana_space_id === current_space_id
    • Behavior is the same as today. Install/reinstall buttons should behave as they do currently.

[elasticmachine]

Pinging @elastic/fleet (Team:Fleet)

[mbudge]

Yes this would be a very very good improvement. We want to install dashboards to multiple spaces and have them upgraded when the integration is upgraded. We're not using the integration dashboards as last time we deployed them into our multispace Kibana they ended up broken.

[kpollich]

I am spending some time this sprint exploring this functionality. Here's what I am thinking of build as a proof of concept:

• Add new additional_asset_spaces[] property to Installation saved object type
• Add additional logic to integration details page e.g.
  • When installed_kibana_space_id !== current_space_id AND !additional_asset_spaces.includes(current_space_id), e.g. the assets are not installed in the current space at all, but the integration is installed in another space
    • Show a button to install assets in the current space
    • Clicking this button initiates a request to POST /api/fleet/epm/packages/:pkgName/:pkgVersion with two new parameters: additional_space_id and kibana_assets_only that will add the current space to additional_asset_spaces and only attempt to install Kibana assets
  • When installed_kibana_space_id !== current_space_id AND additional_asset_spaces.includes(current_space_id), e.g. the assets are installed in the current space, but the integration itself is installed in another space
    • Show a button to reinstall assets in the current space
    • Button behavior is same as above, but with the force parameter added to reinstall
  • When installed_kibana_space_id === current_space_id
    • Behavior is the same as today. Install/reinstall buttons should behave as they do currently.

We'll need to explore the behavior of duplicating these assets across spaces, as it's not totally clear what will happen to markdown panel links or other objects. So, a major goal of the proof of concept here will be to validate the workflow of duplicating assets into multiple spaces functions acceptably.

[nchaulet]

@kpollich what do you think of creating a dedicated endpoint to install assets in a new space, it's what we had in mind for package install recovery?

POST /s/{space}/api/fleet/epm/packages/:pkgName/:pkgVersion/kibana_assets

What will be the expected behaviour on upgrade/uninstall are we upgrading/removing all assets in all spaces?

[kpollich]

That makes sense, I expect this action will definitely overlap with the package recovery API work.

[kpollich]

What will be the expected behaviour on upgrade/uninstall are we upgrading/removing all assets in all spaces

Yes this is what I had in mind. The assets will appear in the references array regardless of space, and be brought along during upgrade/uninstall.

[kpollich]

I started down the path of implementing this, but I feel that #175592 will be a better path to unlock this functionality. The kibana_assets API that @nchaulet will serve as the backend route that powers the new UI treatment described here, but implementing that API as a one-off without the rest of the new "state machine" package APIs seems like a poor path forward.

Once #175592 has landed, we should only need to wire up the new UI elements here to resolve this issue and perhaps add the additional_kibana_space_ids tracking value to the Installation saved object. Hence marking this blocked for now.

[kpollich]

Relevant issue within the space awareness project: #182735

[nchaulet]

@pgayvallet @jloleysens We change a little the approach we previously discsused to have the installation saved object space agnostics (done in #183920)

Integration are a mix of space aware assets (kibana assets) and global assets ingest pipelines, index templates, and it seems it will be easier for us to manage them with a space agnostic save object and allow to keep track of the space specific assets in a property of that saved object, does that approach make sense to you?

[pgayvallet]

Integration are a mix of space aware assets (kibana assets) and global assets ingest pipelines, index templates, and it seems it will be easier for us to manage them with a space agnostic save object and allow to keep track of the space specific assets in a property of that saved object, does that approach make sense to you?

As long as you're fine with the information for all spaces being stored in an object accessible from any of them (so basically not using spaces RBAC for the kibana-side of your assets), I'd say it could.

It's more a question to ask to the @elastic/kibana-security team though.

[azasypkin]

As long as you're fine with the information for all spaces being stored in an object accessible from any of them (so basically not using spaces RBAC for the kibana-side of your assets), I'd say it could.
It's more a question to ask to the @elastic/kibana-security team though.

At first glance, it might become problematic. Can you please share a bit more info on what information is stored in the installation saved object exactly and what privileges will be required to read or manipulate it so that we can better understand the potential impact?

[nchaulet]

At first glance, it might become problematic. Can you please share a bit more info on what information is stored in the installation saved object exactly and what privileges will be required to read or manipulate it so that we can better understand the potential impact?

@azasypkin we store the reference to the installed assets elasticsearch one and kibana ones, a user will need the Integrations:Read or Integrations:All to manipulate that through Fleet APIs

[harshitgupta-qasource]

Hi Team,

We have created 04 testcases under Testmo for this feature under Fleet test suite at links:

• Validate that on clicking the "Install integration kibana asset in current space" button, Kibana assets are installed to Default space.
• Validate that on clicking the "Install integration kibana asset in current space" button, Kibana assets are installed to Newly created space.
• Validate that on installing the integration in a Default space, the integration is installed in another space and the uninstall/reinstall buttons are visible under the integration settings tab for all the spaces.
• Validate that uninstalling an integration from one space, uninstall it from all spaces.

Please let us know if any other scenario needs to be added from our end.

Thanks!

[harshitgupta-qasource]

Hi Team,

We have executed 04 testcases under the Feature test run for the 8.15.0 release at the link:

• Allow an integration to be installed/reinstalled into another space

Status:

PASS: 04

Build details:
VERSION: 8.15.0 BC4
BUILD: 76261
COMMIT: 9d62937
Artifact: https://staging.elastic.co/8.15.0-a7432175/summary-8.15.0.html

As the testing is completed on this feature, we are marking this as QA:Validated.

Please let us know if anything else is required from our end.
Thanks