[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.
