Kibana: [discuss] Remove the ability to disable plugins in production

[joshdover]

In https://github.com/elastic/elasticsearch/issues/54745, Elasticsearch removed the ability to disable basic features in order to simplify the implementations of other commercial features that depend on basic features. Their primary motivation:

Many of our basic-license features are important building blocks of higher-level features. For example, Machine Learning can use Index Lifecycle Management to easily manage internal indices. However, if it's possible to disable these basic plugins, then the higher-level features need to account for the case when the basic plugins are disabled, and sometimes even re-implement what those plugins can do in the case that the lower-level plugins are disabled. Further, allowing these settings to be disabled on a per-node basis leads to the unfortunate situation of inconsistent settings on different nodes.

Kibana's plugin dependency resolution is a bit more sophisticated than Elasticsearch's in that plugins may declare optional or required dependencies to ensure that a plugin is present if it truly is a needed in implementation. This allows us to avoid the problems encountered in Elasticsearch, however there are still good reasons we may want to copy Elasticsearch's approach here:

1. Optional dependencies in Kibana may be handled incorrectly by plugins. A plugin's dependencies are typed manually by the plugin and if they do not match the optional & required deps listed in the kibana.json it's possible for a plugin to encounter an "NPE" creating a bug for users.
2. We have implicit cross-plugin dependencies today. Registries allow plugins to implicitly depend on other plugins without realizing it. While there are ongoing discussions about how to fix this, this scenario already exists today and is a bug waiting to happen.
3. Disabling some plugins may result in a useless or even broken Kibana. In practice, there are a number of plugins that Kibana cannot do much without (eg. data plugin). There are also plugins that Core implicitly depends on (eg. home plugin) that would break if some functionality if disabled.
4. Two overlapping mechanisms for disabling functionality: feature controls & config. Since the advent of feature controls (which is available in the free Basic tier), Kibana admins now have two methods for disabling functionality. This can lead to confusion for users and support.
5. Consistency with Elasticsearch. There are multiple ongoing efforts trying to make configuration across the Stack consistent. Not allowing features to be disabled in Elasticsearch but allowing it in Kibana is a confusing experience.

I would like to open the discussion for removing the ability for users to disable plugins in production, but retaining this feature in development mode.

Reasons to keep this feature in development:

1. It enforces best practices while reducing risk to users. We should and will continue to ensure that implicit dependencies between plugins do not exist, but allows us to reduce the risk that an implicit dependency breaks a user's deployment.
2. Allows us to support "focus mode" to improve the developer XP. We can greatly improve the performance of Kibana in development by allowing a developer to specify the part of the application they need to work on and only starting those components. This is only possible if we have strict enforce dependencies between plugins.
3. Gives us flexibility in the future. If Kibana ever were to release different "flavors" that are focused on specific use-cases (eg. Observability, Enterprise Search, etc.), having this feature in our back pocket will make this much simpler.

Similar to https://github.com/elastic/elasticsearch/issues/54745, we may want to consider the security plugin separately since it does have different implications when it is disabled. @elastic/kibana-security may have more thoughts on that as well.

Open questions:

• Are there legitimate use cases for disabling particular plugins in Kibana?
• Would this create future problems by making implicit dependencies harder to catch? (an aside: would the new build system on Bazel fix this?)

cc @elastic/kibana-platform @elastic/kibana-app-arch @elastic/kibana-operations

[legrego]

Similar to elastic/elasticsearch#54745, we may want to consider the security plugin separately since it does have different implications when it is disabled. @elastic/kibana-security may have more thoughts on that as well.

I agree that security likely needs special consideration, and potentially spaces since they are so interwoven right now.

For "focus mode" specifically, I would want to ensure that security and spaces are both enabled here, even if not explicitly depended on. Disabling these plugins at dev time will make it too easy for engineers to ignore the complexities of the security model, and/or multi-space setups.

Are there legitimate use cases for disabling particular plugins in Kibana?

I could see an argument for an administrator wanting to disable fleet in certain setups. Even if there there weren't any roles created with access to Fleet, that wouldn't prevent a superuser, or other similarly powerful user from deploying agents if they were to get access to another machine. Similarly for endpoint (siem?), an administrator may want an extra level of protection that a certain instance of Kibana won't _ever_ be able to communicate with (or control) endpoints.

There have also been security advisories issued in the past, where the only reasonable remediation (short of upgrading) is to disable a vulnerable plugin. This is a pretty important feature in my opinion, especially for our on-prem users who won't get the benefit of magically patched instances like we offer on ESS

• ESA-2019-17
• ESA-2019-12
• ESA-2019-09
• ESA-2019-02
• ESA-2018-17
• ESA-2018-18
• ESA-2017-24
• ESA-2017-07

[tylersmalley]

From my observations, the most common reason for users to disable a plugin is it's the easiest and was historically the only way to prevent users from accessing a feature. An example of this would be a marketing team having a dedicated Kibana instance where the administrators don't want them to access Dev Tools/Console. Now that we have more fine grained control over these, I think we're covered.

[legrego]

What if we took a middle ground, and allowed "solution" plugins to be disabled, while preventing "platform" plugins from being disabled? That would allow all of our solutions to depend on the core features that make up the platform, while still giving us the flexibility to disable features which are either not needed by a particular install, or are found to be vulnerable.

I haven't enumerated all of the plugins, but I'd loosely say that plugins maintained by @elastic/kibana-platform , @elastic/kibana-app-arch, or @elastic/kibana-security are all candidates for "always-on", while the rest are eligible to be disabled.

If we think that's a worthwhile distinction, then we can draft up a more definitive table of plugins and ensure that we have a plan for 8.0 to make this happen.

[pgayvallet]

From my observations, the most common reason for users to disable a plugin is it's the easiest and was historically the only way to prevent users from accessing a feature

That's also still the only way to do it in a OSS distribution, right?

What if we took a middle ground, and allowed "solution" plugins to be disabled, while preventing "platform" plugins from being disabled? That would allow all of our solutions to depend on the core features that make up the platform, while still giving us the flexibility to disable features which are either not needed by a particular install, or are found to be vulnerable.

Naive question, but would disabling a plugin only disable access to its registered applications be an option here?

[legrego]

Naive question, but would disabling a plugin only disable access to its registered applications be an option here?

Are you asking if the plugin would still be initialized and go through the normal plugin lifecycle? If so, then that's not my expectation. I would expect a disabled plugin to behave much like it does today: it won't be initialized, and it won't participate in the lifecycle.

Do you have a scenario in mind where we would want a disabled plugin to participate in the lifecycle?

[pgayvallet]

Do you have a scenario in mind where we would want a disabled plugin to participate in the lifecycle?

Not really. I was just wondering it this could be a 'quick' fix for point 2. and 3. of this issue's description. But after thinking a little more about it, it would not work anyway, for security for example. Letting the plugin initialize while disabled the login and logout app would just broke everything. Forget I said anything.