* csp: warn legacy browsers that do not support CSP The new csp.warnLegacyBrowsers configuration is enabled by default, and it shows a warning message to any legacy browser when they access Kibana to indicate that they are not enforcing the basic security protections of the current install. The protections check is the same as csp.strict, so this feature is designed to be used as an alternative to aid in BWC. When csp.strict is enabled, warnLegacyBrowsers is effectively ignored. * fix ChromeService tests * more test fixes * csp injectvars in legacy test bundle * update warning text and make it translatable * no need to warn in legacy browser unit tests * tests for chrome legacy browser warning * document legacy browser warning breaking change * update csp warning toast message * add period, remove dev code
209 lines
12 KiB
Plaintext
209 lines
12 KiB
Plaintext
[[breaking-changes-7.0]]
|
|
== Breaking changes in 7.0
|
|
++++
|
|
<titleabbrev>7.0</titleabbrev>
|
|
++++
|
|
|
|
This section discusses the changes that you need to be aware of when migrating
|
|
your application to Kibana 7.0.
|
|
|
|
See also <<release-highlights>> and <<release-notes>>.
|
|
|
|
[float]
|
|
=== Removed support for users relying on direct index privileges to the Kibana index in Elasticsearch
|
|
*Details:* With the introduction of Kibana RBAC in 6.4, users no longer require privileges to the Kibana index in Elasticsearch. Instead, users
|
|
should be granted <<kibana-privileges>>. Prior to 7.0, when a user that relies upon direct index privileges logs into Kibana, a deprecation warning is logged. If you are using the `kibana_user` or `kibana_dashboard_only_user` role to grant access to Kibana, or a custom role using <<kibana-privileges>>, no changes are required.
|
|
|
|
*Impact:* You must change any roles which grant access to Kibana using index privileges to instead use <<kibana-privileges>>. Watcher jobs using the Reporting attachment type must be updated as well.
|
|
|
|
[float]
|
|
=== Removed support for tribe nodes
|
|
*Details:* Elasticsearch 7.0 removes the tribe node feature, so Kibana removes it as well.
|
|
|
|
*Impact:* You must remove any tribe node configurations in Kibana. Consider using <<management-cross-cluster-search>> instead, which does not require kibana.yml configurations in Kibana.
|
|
|
|
|
|
[float]
|
|
=== Removed support for running Kibana with a global Node.js installation
|
|
*Details:* Previous versions of Kibana would fallback to using a global installation of Node.js if the distribution included with Kibana was not found.
|
|
Kibana 7.0 will only use the Node.js distribution included in the package.
|
|
|
|
*Impact:* There is no expected impact unless Kibana is installed in a non-standard way.
|
|
|
|
[float]
|
|
=== Removed support for using PhantomJS browser for screenshots in Reporting
|
|
*Details:* Since the first release of Kibana Reporting, PhantomJS was used as
|
|
the headless browser to capture screenshots of Kibana dashboards and
|
|
visualizations. In that short time, Chromium has started offering a new
|
|
headless browser library and the PhantomJS maintainers abandoned their project.
|
|
We started planning for a transition in 6.5.0, when we made Chromium the
|
|
default option, but allowed users to continue using Phantom with the
|
|
`xpack.reporting.capture.browser.type: phantom` setting. In 7.0, that setting
|
|
will still exist for compatibility, but the only valid option will be
|
|
`chromium`.
|
|
|
|
*Impact:* Before upgrading to 7.0, if you have `xpack.reporting.capture.browser.type`
|
|
set in kibana.yml, make sure it is set to `chromium`.
|
|
|
|
[NOTE]
|
|
============
|
|
Reporting 7.0 uses a version of the Chromium headless browser that RHEL 6,
|
|
CentOS 6.x, and other old versions of Linux derived from RHEL 6. This change
|
|
effectively removes RHEL 6 OS server support from Kibana Reporting. Users with
|
|
RHEL 6 must upgrade to RHEL 7 to use Kibana Reporting starting with version
|
|
7.0.0 of the Elastic stack.
|
|
============
|
|
|
|
[float]
|
|
=== Advanced setting query:queryString:options no longer applies to filters
|
|
*Details:* In previous versions of Kibana the Advanced Setting `query:queryString:options` was applied to both queries
|
|
and custom filters using the `query_string` query. This could cause errors if a custom filter used options that
|
|
conflicted with the Advanced Setting. In 7.0 `query:queryString:options` will no longer be applied to filters so that
|
|
users can have full control over their custom filters.
|
|
|
|
*Impact:* You must ensure that any saved searches with a `query_string` filter aren't relying implicitly on
|
|
`query:queryString:options`.
|
|
|
|
[float]
|
|
=== Advanced setting query:queryString:options no longer applies `default_field: *` by default.
|
|
*Details:* Elasticsearch removed the ability to create indices with an _all field in 6.0. As a result, a user could end
|
|
up with a mix of indices with and without _all fields if they upgraded from an older version of ES. This could lead to
|
|
inconsistent highlighting in Discover. To work around this issue we added `default_field: *` to query:queryString:options
|
|
to force consistent querying across indices with and without _all. In 7.0 the _all field will be gone from all indices
|
|
so we no longer need this workaround.
|
|
|
|
*Impact:* Since we'll no longer send the `default_field` parameter in Kibana's query_string query, Elasticsearch
|
|
will use the index setting instead. The default for the index setting is also `*`, so most users should not be impacted.
|
|
If some of your indices have a non-default `default_field` setting, you may want to update it or re-add the parameter
|
|
to Kibana's advanced setting.
|
|
|
|
[float]
|
|
=== Deprecated kibana.yml setting `xpack.monitoring.node_resolver` has been removed
|
|
*Details:* This setting has been deprecated since 5.6, when it was explicitly recommended to use `uuid` as its value.
|
|
|
|
*Impact:* This setting is no longer necessary. If you enable {monitoring} across the Elastic Stack, a monitoring agent runs
|
|
on each Elasticsearch node, Logstash node, Kibana instance, and Beat to collect and index metrics. Each node and instance is
|
|
considered unique based on its persistent UUID, which is written to the path.data directory when the node or instance starts.
|
|
|
|
[float]
|
|
=== kibana.yml setting `xpack.monitoring.elasticsearch.url` is no longer valid
|
|
*Details:* This deprecated setting has been removed and `xpack.monitoring.elasticsearch.hosts` should be used instead.
|
|
In prior versions of Kibana, if no port was specified in `xpack.monitoring.elasticsearch.url` a default of 9200 was chosen.
|
|
The port in `xpack.monitoring.elasticsearch.hosts` is protocol dependent: https ports will use 443, and http ports will use 80.
|
|
|
|
*Impact:* Users with `xpack.monitoring.elasticsearch.url` set should use `xpack.monitoring.elasticsearch.hosts` instead and if
|
|
`xpack.monitoring.elasticsearch.url` was dependent on an unspecified port set to 9200, `:9200` will have to be appended to the url.
|
|
|
|
[float]
|
|
=== kibana.yml setting `xpack.monitoring.elasticsearch.ssl.cert` is no longer valid
|
|
*Details:* This deprecated setting has been removed and `xpack.monitoring.elasticsearch.ssl.certificate` should be used instead.
|
|
|
|
*Impact:* Users with `xpack.monitoring.elasticsearch.ssl.cert` set should use `xpack.monitoring.elasticsearch.ssl.certificate` instead
|
|
|
|
[float]
|
|
=== kibana.yml setting `xpack.monitoring.elasticsearch.ssl.ca` is no longer valid
|
|
*Details:* This deprecated setting has been removed and `xpack.monitoring.elasticsearch.ssl.certificateAuthorities` should be used instead.
|
|
|
|
*Impact:* Users with `xpack.monitoring.elasticsearch.ssl.ca` set should use `xpack.monitoring.elasticsearch.ssl.certificateAuthorities` instead
|
|
|
|
[float]
|
|
=== kibana.yml setting `xpack.monitoring.elasticsearch.ssl.verify` is no longer valid
|
|
*Details:* This deprecated setting has been removed and `xpack.monitoring.elasticsearch.ssl.verificationMode` should be used instead.
|
|
|
|
*Impact:* Users with `xpack.monitoring.elasticsearch.ssl.verify` set should use `xpack.monitoring.elasticsearch.ssl.verificationMode` instead.
|
|
Previously set `xpack.monitoring.elasticsearch.ssl.verify` is equal to `xpack.monitoring.elasticsearch.ssl.verificationMode: full`.
|
|
|
|
[float]
|
|
=== Deprecated API `/shorten` has been removed
|
|
*Details:* The `/shorten` API has been deprecated since 6.5, when it was replaced by the `/api/shorten_url` API.
|
|
|
|
*Impact:* The '/shorten' API has been removed. Use the '/api/shorten_url' API instead.
|
|
|
|
[float]
|
|
=== Deprecated kibana.yml setting logging.useUTC has been replaced with logging.timezone
|
|
*Details:* Any timezone can now be specified by canonical id.
|
|
|
|
*Impact:* The logging.useUTC flag will have to be replaced with a timezone id. If set to true the id is `UTC`.
|
|
|
|
[float]
|
|
=== kibana.yml setting `server.ssl.supportedProtocols` excludes TLSv1 by default
|
|
*Details:* TLSv1 support has been removed by default, it's still possible to opt-in to TLSv1 support by explicitly setting
|
|
`server.ssl.supportedProtocols`
|
|
|
|
*Impact:* Users relying upon TLSv1 will be unable to use Kibana unless `server.ssl.supportedProtocols` is explicitly set.
|
|
|
|
[float]
|
|
=== kibana.yml setting `server.ssl.cert` is no longer valid
|
|
*Details:* This deprecated setting has been removed and `server.ssl.certificate` should be used instead.
|
|
|
|
*Impact:* Users with `server.ssl.cert` set should use `server.ssl.certificate` instead
|
|
|
|
[float]
|
|
=== kibana.yml `server.ssl.enabled` must be set to `true` to enable SSL
|
|
*Details:* Previously, if `server.ssl.certificate` and `server.ssl.key` were set, SSL would automatically be enabled.
|
|
It's now required that the user sets `server.ssl.enabled` to true for this to occur.
|
|
|
|
*Impact:* Users with both `server.ssl.certificate` and `server.ssl.key` set must now also set `server.ssl.enabled` to enable SSL.
|
|
|
|
[float]
|
|
=== Deprecated kibana.yml setting `regionmap` has been replaced with `map.regionmap`
|
|
*Details:* This deprecated setting has been removed and `map.regionmap` should be used instead.
|
|
|
|
*Impact:* Users with `regionmap` set should use `map.regionmap` instead.
|
|
|
|
[float]
|
|
=== Deprecated kibana.yml setting `tilemap` has been replaced with `map.tilemap`
|
|
*Details:* This deprecated setting has been removed and `map.tilemap` should be used instead.
|
|
|
|
*Impact:* Users with `tilemap` set should use `map.tilemap` instead.
|
|
|
|
|
|
[float]
|
|
=== Optimization step deferred until server start
|
|
*Details:* Prior versions of Kibana would run the optimization step after each plugin installation. This is now run on server start when necessary.
|
|
|
|
*Impact:* Users can trigger a standalone optimization after all plugins have been installed with `bin/kibana --optimize` or let the server manage it on startup.
|
|
|
|
[float]
|
|
=== kibana.yml setting `i18n.defaultLocale` is no longer valid
|
|
*Details:* This deprecated setting has been removed and `i18n.locale` should be used instead.
|
|
|
|
*Impact:* Users with `i18n.defaultLocale` set should use `i18n.locale` instead
|
|
|
|
[float]
|
|
=== kibana.yml setting `elasticsearch.url` is no longer valid
|
|
*Details:* This deprecated setting has been removed and `elasticsearch.hosts` should be used instead.
|
|
In prior versions of Kibana, if no port was specified in `elasticsearch.url` a default of 9200 was chosen. The port in
|
|
`elasticsearch.hosts` is protocol dependent: https ports will use 443, and http ports will use 80.
|
|
|
|
*Impact:* Users with `elasticsearch.url` set should use `elasticsearch.hosts` instead and if `elasticsearch.url` was
|
|
dependent on an unspecified port set to 9200, `:9200` will have to be appended to the url.
|
|
|
|
[float]
|
|
=== kibana.yml setting `elasticsearch.ssl.cert` is no longer valid
|
|
*Details:* This deprecated setting has been removed and `elasticsearch.ssl.certificate` should be used instead.
|
|
|
|
*Impact:* Users with `elasticsearch.ssl.cert` set should use `elasticsearch.ssl.certificate` instead
|
|
|
|
[float]
|
|
=== kibana.yml setting `elasticsearch.ssl.ca` is no longer valid
|
|
*Details:* This deprecated setting has been removed and `elasticsearch.ssl.certificateAuthorities` should be used instead.
|
|
|
|
*Impact:* Users with `elasticsearch.ssl.ca` set should use `elasticsearch.ssl.certificateAuthorities` instead
|
|
|
|
[float]
|
|
=== kibana.yml setting `elasticsearch.ssl.verify` is no longer valid
|
|
*Details:* This deprecated setting has been removed and `elasticsearch.ssl.verificationMode` should be used instead.
|
|
|
|
*Impact:* Users with `elasticsearch.ssl.verify` set should use `elasticsearch.ssl.verificationMode` instead.
|
|
Previously set `elasticsearch.ssl.verify` is equal to `elasticsearch.ssl.verificationMode: full`.
|
|
|
|
[float]
|
|
=== Legacy browsers (namely IE11) will see a security warning message whenever they load Kibana
|
|
*Details:* Kibana now has a Content Security Policy, but it's only effective if browsers enforce it, and since older
|
|
browsers like Internet Explorer 11 do not support CSP, we show them a warning message whenever they load Kibana.
|
|
|
|
*Impact:* Nothing needs to be done necessarily, but if you don't need to support legacy browsers like IE11, we recommend
|
|
that you set `csp.strict: true` in your kibana.yml to block access to those browsers entirely. If your organization requires
|
|
users to use IE11, you might like to disable the warning entirely with `csp.warnLegacyBrowsers: false` in your kibana.yml.
|