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:
kibana.json
it's possible for a plugin to encounter an "NPE" creating a bug for users.data
plugin). There are also plugins that Core implicitly depends on (eg. home
plugin) that would break if some functionality if disabled.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:
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:
cc @elastic/kibana-platform @elastic/kibana-app-arch @elastic/kibana-operations
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
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.
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.
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?
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?
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.
Most helpful comment
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.