291 lines
12 KiB
Plaintext
291 lines
12 KiB
Plaintext
[discrete]
|
|
[[breaking_70_settings_changes]]
|
|
=== Settings changes
|
|
|
|
//NOTE: The notable-breaking-changes tagged regions are re-used in the
|
|
//Installation and Upgrade Guide
|
|
|
|
//tag::notable-breaking-changes[]
|
|
|
|
// end::notable-breaking-changes[]
|
|
|
|
[discrete]
|
|
[[default-node-name-now-hostname]]
|
|
==== The default for `node.name` is now the hostname
|
|
|
|
`node.name` now defaults to the hostname at the time when Elasticsearch
|
|
is started. Previously the default node name was the first eight characters
|
|
of the node id. It can still be configured explicitly in `elasticsearch.yml`.
|
|
|
|
[discrete]
|
|
==== Percolator
|
|
|
|
* The deprecated `index.percolator.map_unmapped_fields_as_string` setting has been removed in favour of
|
|
the `index.percolator.map_unmapped_fields_as_text` setting.
|
|
|
|
[discrete]
|
|
==== Index thread pool
|
|
|
|
* Internally, single-document index/delete/update requests are executed as bulk
|
|
requests with a single-document payload. This means that these requests are
|
|
executed on the bulk thread pool. As such, the indexing thread pool is no
|
|
longer needed and has been removed. As such, the settings
|
|
`thread_pool.index.size` and `thread_pool.index.queue_size` have been removed.
|
|
|
|
[discrete]
|
|
[[write-thread-pool-fallback]]
|
|
==== Write thread pool fallback
|
|
|
|
* The bulk thread pool was replaced by the write thread pool in 6.3.0. However,
|
|
for backwards compatibility reasons the name `bulk` was still usable as fallback
|
|
settings `thread_pool.bulk.size` and `thread_pool.bulk.queue_size` for
|
|
`thread_pool.write.size` and `thread_pool.write.queue_size`, respectively, and
|
|
the system property `es.thread_pool.write.use_bulk_as_display_name` was
|
|
available to keep the display output in APIs as `bulk` instead of `write`.
|
|
These fallback settings and this system property have been removed.
|
|
|
|
[discrete]
|
|
==== Disabling memory-mapping
|
|
|
|
* The setting `node.store.allow_mmapfs` has been renamed to `node.store.allow_mmap`.
|
|
|
|
[discrete]
|
|
[[remove-http-enabled]]
|
|
==== Http enabled setting removed
|
|
|
|
* The setting `http.enabled` previously allowed disabling binding to HTTP, only allowing
|
|
use of the transport client. This setting has been removed, as the transport client
|
|
will be removed in the future, thus requiring HTTP to always be enabled.
|
|
|
|
[discrete]
|
|
[[remove-http-pipelining-setting]]
|
|
==== Http pipelining setting removed
|
|
|
|
* The setting `http.pipelining` previously allowed disabling HTTP pipelining support.
|
|
This setting has been removed, as disabling http pipelining support on the server
|
|
provided little value. The setting `http.pipelining.max_events` can still be used to
|
|
limit the number of pipelined requests in-flight.
|
|
|
|
[discrete]
|
|
==== Cross-cluster search settings renamed
|
|
|
|
The cross-cluster search remote cluster connection infrastructure is also used
|
|
in cross-cluster replication. This means that the setting names
|
|
`search.remote.*` used for configuring cross-cluster search belie the fact that
|
|
they also apply to other situations where a connection to a remote cluster as
|
|
used. Therefore, these settings have been renamed from `search.remote.*` to
|
|
`cluster.remote.*`. For backwards compatibility purposes, we will fallback to
|
|
`search.remote.*` if `cluster.remote.*` is not set. For any such settings stored
|
|
in the cluster state, or set on dynamic settings updates, we will automatically
|
|
upgrade the setting from `search.remote.*` to `cluster.remote.*`. The fallback
|
|
settings will be removed in 8.0.0.
|
|
|
|
[discrete]
|
|
[[audit-logfile-local-node-info]]
|
|
==== Audit logfile local node info
|
|
|
|
The following settings have been removed:
|
|
|
|
- `xpack.security.audit.logfile.prefix.emit_node_host_address`, instead use
|
|
`xpack.security.audit.logfile.emit_node_host_address`
|
|
- `xpack.security.audit.logfile.prefix.emit_node_host_name`, instead use
|
|
`xpack.security.audit.logfile.emit_node_host_name`
|
|
- `xpack.security.audit.logfile.prefix.emit_node_name`, instead use
|
|
`xpack.security.audit.logfile.emit_node_name`
|
|
|
|
The new settings have the same meaning as the removed ones, but the `prefix`
|
|
name component is no longer meaningful as logfile audit entries are structured
|
|
JSON documents and are not prefixed by anything.
|
|
Moreover, `xpack.security.audit.logfile.emit_node_name` has changed its default
|
|
from `true` to `false`. All other settings mentioned before, have kept their
|
|
default value of `false`.
|
|
|
|
[discrete]
|
|
[[include-realm-type-in-setting]]
|
|
==== Security realms settings
|
|
|
|
The settings for all security realms must now include the realm type as part
|
|
of the setting name, and the explicit `type` setting has been removed.
|
|
|
|
A realm that was previous configured as:
|
|
[source,yaml]
|
|
--------------------------------------------------
|
|
xpack.security.authc.realms:
|
|
ldap1:
|
|
type: ldap
|
|
order: 1
|
|
url: "ldaps://ldap.example.com/"
|
|
--------------------------------------------------
|
|
|
|
Must be migrated to:
|
|
[source,yaml]
|
|
--------------------------------------------------
|
|
xpack.security.authc.realms:
|
|
ldap.ldap1:
|
|
order: 1
|
|
url: "ldaps://ldap.example.com/"
|
|
--------------------------------------------------
|
|
|
|
Any realm specific secure settings that have been stored in the elasticsearch
|
|
keystore (such as ldap bind passwords, or passwords for ssl keys) must be updated
|
|
in a similar way.
|
|
|
|
[discrete]
|
|
[[tls-setting-fallback]]
|
|
==== TLS/SSL settings
|
|
|
|
The default TLS/SSL settings, which were prefixed by `xpack.ssl`, have been removed.
|
|
The removal of these default settings also removes the ability for a component to
|
|
fallback to a default configuration when using TLS. Each component (realm, transport, http,
|
|
http client, etc) must now be configured with their own settings for TLS if it is being
|
|
used.
|
|
|
|
[discrete]
|
|
[[tls-v1-removed]]
|
|
==== TLS v1.0 disabled
|
|
|
|
TLS version 1.0 is now disabled by default as it suffers from
|
|
https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet#Rule_-_Only_Support_Strong_Protocols[known security issues].
|
|
The default protocols are now TLSv1.3 (if supported), TLSv1.2 and TLSv1.1.
|
|
|
|
You can enable TLS v1.0 by configuring the relevant `ssl.supported_protocols`
|
|
setting to include `"TLSv1"`.
|
|
Depending on your local configuration and the TLS protocols that are in use
|
|
on your network, you may need to enable TLS v1.0 support in any or all of the
|
|
following places:
|
|
|
|
`xpack.security.http.ssl.supported_protocols`::
|
|
For incoming HTTP connections to Elasticsearch's HTTP (Rest) interface.
|
|
If there are clients that connect to {es} and do not support newer TLS versions,
|
|
you must update this setting.
|
|
|
|
`xpack.http.ssl.supported_protocols`::
|
|
For outgoing HTTP connections from {watcher}.
|
|
If you have watches that connect to external HTTP servers and do not support
|
|
newer TLS versions, you must update this setting.
|
|
|
|
`xpack.security.authc.realms.ldap.{name}.ssl.supported_protocols`::
|
|
For outgoing LDAP connections from {es} {security-features}.
|
|
If you have an LDAP realm enabled and the LDAP directory to which that realm
|
|
connects does not support newer TLS versions, you must update this setting.
|
|
|
|
`xpack.security.authc.realms.active_directory.{name}.ssl.supported_protocols`::
|
|
For outgoing Active Directory (LDAP) connections from {es} {security-features}.
|
|
If you have an AD realm enabled and the directory server to which that realm
|
|
connects does not support newer TLS versions, you must update this setting.
|
|
|
|
`xpack.security.authc.realms.saml.{name}.ssl.supported_protocols`::
|
|
For outgoing HTTP connections to retrieve SAML metadata.
|
|
If you have a SAML realm enabled and the realm is configured to retrieve
|
|
metadata over HTTPS (that is, `idp.metadata.path` is a URL starting with
|
|
`https://`) and the web server which hosts the metadata does not support newer
|
|
TLS versions, you must update this setting.
|
|
|
|
`xpack.security.authc.realms.oidc.{name}.ssl.supported_protocols`::
|
|
For outgoing HTTP connections to an OpenId Connect Provider.
|
|
If you have an OpenId Connect ("oidc") realm enabled and the realm is configured
|
|
to connect to a remote OpenID Connect Provider which does not support newer TLS
|
|
versions, you must update this setting.
|
|
|
|
`xpack.monitoring.exporters.{name}.ssl.supported_protocols`::
|
|
For remote monitoring data.
|
|
If your monitoring data is exported to a remote monitoring cluster and that
|
|
cluster is configured to only support TLSv1, you must update this setting.
|
|
|
|
`reindex.ssl.supported_protocols`::
|
|
For reindex from remote.
|
|
If you reindex data from a remote {es} cluster which has SSL enabled on the
|
|
`http` interface and that cluster is configured to only support TLSv1, you must
|
|
update this setting.
|
|
|
|
`xpack.security.transport.ssl.supported_protocols`::
|
|
For incoming connections between {es} nodes. If you have specialized network
|
|
equipment which inspects TLS packets between your nodes, and that equipment
|
|
enforces TLSv1 you must update this setting.
|
|
|
|
|
|
The following is an example that enables TLS v1.0 for incoming HTTP connections:
|
|
[source,yaml]
|
|
--------------------------------------------------
|
|
xpack.security.http.ssl.supported_protocols: [ "TLSv1.3", "TLSv1.2", "TLSv1.1", "TLSv1" ]
|
|
--------------------------------------------------
|
|
|
|
[discrete]
|
|
[[trial-explicit-security]]
|
|
==== Security on Trial Licenses
|
|
|
|
On trial licenses, `xpack.security.enabled` defaults to `false`.
|
|
|
|
In prior versions, a trial license would automatically enable security if either
|
|
|
|
* `xpack.security.transport.enabled` was `true`; _or_
|
|
* the trial license was generated on a version of X-Pack from 6.2 or earlier.
|
|
|
|
This behaviour has been now removed, so security is only enabled if:
|
|
|
|
* `xpack.security.enabled` is `true`; _or_
|
|
* `xpack.security.enabled` is not set, and a gold or platinum license is installed.
|
|
|
|
[discrete]
|
|
[[watcher-notifications-account-settings]]
|
|
==== Watcher notifications account settings
|
|
|
|
The following settings have been removed in favor of the secure variants.
|
|
The <<secure-settings, secure settings>> have to be defined inside each cluster
|
|
node's keystore, i.e., they are not to be specified via the cluster settings API.
|
|
|
|
- `xpack.notification.email.account.<id>.smtp.password`, instead use
|
|
`xpack.notification.email.account.<id>.smtp.secure_password`
|
|
- `xpack.notification.hipchat.account.<id>.auth_token`, instead use
|
|
`xpack.notification.hipchat.account.<id>.secure_auth_token`
|
|
- `xpack.notification.jira.account.<id>.url`, instead use
|
|
`xpack.notification.jira.account.<id>.secure_url`
|
|
- `xpack.notification.jira.account.<id>.user`, instead use
|
|
`xpack.notification.jira.account.<id>.secure_user`
|
|
- `xpack.notification.jira.account.<id>.password`, instead use
|
|
`xpack.notification.jira.account.<id>.secure_password`
|
|
- `xpack.notification.pagerduty.account.<id>.service_api_key`, instead use
|
|
`xpack.notification.pagerduty.account.<id>.secure_service_api_key`
|
|
- `xpack.notification.slack.account.<id>.url`, instead use
|
|
`xpack.notification.slack.account.<id>.secure_url`
|
|
|
|
[discrete]
|
|
[[remove-audit-index-output]]
|
|
==== Audit index output type removed
|
|
|
|
All the settings under the `xpack.security.audit.index` namespace have been
|
|
removed. In addition, the `xpack.security.audit.outputs` setting has been
|
|
removed as well.
|
|
|
|
These settings enabled and configured the audit index output type. This output
|
|
type has been removed because it was unreliable in certain scenarios and this
|
|
could have lead to dropping audit events while the operations on the system
|
|
were allowed to continue as usual. The recommended replacement is the
|
|
use of the `logfile` audit output type and using other components from the
|
|
Elastic Stack to handle the indexing part.
|
|
|
|
[discrete]
|
|
[[ingest-user-agent-ecs-always]]
|
|
==== Ingest User Agent processor defaults uses `ecs` output format
|
|
https://github.com/elastic/ecs[ECS] format is now the default.
|
|
The `ecs` setting for the user agent ingest processor now defaults to true.
|
|
|
|
[discrete]
|
|
[[remove-action-master-force_local]]
|
|
==== Remove `action.master.force_local`
|
|
|
|
The `action.master.force_local` setting was an undocumented setting, used
|
|
internally by the tribe node to force reads to local cluster state (instead of
|
|
forwarding to a master, which tribe nodes did not have). Since the tribe
|
|
node was removed, this setting was removed too.
|
|
|
|
[discrete]
|
|
==== Enforce cluster-wide shard limit
|
|
The cluster-wide shard limit is now enforced and not optional. The limit can
|
|
still be adjusted as desired using the cluster settings API.
|
|
|
|
[discrete]
|
|
==== HTTP Max content length setting is no longer parsed leniently
|
|
Previously, `http.max_content_length` would reset to `100mb` if the setting was
|
|
greater than `Integer.MAX_VALUE`. This leniency has been removed.
|