Kibana's system indices

[kobelb]

Legacy multi-tenancy

Kibana currently supports "legacy multi-tenancy" by allowing users to configure the Elasticsearch indices that should be used to persist Kibana specific entities. It's rather common to hear developers refer to the ".kibana" index, but this is rather imprecise as there are a number of dot-indices that are used, not just ".kibana":

name	kibana.yml setting	default indices	default alias	category
saved-objects	kibana.index	.kibana_${integer}	.kibana	system
reporting	xpack.reporting.index	.reporting-${date}	N/A	system
task manager	xpack.task_manager.index	.kibana_task_manager_${integer}	.kibana_task_manager	system
security session	derived from kibana.index	.kibana_security_session_${integer}	N/A	system
event log	derived from kibana.index	.kibana-event-log-${version}-${integer}	.kibana-event-log-${version}	hidden

There are also some indices that Kibana reads from and writes to, but they aren't configurable in the kibana.yml, so they aren't changed when users are implementing legacy multi-tenancy.

name	default indices	default alias	category
APM agent configuration	.apm-agent-configuration	N/A	system
APM custom link	.apm-custom-link	N/A	system
monitoring	.monitoring-*		hidden
beats central management	.management-beats		deprecated

Starting in 8.0, this method of multi-tenancy will no longer be supported. Users will no longer be able to specify their kibana.index, xpack.reporting.index and xpack.task_manager.index settings in their kibana.yml. For more details, please see #82020

Upgrade Paths

According to our documentation, the following upgrade paths are supported with a rolling upgrade:

• Between minor versions
• From 6.last to 7.x
• From 7.last to 8.x

And the following upgrade paths are supported with a full cluster restart:

• From 6.not-last to 7.x
• From 7.not-last to 8.x

When upgrading Kibana, users are instructed to first upgrade Elasticsearch and then shut down all instances of Kibana prior to starting up a new version.

Kibana's system-index patterns

Per elastic/elasticsearch#67383, Kibana's system-indices will be considered "unmanaged system indices". This allows Kibana to be fully responsible and in control of creating its own system-indices and their mappings. Additionally, Kibana can continue accessing these indices using the standard ES APIs while specifying a special HTTP request header and value pair. It's my understanding that the ES implementation will require the 'x-elastic-product-origin': 'kibana' header to be specified to denote these requests as originating from Kibana.

The following patterns will be registered as Kibana's system-indices. As such, end-users will be unable to access them using the standard ES document APIs starting in 8.0. If end-users access them during 7.x, a deprecation will be logged.

• .kibana_*
• .reporting-*
• .apm-*

7.x

During 7.x, since users will still be able to specify kibana.index, xpack.reporting.index and xpack.task_manager.index settings in their kibana.yml. All HTTP requests made from Kibana to Elasticsearch that access Kibana's system-indices will include the 'x-elastic-product-origin': 'kibana' header.

Users have historically had full control over the HTTP request headers that Kibana sends to Elasticsearch using the elasticsearch.customHeaders and elasticsearch.requestHeadersWhitelist settings. As a result, users can potentially override the x-elastic-product-origin header. This is rather unlikely; however, if users do happen to do so, Elasticsearch will log a deprecation warning about Kibana's system-indices being accessed incorrectly.

8.0

Users will no longer be able to specify kibana.index, xpack.reporting.index or xpack.task_manager.index in the kibana.yml. Additionally, they will no longer be able to specify the x-elastic-product-origin header in both elasticsearch.customHeaders and elasticsearch.requestHeadersWhitelist. If they do, they won't be able to start Kibana. Users will be instructed as part of the 8.0 major upgrade assistant to migrate to using Spaces or CCS for multi-tenancy.

Implementation

• No longer allow the x-elastic-product-origin header to be configurable No longer allow the x-elastic-product-origin header to be configurable #89803
• ESArchiver should specify 'x-elastic-product-origin': 'kibana' when accessing Kibana's system-indices ESArchiver should specify 'x-elastic-product-origin': 'kibana' when accessing Kibana's system-indices #89805
• Reporting system-index retention policy Reporting ILM policy #81544
• Explicitly delete all Kibana security session Explicitly delete all Kibana security sessions #81941

Required changes

• Exclude the x-elastic-product-origin for the dev console [console] exclude the x-elastic-product-origin header for requests performed from the dev console #90123

[kobelb]

@jaymode is going to be investigating whether or not we have other options besides wrapping the existing APIs under a new endpoint in ES, so we should hold off on implementing the approach outlined in this issue for the time being.

/cc @elastic/kibana-core

[kobelb]

This issue has been updated to reflect that Kibana's system-indices will now be external unmanaged system-indices.

[kobelb]

Closing this issue, as all of the work to move Kibana to system indices has been completed.

[kobelb]

Reopening this issue because the system indices protection haven't been implemented in Elasticsearch yet. The Kibana development work is theoretically complete; however, we won't be sure it is until the enforcements are done. Thanks for bringing this up @jaymode