0e00c3ffef
* Remove mode.initialize and change useRbacForRequest to useRbac * Updating saved object api tests * Fixing spaces api integration tests * Removing unused "expect legacy forbidden" declarations and imports * Updating docs * Update docs/migration/migrate_7_0.asciidoc Co-Authored-By: kobelb <brandon.kobel@gmail.com> * Update docs/migration/migrate_7_0.asciidoc Co-Authored-By: kobelb <brandon.kobel@gmail.com> * Updating comment that mentions the scenario when we aren't using RBAC * Adding back the authorization section of the config When a config setting is marked as unused using the deprecations, it's still required to show up in the config declarations so an error isn't thrown on startup. * Adding note about watcher jobs * Update docs/migration/migrate_7_0.asciidoc Co-Authored-By: kobelb <brandon.kobel@gmail.com>
126 lines
7 KiB
Plaintext
126 lines
7 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]
|
|
=== 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 `elasticsearch.url` sets port based on protocol
|
|
*Details:* In prior versions of Kibana, if no port was specified in `elasticsearch.url` a default of 9200 was chosen.
|
|
The port is now protocol dependent: https ports will use 443, and http ports will use 80.
|
|
|
|
*Impact:* If your `elasticsearch.url` was dependent on an unspecified port set to 9200, `:9200` will have to be appended to the url.
|
|
|
|
[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.
|