By default, a plugin should not be disable-able

[stacey-gammon]

In an effort to create a more stable and well-tested architecture, starting in 8.0 we will require every plugin to explicitly opt-in to the ability to be disabled via the yml config file.

We have many small plugins that were not built with this capability in mind, and we don't test all of the possible permutations. Moving forward, we want developers to intentionally choose this feature for their plugin.

To make a plugin disable-able, you add an enabled setting in your plugin's config:

// myplugin/server/index.ts
export const config = {
  schema: schema.object({
    enabled: schema.boolean({ defaultValue: true }),
  }),
};

Plugins without enabled in their config will be turned on by default and cannot be disabled in the Kibana yml config or cli.

Plugins without any config schema implicitly have enabled added, however we will be removing this in 8.0.

Here is a list of plugins which currently specify an enabled config. We believe the vast majority of these do not have a strong need to support disabling. However, if you own a plugin listed below and you believe it should support disabling, please add a yes to the table.

Additionally, if you own a plugin which isn't on this list because it doesn't have a config schema (as in Josh's list below), please speak up if you are relying on enabled being added to your plugin implicitly. Otherwise, your plugin will no longer be disable-able in 8.0.

Toward the end of the 7.16 dev cycle, we will open a PR removing enabled from any plugins that don't have a yes indicated below. To prepare for this update, we'd ask that folks review the affected plugins by 31 August 2021.

Plugin	Owner	Must be disable-able in 8.0?
apm_oss	@elastic/apm-ui
console	@elastic/kibana-stack-management	no
interactive_setup	@elastic/kibana-security	yes
newsfeed	@elastic/kibana-core	yes
telemetry	@elastic/kibana-core	yes
timelion	@elastic/kibana-app	removed in 7.16
vis_type_markdown	@elastic/kibana-presentation	yes
vis_type_metric	@elastic/kibana-app	yes
vis_type_table	@elastic/kibana-app	yes
vis_type_tagcloud	@elastic/kibana-app	yes
vis_type_timelion	@elastic/kibana-app	yes
vis_type_timeseries	@elastic/kibana-app	yes
vis_type_vega	@elastic/kibana-app	yes
vis_type_vislib	@elastic/kibana-app	yes
vis_type_pie	@elastic/kibana-app	yes
x-pack/actions	@elastic/kibana-alerting-services	no
x-pack/alerting	@elastic/kibana-alerting-services	no
x-pack/apm	@elastic/apm-ui
x-pack/cases	@elastic/security-threat-hunting
x-pack/cloud	@elastic/kibana-core	no
x-pack/cross_cluster_replication	@elastic/kibana-stack-management	no
x-pack/dashboard_mode	@elastic/kibana-presentation	no
x-pack/encrypted_saved_objects	@elastic/kibana-security	no
x-pack/enterprise_search	@elastic/enterprise-search-frontend	no
x-pack/event_log	@elastic/kibana-alerting-services	no
x-pack/fleet	@elastic/fleet	no
x-pack/graph	@elastic/kibana-app	no
x-pack/grokdebugger	@elastic/kibana-stack-management	no
x-pack/index_lifecycle_management	@elastic/kibana-stack-management	no
x-pack/index_management	@elastic/kibana-stack-management	no
x-pack/infra	@elastic/logs-metrics-ui	no
x-pack/lens	@elastic/kibana-app	no
x-pack/license_management	@elastic/kibana-stack-management	no
x-pack/lists	@elastic/security-detections-response
x-pack/logstash	?
x-pack/maps	@elastic/kibana-gis	no
x-pack/metrics_entities	@elastic/security-detections-response (?)
x-pack/monitoring	@elastic/stack-monitoring-ui	no
x-pack/observability	@elastic/observability-ui	no
x-pack/osquery	@elastic/security-asset-management	no
x-pack/remote_clusters	@elastic/kibana-stack-management	no
x-pack/reporting	@elastic/kibana-app-services	yes
x-pack/rollup	@elastic/kibana-stack-management	no
x-pack/rule_registry	@elastic/security-detections-response (?)	no
x-pack/saved_objects_tagging	@elastic/kibana-core	no
x-pack/security	@elastic/kibana-security	no
x-pack/security_solution	@elastic/security-solution
x-pack/snapshot_restore	@elastic/kibana-stack-management	no
x-pack/spaces	@elastic/kibana-security	no
x-pack/stack_alerts	@elastic/kibana-alerting-services	no
x-pack/task_manager	@elastic/kibana-alerting-services	no
x-pack/timelines	@elastic/security-threat-hunting
x-pack/upgrade_assistant	@elastic/kibana-stack-management	no

[elasticmachine]

Pinging @elastic/kibana-core (Team:Core)

[lukeelmers]

related #66621

[rudolf]

Reducing the amount of permutations (and all the test cases to cover these permutations) is a good idea, we can get a lot of value by doing this for spaces, security, encrypted saved objects etc.

However, I don't believe this should be the default. Every plugin that can't be disabled poses an operational risk for users:

1. Disabling the plugin is often the only way to mitigate a security vulnerability [discuss] Remove the ability to disable plugins in production #66621 (comment)
2. Disabling a plugin is the fastest way to work around a migration bug. If e.g. SIEM's migrations fail because of a bug (or corrupt data) a sysadmin can decide to disable the plugin and proceed with the upgrade because SIEM isn't used or it's not a critical part of their infrastructure. When users upgrade from minors it's relatively easy to do a rollback if a migration fails, but when you upgrade from e.g. 6.x to 7.x you have to upgrade Elasticsearch first meaning you can't rollback without rolling back Elasticsearch and loosing all data that's been written since you started the upgrade.
3. Disabling a plugin allows users to temporarily stop a plugin that's e.g. causing stability problems like excessive load on ES, slow response times from Kibana, a memory leak in Kibana (Constantly memory leaking on x-pack.reporting #90274).
4. (Sync lifecycles probably reduces this risk sufficiently, but I've seen SDH's where we had to disable plugins to allow Kibana to start up because they were blocking on requests which always timedout)

Kibana is a gigantic monolith which comes with all the operational downsides of running a monolith. With Kibana being used increasingly for mission critical work loads these downsides have a bigger impact on users. Being able to enable/disable some plugins mitigates some of these downsides e.g. it's theoretically possible to scale up alerting-only Kibana instances, or only disable alerting if that's causing stability problems for other systems.

So I would prefer if plugins had to opt-out of being disable-able, and I think we should evaluate plugins on a case by case basis to weigh up the benefits/risk.

[joshdover]

Reducing the amount of permutations (and all the test cases to cover these permutations) is a good idea, we can get a lot of value by doing this for spaces, security, encrypted saved objects etc.

However, I don't believe this should be the default. Every plugin that can't be disabled poses an operational risk for users:

If the issue with keeping the ability to disable these items is testing & support, maybe we need to make it more clear that running with disabled plugins is not supported. Yes, it's a workaround that may work for some situations detailed above, however it's not something we test for, and we shouldn't rely on this feature working without breaking other things if we aren't testing for it. IMO, at the very least there should be a warning logged when disabling a plugin that we don't test for.

I also think we can find other, well-tested solutions to most of the problems above that don't involve drastically changing which plugins are executing in production.

The exception being the security vulnerability case, and while I can see how that is a useful defense, is it an explicit part of our security model? Are there other ways we can achieve this based on the patterns we've seen? For instance, if disabling plugins is usually used to disable vulnerable REST endpoints, we could add a feature for disabling some route paths instead.

it's theoretically possible to scale up alerting-only Kibana instances, or only disable alerting if that's causing stability problems for other systems.

I'd prefer we explicitly add features that are well-tested to support dedicated node types over having this feature exist by accident. What good is a feature if it may be breaking between releases?

Overall, I do agree this functionality is needed in some cases, which is why I generally support this proposal over #66621. However, in the cases where we need this, we still need tests & verifications across versions to ensure we don't break configuration. If we agree that there is extra work that should be done for a plugin to be disable-able, then I think the default should reflect that.

[rudolf]

The exception being the security vulnerability case, and while I can see how that is a useful defense, is it an explicit part of our security model?

I suspect we would always fix vulnerabilities in supported releases, so strictly speaking we don't need to provide the ability to disable a plugin to fix a vulnerability, the real fix is to upgrade Kibana. When Kibana ships with 100+ plugins it becomes increasingly likely that some plugin you don't use has a vulnerability and having to upgrade just for that is rather annoying. However, upgrading for security vulnerabilities is definitely the norm in the industry and as long as we make this process as seamless as possible maybe the impact/frustration/cost on users is negligible.

I'd prefer we explicitly add features that are well-tested to support dedicated node types over having this feature exist by accident. What good is a feature if it may be breaking between releases?

I agree, we should rather provide a more stream-lined and better documented way to achieve this.

If we agree that there is extra work that should be done for a plugin to be disable-able, then I think the default should reflect that.

My concern is that most plugins would just opt to stick with the default. I agree there's probably better ways to address the problems I mentioned. But short term this would reduce the amount of options users and support have to fix/stabilize a Kibana deployment.

I agree that in principle this default would reduce the amount of bugs we get from untested permutations. But is this currently a notable problem, I'm not aware of it impacting users. So my bias is towards the SDH's I've been part of where disabling a plugin was a quick win to get a deployment back up and running.

[legrego]

The exception being the security vulnerability case, and while I can see how that is a useful defense, is it an explicit part of our security model?

I don't think it's an explicit part of our security model, but it us a useful mitigation to protect our users. @joshbressers / @douglasday do you have an opinion on this? Do you/our users find it helpful that we can mitigate certain vulnerabilities by disabling plugins, or is this something that just "feels" like a good thing to offer?

Are there other ways we can achieve this based on the patterns we've seen?. For instance, if disabling plugins is usually used to disable vulnerable REST endpoints, we could add a feature for disabling some route paths instead.

I'm all for exploring other options, but I think it needs to include an answer for client-side as well. The reports we get are a mixed bag of front-end and back-end, so disabling REST endpoints (for example) might not help as much as we'd like.

[joshbressers]

I wanted to close this loop (Larry asked me about this in a security team meeting).

I'm comfortable not disabling plugins. We do provide mitigation advice to disable certain functionality for some security vulnerabilities, but I don't suspect this is widely used (I get very few comments on the feedback, I recall in the past there have been some instructions that broke things and we only heard from one or two people).

[joshdover]

@kobelb @stacey-gammon Are we still comfortable moving forward with this?