honeymoose
/
OpenSearch
mirror of https://github.com/honeymoose/OpenSearch.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
OpenSearch/docs/reference/migration/migrate_7_0/settings.asciidoc

291 lines
12 KiB
Plaintext
Raw Normal View History

[DOCS] Swap `[float]` for `[discrete]` (#60134) Changes instances of `[float]` in our docs for `[discrete]`. Asciidoctor prefers the `[discrete]` tag for floating headings: https://asciidoctor.org/docs/asciidoc-asciidoctor-diffs/#blocks
2020-07-23 12:42:33 -04:00
[discrete]
percolator: remove deprecated map_unmapped_fields_as_string setting
2018-01-03 06:16:42 -05:00
[[breaking_70_settings_changes]]
=== Settings changes
[DOCS] Add notable-breaking-changes tags (#40991)
2019-04-08 21:54:29 -04:00
//NOTE: The notable-breaking-changes tagged regions are re-used in the
//Installation and Upgrade Guide
//tag::notable-breaking-changes[]
// end::notable-breaking-changes[]
[DOCS] Swap `[float]` for `[discrete]` (#60134) Changes instances of `[float]` in our docs for `[discrete]`. Asciidoctor prefers the `[discrete]` tag for floating headings: https://asciidoctor.org/docs/asciidoc-asciidoctor-diffs/#blocks
2020-07-23 12:42:33 -04:00
[discrete]
[DOCS] Set literal anchors for Asciidoctor (#42462)
2019-05-28 14:16:18 -04:00
[[default-node-name-now-hostname]]
Core: Default node.name to the hostname (#33677) Changes the default of the `node.name` setting to the hostname of the machine on which Elasticsearch is running. Previously it was the first 8 characters of the node id. This had the advantage of producing a unique name even when the node name isn't configured but the disadvantage of being unrecognizable and not being available until fairly late in the startup process. Of particular interest is that it isn't available until after logging is configured. This forces us to use a volatile read whenever we add the node name to the log. Using the hostname is available immediately on startup and is generally recognizable but has the disadvantage of not being unique when run on machines that don't set their hostname or when multiple elasticsearch processes are run on the same host. I believe that, taken together, it is better to default to the hostname. 1. Running multiple copies of Elasticsearch on the same node is a fairly advanced feature. We do it all the as part of the elasticsearch build for testing but we make sure to set the node name then. 2. That the node.name defaults to some flavor of "localhost" on an unconfigured box feels like it isn't going to come up too much in production. I expect most production deployments to at least set the hostname. As a bonus, production deployments need no longer set the node name in most cases. At least in my experience most folks set it to the hostname anyway.
2018-09-19 15:21:29 -04:00
==== 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`.
[DOCS] Swap `[float]` for `[discrete]` (#60134) Changes instances of `[float]` in our docs for `[discrete]`. Asciidoctor prefers the `[discrete]` tag for floating headings: https://asciidoctor.org/docs/asciidoc-asciidoctor-diffs/#blocks
2020-07-23 12:42:33 -04:00
[discrete]
percolator: remove deprecated map_unmapped_fields_as_string setting
2018-01-03 06:16:42 -05:00
==== Percolator
* The deprecated `index.percolator.map_unmapped_fields_as_string` setting has been removed in favour of
Remove the index thread pool (#29556) Now that single-document indexing requests are executed on the bulk thread pool the index thread pool is no longer needed. This commit removes this thread pool from Elasticsearch.
2018-04-18 09:18:08 -04:00
the `index.percolator.map_unmapped_fields_as_text` setting.
[DOCS] Swap `[float]` for `[discrete]` (#60134) Changes instances of `[float]` in our docs for `[discrete]`. Asciidoctor prefers the `[discrete]` tag for floating headings: https://asciidoctor.org/docs/asciidoc-asciidoctor-diffs/#blocks
2020-07-23 12:42:33 -04:00
[discrete]
Remove the index thread pool (#29556) Now that single-document indexing requests are executed on the bulk thread pool the index thread pool is no longer needed. This commit removes this thread pool from Elasticsearch.
2018-04-18 09:18:08 -04:00
==== 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
Remove bulk fallback for write thread pool (#29609) The name of the bulk thread pool was renamed to "write" with "bulk" as a fallback name. This change was made in 6.x for BWC reasons yet in 7.0.0 we are removing this fallback. This commit removes this fallback for the write thread pool.
2018-04-19 16:59:58 -04:00
`thread_pool.index.size` and `thread_pool.index.queue_size` have been removed.
[DOCS] Swap `[float]` for `[discrete]` (#60134) Changes instances of `[float]` in our docs for `[discrete]`. Asciidoctor prefers the `[discrete]` tag for floating headings: https://asciidoctor.org/docs/asciidoc-asciidoctor-diffs/#blocks
2020-07-23 12:42:33 -04:00
[discrete]
Remove bulk fallback for write thread pool (#29609) The name of the bulk thread pool was renamed to "write" with "bulk" as a fallback name. This change was made in 6.x for BWC reasons yet in 7.0.0 we are removing this fallback. This commit removes this fallback for the write thread pool.
2018-04-19 16:59:58 -04:00
[[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.
Network: Remove http.enabled setting (#29601) This commit removes the http.enabled setting. While all real nodes (started with bin/elasticsearch) will always have an http binding, there are many tests that rely on the quickness of not actually needing to bind to 2 ports. For this case, the MockHttpTransport.TestPlugin provides a dummy http transport implementation which is used by default in ESIntegTestCase. closes #12792
2018-05-02 14:42:05 -04:00
[DOCS] Swap `[float]` for `[discrete]` (#60134) Changes instances of `[float]` in our docs for `[discrete]`. Asciidoctor prefers the `[discrete]` tag for floating headings: https://asciidoctor.org/docs/asciidoc-asciidoctor-diffs/#blocks
2020-07-23 12:42:33 -04:00
[discrete]
Rename setting to enable mmap With this commit we rename `node.store.allow_mmapfs` to `node.store.allow_mmap`. Previously this setting has controlled whether `mmapfs` could be used as a store type. With the introduction of `hybridfs` which also relies on memory-mapping, `node.store.allow_mmapfs` also applies to `hybridfs` and thus we rename it in order to convey that it is actually used to allow memory-mapping but not a specific store type. Relates #36668 Relates #37070
2019-01-03 01:10:34 -05:00
==== Disabling memory-mapping
* The setting `node.store.allow_mmapfs` has been renamed to `node.store.allow_mmap`.
[DOCS] Swap `[float]` for `[discrete]` (#60134) Changes instances of `[float]` in our docs for `[discrete]`. Asciidoctor prefers the `[discrete]` tag for floating headings: https://asciidoctor.org/docs/asciidoc-asciidoctor-diffs/#blocks
2020-07-23 12:42:33 -04:00
[discrete]
Network: Remove http.enabled setting (#29601) This commit removes the http.enabled setting. While all real nodes (started with bin/elasticsearch) will always have an http binding, there are many tests that rely on the quickness of not actually needing to bind to 2 ports. For this case, the MockHttpTransport.TestPlugin provides a dummy http transport implementation which is used by default in ESIntegTestCase. closes #12792
2018-05-02 14:42:05 -04:00
[[remove-http-enabled]]
==== Http enabled setting removed
Make http pipelining support mandatory (#30695) This is related to #29500 and #28898. This commit removes the abilitiy to disable http pipelining. After this commit, any elasticsearch node will support pipelined requests from a client. Additionally, it extracts some of the http pipelining work to the server module. This extracted work is used to implement pipelining for the nio plugin.
2018-05-22 11:29:31 -04:00
* The setting `http.enabled` previously allowed disabling binding to HTTP, only allowing
Network: Remove http.enabled setting (#29601) This commit removes the http.enabled setting. While all real nodes (started with bin/elasticsearch) will always have an http binding, there are many tests that rely on the quickness of not actually needing to bind to 2 ports. For this case, the MockHttpTransport.TestPlugin provides a dummy http transport implementation which is used by default in ESIntegTestCase. closes #12792
2018-05-02 14:42:05 -04:00
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.
Make http pipelining support mandatory (#30695) This is related to #29500 and #28898. This commit removes the abilitiy to disable http pipelining. After this commit, any elasticsearch node will support pipelined requests from a client. Additionally, it extracts some of the http pipelining work to the server module. This extracted work is used to implement pipelining for the nio plugin.
2018-05-22 11:29:31 -04:00
[DOCS] Swap `[float]` for `[discrete]` (#60134) Changes instances of `[float]` in our docs for `[discrete]`. Asciidoctor prefers the `[discrete]` tag for floating headings: https://asciidoctor.org/docs/asciidoc-asciidoctor-diffs/#blocks
2020-07-23 12:42:33 -04:00
[discrete]
Make http pipelining support mandatory (#30695) This is related to #29500 and #28898. This commit removes the abilitiy to disable http pipelining. After this commit, any elasticsearch node will support pipelined requests from a client. Additionally, it extracts some of the http pipelining work to the server module. This extracted work is used to implement pipelining for the nio plugin.
2018-05-22 11:29:31 -04:00
[[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.
Add migration note for remote cluster settings (#33632) The remote cluster settings search.remote.* have been renamed to cluster.remote.* and are automatically upgraded in the cluster state on gateway recovery, and on put. This commit adds a note to the migration docs for these changes.
2018-09-12 13:37:11 -04:00
[DOCS] Swap `[float]` for `[discrete]` (#60134) Changes instances of `[float]` in our docs for `[discrete]`. Asciidoctor prefers the `[discrete]` tag for floating headings: https://asciidoctor.org/docs/asciidoc-asciidoctor-diffs/#blocks
2020-07-23 12:42:33 -04:00
[discrete]
Add migration note for remote cluster settings (#33632) The remote cluster settings search.remote.* have been renamed to cluster.remote.* and are automatically upgraded in the cluster state on gateway recovery, and on put. This commit adds a note to the migration docs for these changes.
2018-09-12 13:37:11 -04:00
==== 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.
Include realm type in Security Realm setting keys (#30241) This moves all Realm settings to an Affix definition. However, because different realm types define different settings (potentially conflicting settings) this requires that the realm type become part of the setting key. Thus, we now need to define realm settings as: xpack.security.authc.realms: file.file1: order: 0 native.native1: order: 1 - This is a breaking change to realm config - This is also a breaking change to custom security realms (SecurityExtension)
2018-11-05 22:56:50 -05:00
[DOCS] Swap `[float]` for `[discrete]` (#60134) Changes instances of `[float]` in our docs for `[discrete]`. Asciidoctor prefers the `[discrete]` tag for floating headings: https://asciidoctor.org/docs/asciidoc-asciidoctor-diffs/#blocks
2020-07-23 12:42:33 -04:00
[discrete]
Remove deprecated audit settings (#35205) Removes `.prefix` deprecated settings for the logfile auditing and also documents it in the migrate asciidoc.
2018-11-08 07:06:47 -05:00
[[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`.
[DOCS] Swap `[float]` for `[discrete]` (#60134) Changes instances of `[float]` in our docs for `[discrete]`. Asciidoctor prefers the `[discrete]` tag for floating headings: https://asciidoctor.org/docs/asciidoc-asciidoctor-diffs/#blocks
2020-07-23 12:42:33 -04:00
[discrete]
Include realm type in Security Realm setting keys (#30241) This moves all Realm settings to an Affix definition. However, because different realm types define different settings (potentially conflicting settings) this requires that the realm type become part of the setting key. Thus, we now need to define realm settings as: xpack.security.authc.realms: file.file1: order: 0 native.native1: order: 1 - This is a breaking change to realm config - This is also a breaking change to custom security realms (SecurityExtension)
2018-11-05 22:56:50 -05:00
[[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/"
--------------------------------------------------
Remove deprecated audit settings (#35205) Removes `.prefix` deprecated settings for the logfile auditing and also documents it in the migrate asciidoc.
2018-11-08 07:06:47 -05:00
Must be migrated to:
Include realm type in Security Realm setting keys (#30241) This moves all Realm settings to an Affix definition. However, because different realm types define different settings (potentially conflicting settings) this requires that the realm type become part of the setting key. Thus, we now need to define realm settings as: xpack.security.authc.realms: file.file1: order: 0 native.native1: order: 1 - This is a breaking change to realm config - This is also a breaking change to custom security realms (SecurityExtension)
2018-11-05 22:56:50 -05:00
[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.
Security: remove SSL settings fallback (#36846) This commit removes the fallback for SSL settings. While this may be seen as a non user friendly change, the intention behind this change is to simplify the reasoning needed to understand what is actually being used for a given SSL configuration. Each configuration now needs to be explicitly specified as there is no global configuration or fallback to some other configuration. Closes #29797
2019-01-14 16:06:22 -05:00
[DOCS] Swap `[float]` for `[discrete]` (#60134) Changes instances of `[float]` in our docs for `[discrete]`. Asciidoctor prefers the `[discrete]` tag for floating headings: https://asciidoctor.org/docs/asciidoc-asciidoctor-diffs/#blocks
2020-07-23 12:42:33 -04:00
[discrete]
Security: remove SSL settings fallback (#36846) This commit removes the fallback for SSL settings. While this may be seen as a non user friendly change, the intention behind this change is to simplify the reasoning needed to understand what is actually being used for a given SSL configuration. Each configuration now needs to be explicitly specified as there is no global configuration or fallback to some other configuration. Closes #29797
2019-01-14 16:06:22 -05:00
[[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.
Remove Watcher Account "unsecure" settings (#36736) Removes all sensitive settings (passwords, auth tokens, urls, etc...) for watcher notifications accounts. These settings were deprecated (and herein removed) in favor of their secure sibling that is set inside the elasticsearch keystore. For example: `xpack.notification.email.account.<id>.smtp.password` is no longer a valid setting, and it is replaced by `xpack.notification.email.account.<id>.smtp.secure_password`
2019-01-20 05:51:24 -05:00
[DOCS] Swap `[float]` for `[discrete]` (#60134) Changes instances of `[float]` in our docs for `[discrete]`. Asciidoctor prefers the `[discrete]` tag for floating headings: https://asciidoctor.org/docs/asciidoc-asciidoctor-diffs/#blocks
2020-07-23 12:42:33 -04:00
[discrete]
Remove TLS 1.0 as a default SSL protocol (#37512) The default value for ssl.supported_protocols no longer includes TLSv1 as this is an old protocol with known security issues. Administrators can enable TLSv1.0 support by configuring the appropriate `ssl.supported_protocols` setting, for example: xpack.security.http.ssl.supported_protocols: ["TLSv1.2","TLSv1.1","TLSv1"] Relates: #36021
2019-01-24 23:46:39 -05:00
[[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].
Enable TLSv1.3 by default for JDKs with support (#38103) This commit enables the use of TLSv1.3 with security by enabling us to properly map `TLSv1.3` in the supported protocols setting to the algorithm for a SSLContext. Additionally, we also enable TLSv1.3 by default on JDKs that support it. An issue was uncovered with the MockWebServer when TLSv1.3 is used that ultimately winds up in an endless loop when the client does not trust the server's certificate. Due to this, SSLConfigurationReloaderTests has been pinned to TLSv1.2. Closes #32276
2019-02-01 10:34:11 -05:00
The default protocols are now TLSv1.3 (if supported), TLSv1.2 and TLSv1.1.
Expand docs on TLSv1 breaking change (#49352) The breaking changes cover the removal of TLSv1 from the default protocols, but assume that users who need to retain TLSv1 support will understand all the places where they may used it. This has proven not to be true, as it is easy to be unaware that (for example) an LDAP server is using TLSv1. This change explicitly lists all the places where TLS protocols may need to be configured. Co-Authored-By: Lisa Cawley <lcawley@elastic.co> Co-Authored-By: Pius <pius@elastic.co>
2019-11-26 00:34:55 -05:00
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,
Deprecate disabling basic-license features (#54816) (#55405) We believe there's no longer a need to be able to disable basic-license features completely using the "xpack.*.enabled" settings. If users don't want to use those features, they simply don't need to use them. Having such features always available lets us build more complex features that assume basic-license features are present. This commit deprecates settings of the form "xpack.*.enabled" for basic-license features, excluding "security", which is a special case. It also removes deprecated settings from integration tests and unit tests where they're not directly relevant; e.g. monitoring and ILM are no longer disabled in many integration tests.
2020-04-17 15:04:17 -04:00
you must update this setting.
Expand docs on TLSv1 breaking change (#49352) The breaking changes cover the removal of TLSv1 from the default protocols, but assume that users who need to retain TLSv1 support will understand all the places where they may used it. This has proven not to be true, as it is easy to be unaware that (for example) an LDAP server is using TLSv1. This change explicitly lists all the places where TLS protocols may need to be configured. Co-Authored-By: Lisa Cawley <lcawley@elastic.co> Co-Authored-By: Pius <pius@elastic.co>
2019-11-26 00:34:55 -05:00
`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`::
Deprecate disabling basic-license features (#54816) (#55405) We believe there's no longer a need to be able to disable basic-license features completely using the "xpack.*.enabled" settings. If users don't want to use those features, they simply don't need to use them. Having such features always available lets us build more complex features that assume basic-license features are present. This commit deprecates settings of the form "xpack.*.enabled" for basic-license features, excluding "security", which is a special case. It also removes deprecated settings from integration tests and unit tests where they're not directly relevant; e.g. monitoring and ILM are no longer disabled in many integration tests.
2020-04-17 15:04:17 -04:00
For reindex from remote.
Expand docs on TLSv1 breaking change (#49352) The breaking changes cover the removal of TLSv1 from the default protocols, but assume that users who need to retain TLSv1 support will understand all the places where they may used it. This has proven not to be true, as it is easy to be unaware that (for example) an LDAP server is using TLSv1. This change explicitly lists all the places where TLS protocols may need to be configured. Co-Authored-By: Lisa Cawley <lcawley@elastic.co> Co-Authored-By: Pius <pius@elastic.co>
2019-11-26 00:34:55 -05:00
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:
Remove TLS 1.0 as a default SSL protocol (#37512) The default value for ssl.supported_protocols no longer includes TLSv1 as this is an old protocol with known security issues. Administrators can enable TLSv1.0 support by configuring the appropriate `ssl.supported_protocols` setting, for example: xpack.security.http.ssl.supported_protocols: ["TLSv1.2","TLSv1.1","TLSv1"] Relates: #36021
2019-01-24 23:46:39 -05:00
[source,yaml]
--------------------------------------------------
Enable TLSv1.3 by default for JDKs with support (#38103) This commit enables the use of TLSv1.3 with security by enabling us to properly map `TLSv1.3` in the supported protocols setting to the algorithm for a SSLContext. Additionally, we also enable TLSv1.3 by default on JDKs that support it. An issue was uncovered with the MockWebServer when TLSv1.3 is used that ultimately winds up in an endless loop when the client does not trust the server's certificate. Due to this, SSLConfigurationReloaderTests has been pinned to TLSv1.2. Closes #32276
2019-02-01 10:34:11 -05:00
xpack.security.http.ssl.supported_protocols: [ "TLSv1.3", "TLSv1.2", "TLSv1.1", "TLSv1" ]
Remove TLS 1.0 as a default SSL protocol (#37512) The default value for ssl.supported_protocols no longer includes TLSv1 as this is an old protocol with known security issues. Administrators can enable TLSv1.0 support by configuring the appropriate `ssl.supported_protocols` setting, for example: xpack.security.http.ssl.supported_protocols: ["TLSv1.2","TLSv1.1","TLSv1"] Relates: #36021
2019-01-24 23:46:39 -05:00
--------------------------------------------------
[DOCS] Swap `[float]` for `[discrete]` (#60134) Changes instances of `[float]` in our docs for `[discrete]`. Asciidoctor prefers the `[discrete]` tag for floating headings: https://asciidoctor.org/docs/asciidoc-asciidoctor-diffs/#blocks
2020-07-23 12:42:33 -04:00
[discrete]
Remove heuristics that enable security on trial licenses (#38075) In 6.3 trial licenses were changed to default to security disabled, and ee added some heuristics to detect when security should be automatically be enabled if `xpack.security.enabled` was not set. This change removes those heuristics, and requires that security be explicitly enabled (via the `xpack.security.enabled` setting) for trial licenses. Relates: #38009
2019-02-01 01:59:13 -05:00
[[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.
[DOCS] Swap `[float]` for `[discrete]` (#60134) Changes instances of `[float]` in our docs for `[discrete]`. Asciidoctor prefers the `[discrete]` tag for floating headings: https://asciidoctor.org/docs/asciidoc-asciidoctor-diffs/#blocks
2020-07-23 12:42:33 -04:00
[discrete]
Remove Watcher Account "unsecure" settings (#36736) Removes all sensitive settings (passwords, auth tokens, urls, etc...) for watcher notifications accounts. These settings were deprecated (and herein removed) in favor of their secure sibling that is set inside the elasticsearch keystore. For example: `xpack.notification.email.account.<id>.smtp.password` is no longer a valid setting, and it is replaced by `xpack.notification.email.account.<id>.smtp.secure_password`
2019-01-20 05:51:24 -05:00
[[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`
Remove index audit output type (#37707) This commit removes the Index Audit Output type, following its deprecation in 6.7 by 8765a31d4e6770. It also adds the migration notice (settings notice). In general, the problem with the index audit output is that event indexing can be slower than the rate with which audit events are generated, especially during the daily rollovers or the rolling cluster upgrades. In this situation audit events will be lost which is a terrible failure situation for an audit system. Besides of the settings under the `xpack.security.audit.index` namespace, the `xpack.security.audit.outputs` setting has also been deprecated and will be removed in 7. Although explicitly configuring the logfile output does not touch any deprecation bits, this setting is made redundant in 7 so this PR deprecates it as well. Relates #29881
2019-01-24 05:36:10 -05:00
[DOCS] Swap `[float]` for `[discrete]` (#60134) Changes instances of `[float]` in our docs for `[discrete]`. Asciidoctor prefers the `[discrete]` tag for floating headings: https://asciidoctor.org/docs/asciidoc-asciidoctor-diffs/#blocks
2020-07-23 12:42:33 -04:00
[discrete]
Remove index audit output type (#37707) This commit removes the Index Audit Output type, following its deprecation in 6.7 by 8765a31d4e6770. It also adds the migration notice (settings notice). In general, the problem with the index audit output is that event indexing can be slower than the rate with which audit events are generated, especially during the daily rollovers or the rolling cluster upgrades. In this situation audit events will be lost which is a terrible failure situation for an audit system. Besides of the settings under the `xpack.security.audit.index` namespace, the `xpack.security.audit.outputs` setting has also been deprecated and will be removed in 7. Although explicitly configuring the logfile output does not touch any deprecation bits, this setting is made redundant in 7 so this PR deprecates it as well. Relates #29881
2019-01-24 05:36:10 -05:00
[[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.
Add ECS schema for user-agent ingest processor (#37727) (#37984) * Add ECS schema for user-agent ingest processor (#37727) This switches the format of the user agent processor to use the schema from [ECS](https://github.com/elastic/ecs). So rather than something like this: ``` { "patch" : "3538", "major" : "70", "minor" : "0", "os" : "Mac OS X 10.14.1", "os_minor" : "14", "os_major" : "10", "name" : "Chrome", "os_name" : "Mac OS X", "device" : "Other" } ``` The structure is now like this: ``` { "name" : "Chrome", "original" : "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36", "os" : { "name" : "Mac OS X", "version" : "10.14.1", "full" : "Mac OS X 10.14.1" }, "device" : "Other", "version" : "70.0.3538.102" } ``` This is now the default for 7.0. The deprecated `ecs` setting in 6.x is not supported. Resolves #37329 * Remove `ecs` setting from docs
2019-01-30 13:24:18 -05:00
[DOCS] Swap `[float]` for `[discrete]` (#60134) Changes instances of `[float]` in our docs for `[discrete]`. Asciidoctor prefers the `[discrete]` tag for floating headings: https://asciidoctor.org/docs/asciidoc-asciidoctor-diffs/#blocks
2020-07-23 12:42:33 -04:00
[discrete]
Add ECS schema for user-agent ingest processor (#37727) (#37984) * Add ECS schema for user-agent ingest processor (#37727) This switches the format of the user agent processor to use the schema from [ECS](https://github.com/elastic/ecs). So rather than something like this: ``` { "patch" : "3538", "major" : "70", "minor" : "0", "os" : "Mac OS X 10.14.1", "os_minor" : "14", "os_major" : "10", "name" : "Chrome", "os_name" : "Mac OS X", "device" : "Other" } ``` The structure is now like this: ``` { "name" : "Chrome", "original" : "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36", "os" : { "name" : "Mac OS X", "version" : "10.14.1", "full" : "Mac OS X 10.14.1" }, "device" : "Other", "version" : "70.0.3538.102" } ``` This is now the default for 7.0. The deprecated `ecs` setting in 6.x is not supported. Resolves #37329 * Remove `ecs` setting from docs
2019-01-30 13:24:18 -05:00
[[ingest-user-agent-ecs-always]]
Make 7.x like 6.7 user agent ecs, but default to true (#38828) Forward port of https://github.com/elastic/elasticsearch/pull/38757 This change reverts the initial 7.0 commits and replaces them with the 6.7 variant that still allows for the ecs flag. This commit differs from the 6.7 variants in that ecs flag will now default to true. 6.7: `ecs` : default `false` 7.x: `ecs` : default `true` 8.0: no option, but behaves as `true` * Revert "Ingest node - user agent, move device to an object (#38115)" This reverts commit 5b008a34aa3c07e37b12b415d3c22a44da491329. * Revert "Add ECS schema for user-agent ingest processor (#37727) (#37984)" This reverts commit cac6b8e06f051d68919faf6081f1c87fa5b6757d. * cherry-pick 5dfe1935345da3799931fd4a3ebe0b6aa9c17f57 Add ECS schema for user-agent ingest processor (#37727) * cherry-pick ec8ddc890a34853ee8db6af66f608b0ad0cd1099 Ingest node - user agent, move device to an object (#38115) (#38121) * cherry-pick f63cbdb9b426ba24ee4d987ca767ca05a22f2fbb (with manual merge fixes) Dep. check for ECS changes to User Agent processor (#38362) * make true the default for the ecs option, and update 7.0 references and tests
2019-02-13 11:28:01 -05:00
==== 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.
Add missing "long form" 7.0 breaking changes (#41049) These are breaking changes that were present in the release notes but the PR didn't include any "narrative long form" description for the docs.
2019-04-10 09:41:04 -04:00
[DOCS] Swap `[float]` for `[discrete]` (#60134) Changes instances of `[float]` in our docs for `[discrete]`. Asciidoctor prefers the `[discrete]` tag for floating headings: https://asciidoctor.org/docs/asciidoc-asciidoctor-diffs/#blocks
2020-07-23 12:42:33 -04:00
[discrete]
Add missing "long form" 7.0 breaking changes (#41049) These are breaking changes that were present in the release notes but the PR didn't include any "narrative long form" description for the docs.
2019-04-10 09:41:04 -04:00
[[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.
[DOCS] Swap `[float]` for `[discrete]` (#60134) Changes instances of `[float]` in our docs for `[discrete]`. Asciidoctor prefers the `[discrete]` tag for floating headings: https://asciidoctor.org/docs/asciidoc-asciidoctor-diffs/#blocks
2020-07-23 12:42:33 -04:00
[discrete]
Add missing "long form" 7.0 breaking changes (#41049) These are breaking changes that were present in the release notes but the PR didn't include any "narrative long form" description for the docs.
2019-04-10 09:41:04 -04:00
==== 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.
[DOCS] Swap `[float]` for `[discrete]` (#60134) Changes instances of `[float]` in our docs for `[discrete]`. Asciidoctor prefers the `[discrete]` tag for floating headings: https://asciidoctor.org/docs/asciidoc-asciidoctor-diffs/#blocks
2020-07-23 12:42:33 -04:00
[discrete]
Add missing "long form" 7.0 breaking changes (#41049) These are breaking changes that were present in the release notes but the PR didn't include any "narrative long form" description for the docs.
2019-04-10 09:41:04 -04:00
==== HTTP Max content length setting is no longer parsed leniently
Previously, `http.max_content_length` would reset to `100mb` if the setting was
Clarified http.max_content_length description (#52329) Adding "greater than" based on discussion with @jasontedor for clarity.
2020-02-24 21:01:14 -05:00
greater than `Integer.MAX_VALUE`. This leniency has been removed.