Description
Issue 1
Fleet integrations and policies are not constrained to a space, e.g. all integrations and all policies are all available to any user who has sufficient privileges to see them, in all spaces. It does not matter whether they're in "space1", they will always see all integrations and all policies created in "space1" and in "space2".
This is confusing, and limits the usefulness of spaces, it also bypasses intended RBAC and space access restrictions revealing information to users who should not be able to see integrations in other spaces.
This also means they can access configured integrations and access credentials and other secrets (API keys etc) that they should not be able to access.
Kibana/Fleet should understand and respect the relationship between individual integration instances and the space they have been deployed in when multiple integrations across multiple spaces are used, only showing the relevant integrations installed within the current space as installed. Integrations deployed in other spaces should not be seen by a user working within a space.
Issue 2
A direct effect of issue 1.
Integration assets are only deployed in the first space the integration is first deployed in.
It is not possible to redeploy integration assets in other spaces, except by manually copying them between spaces from the "Management" -> "Saved Objects" page.
Or by exporting and reimporting saved object NDJSON files.
Kibana/Fleet should identify missing assets, and permit installation and reinstallation (overwrite) of all Kibana assets for an integration, into any space, if they do not currently exist as a Saved Object in the current space the user is working within.
Issue 3
Combination of issue 1 and 2.
Using the Palo Alto Networks Logs integration as an example.
If I have 2 x integration instances, both on v1.6.0 and v2.1.0 has just been released.
The first integration is in space ID "space1" and the second integration is in space ID "space2"
If I use the upgrade function in Kibana/Fleet webUI, it will upgrade the first instance of a deployed integration to v2.1.0, in "space1"
But it will leave the integration in "space2" on v1.6.0 and it will not upgrade it.
At this point there are no options in the webUI to manually upgrade the v1.6.0 integration that has been left hanging, regardless of whether I attempt this from the "default" space, or "space1" or "space2".
There is no documentation available on how to correct this, and no obvious API endpoint to trigger upgrade of the integration.
The only option seems to be to delete the v1.6.0 integration and recreate it.
This also appears to mean that the ingest pipeline for v1.6.0 no longer exists, as the only integration pipeline in existence at this point is the v2.1.0.
I believe this means that logs will be lost by agents assigned the v1.6.0 integration.