[Breaking change] Prevent disabling the spaces plugin

[legrego]

Change description

We would like to remove the ability to disable the Spaces plugin in 8.0 (xpack.spaces.enabled)

Which release will ship the breaking change?

8.0

Describe the change. How will it manifest to users?

Users who have explicitly disabled Spaces via xpack.spaces.enabled will no longer be able to do so.

How many users will be affected?

Telemetry indicates that this will impact a very small number of installations. Most administrators run with Spaces enabled, which is the default behavior.

What can users do to address the change manually?

N/A

How could we make migration easier with the Upgrade Assistant?

Indicate that they must enable the Spaces plugin in order to upgrade to 8.0

Are there any edge cases?

No.

Test Data

Testing with spaces disabled:

xpack.spaces.enabled: false

Cross links

#89584

[elasticmachine]

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

[elasticmachine]

Pinging @elastic/es-ui (Team:Elasticsearch UI)

[alisonelizabeth]

Hi @legrego! I'm going to remove the Elasticsearch UI team label. Please consider using the deprecations service (#94845) provided by core to register this deprecation. All registered deprecations will be displayed in the Upgrade Assistant (to be implemented via #97159). Feel free to reach out to myself or the core team with any questions!

[legrego]

Hey folks, I'm noticing a number of 👎 reactions to this issue, and I'd love to get a better understanding of your sentiment. Is anyone willing to share their thoughts in more detail?

I'd love to know:

1. What version of Kibana are you running?
2. Why do you have the spaces plugin disabled today?
3. How would you be negatively impacted if the spaces plugin could no longer be disabled?
4. Any other thoughts you'd like to share about Spaces?

[pchakour]

Hey !

What version of Kibana are you running?

I'm running on Kibana 7.12.1 for now

Why do you have the spaces plugin disabled today?

I've wrote a similar plugin, so the spaces plugin is not necessary in my context.
My plugin allow to separate saved objects in "projects".

In what is different from the spaces plugin ?

• There is an administrator for each project
• A user can ask the administrator to belong to a project
• The administrator can affect different feature visibilities by user in his project
• Some advanced settings are considered as user settings (ex: the dark mode)

How would you be negatively impacted if the spaces plugin could no longer be disabled?

Projects' concept is similar but different in the way to manage it.
If I'm not able to disable the spaces plugins anymore, I will need to find a way to patch the Kibana core to disable it to avoid unexpected conflicts and users misunderstanding.

Why do you want remove the ability to disabled it ? Is there technical issues if the plugin is disabled in Kibana 8 ?

[legrego]

@pchakour, thanks for taking the time to share your concerns.

This doesn't help you at all, but some of the differences you outlined are enhancements that we also have planned for Kibana, although the timeline for them isn't clear yet.

If I'm not able to disable the spaces plugins anymore, I will need to find a way to patch the Kibana core to disable it to avoid unexpected conflicts and users misunderstanding.

Are you leveraging the same hooks/core APIs as the Spaces plugin to achieve saved object isolation?
If the two plugins are able to co-exist, then I wonder if it would be possible for you to configure xpack.spaces.maxSpaces: 1 within your kibana.yml (Link to docs). That would effectively mean that you couldn't create any custom spaces, and everything would exist within the system-created "Default space".

Why do you want remove the ability to disabled it ? Is there technical issues if the plugin is disabled in Kibana 8 ?

We have a few of reasons for wanting to remove this ability:

1. It complicates our security model
   Spaces is an important component of our security model. It's possible to grant access to a subset of spaces, and a subset of features within those spaces. (This sounds similar to The administrator can affect different feature visibilities by user in his project).
   Since we allow Spaces to be disabled, that means we have to support two different security models: one with spaces, and one without. Not only does this complicate our authorization subsystem, it also means we have to support two different role management interfaces. As it's often said: "complexity is the enemy of security", and we are looking to reduce the complexity here as much as possible.

2. It complicates feature development
   We have an increasing number of features that integrate with Spaces today. Some of these features have an "optional" dependency on Spaces, and others have a "required" dependency on Spaces. Over time, I expect that more and more features will choose to have a "required" dependency, which means that disabling the Spaces plugin will leave you with reduced functionality, as all dependent plugins will also be disabled.
   Features that have an "optional" dependency need to support two very different experiences, depending on whether or not Spaces is enabled. This increases design & engineering complexity, and is more error-prone.

3. It explodes the number of testing combinations
   Since Spaces + Security are so tightly integrated, we end up needing to maintain tests (& testing infrastructure) to support the following combinations:

   • Spaces enabled, Security enabled
   • Spaces enabled, Security disabled
   • Spaces disabled, Security enabled
   • Spaces disabled, Security disabled

Removing the ability to disable spaces cuts the amount of test infrastructure in half, which is huge. We spend a significant amount of time writing these tests, and they account for quite a bit of our CI/build time.

---

All of the above reasons are exacerbated by the fact that users can enable/disable the spaces plugin at will by changing kibana.yml and restarting their instance (e.g. it's not just a one-time setting). This means that the Kibana runtime needs to be able to handle saved objects (& other data) that might be space-aware, even if spaces is disabled.

For what it's worth, this is part of a larger initiative to create a more stable runtime for Kibana, by reducing the number of plugin combinations that can be configured at runtime: #89584

[pchakour]

Thanks for the answer, it's very clear 👍

I get it the concern about the complexity to maintain dependencies between plugins. It's obvious that the complixity and the testing combination will increase with the time. Hope somedays all spaces plugin features will fit my needs :-)
At the meantime, I will found a way to run my plugin...

Are you leveraging the same hooks/core APIs as the Spaces plugin to achieve saved object isolation?

Actually, I wrote my own wrapper for saved objects client. The only thing I use from the spaces plugin source code is the function to extract the space name from the URL. I checked the code aboutxpack.spaces.maxSpaces option and I didn't find conflicts with my plugin.

In order to avoid users misunderstanding, is it possible to hide spaces features to users by switching spaces capabilities to false ?

[legrego]

In order to avoid users misunderstanding, is it possible to hide spaces features to users by switching spaces capabilities to false ?

Yes, you can register your own Capabilities Switcher to turn these off. Completely untested, but something like the following should do the trick:

// inside of your plugin's `setup` lifecycle method
core.capabilities.registerSwitcher(() => {
	return {
      spaces: {
        manage: false,
      },
      catalogue: {
        spaces: false,
      },
      management: {
        kibana: {
          spaces: false,
      },
    };
});

[pchakour]

Ok I will try it later !

Thank you so much for your help :-)