2017-01-30 17:56:45 -05:00
|
|
|
[[secure-settings]]
|
2018-07-01 04:11:47 -04:00
|
|
|
=== Secure settings
|
2017-01-30 17:56:45 -05:00
|
|
|
|
|
|
|
Some settings are sensitive, and relying on filesystem permissions to protect
|
2020-01-13 16:02:06 -05:00
|
|
|
their values is not sufficient. For this use case, {es} provides a
|
|
|
|
keystore and the <<elasticsearch-keystore,`elasticsearch-keystore` tool>> to
|
|
|
|
manage the settings in the keystore.
|
2017-01-30 17:56:45 -05:00
|
|
|
|
2019-06-20 17:27:07 -04:00
|
|
|
IMPORTANT: Only some settings are designed to be read from the keystore. However,
|
2020-01-13 16:02:06 -05:00
|
|
|
the keystore has no validation to block unsupported settings. Adding unsupported
|
|
|
|
settings to the keystore causes {es} to fail to start. To see whether a setting
|
|
|
|
is supported in the keystore, look for a "Secure" qualifier the setting
|
|
|
|
reference.
|
2017-06-14 00:04:16 -04:00
|
|
|
|
2020-01-13 16:02:06 -05:00
|
|
|
All the modifications to the keystore take affect only after restarting {es}.
|
2017-11-30 17:19:58 -05:00
|
|
|
|
2020-01-13 16:02:06 -05:00
|
|
|
NOTE: The {es} keystore currently only provides obfuscation. In the future,
|
2018-01-09 18:01:37 -05:00
|
|
|
password protection will be added.
|
|
|
|
|
2018-07-01 04:11:47 -04:00
|
|
|
These settings, just like the regular ones in the `elasticsearch.yml` config file,
|
|
|
|
need to be specified on each node in the cluster. Currently, all secure settings
|
|
|
|
are node-specific settings that must have the same value on every node.
|
|
|
|
|
2020-01-13 16:02:06 -05:00
|
|
|
[discrete]
|
2018-08-01 05:07:23 -04:00
|
|
|
[[reloadable-secure-settings]]
|
|
|
|
=== Reloadable secure settings
|
|
|
|
|
2020-01-13 16:02:06 -05:00
|
|
|
Just like the settings values in `elasticsearch.yml`, changes to the keystore
|
|
|
|
contents are not automatically applied to the running {es} node. Re-reading
|
|
|
|
settings requires a node restart. However, certain secure settings are marked as
|
|
|
|
*reloadable*. Such settings can be re-read and applied on a running node.
|
2018-08-01 05:07:23 -04:00
|
|
|
|
|
|
|
The values of all secure settings, *reloadable* or not, must be identical
|
|
|
|
across all cluster nodes. After making the desired secure settings changes,
|
|
|
|
using the `bin/elasticsearch-keystore add` command, call:
|
2019-09-05 10:11:25 -04:00
|
|
|
|
|
|
|
[source,console]
|
2018-08-01 05:07:23 -04:00
|
|
|
----
|
|
|
|
POST _nodes/reload_secure_settings
|
|
|
|
----
|
2019-09-05 10:11:25 -04:00
|
|
|
|
2020-01-13 16:02:06 -05:00
|
|
|
This API decrypts and re-reads the entire keystore, on every cluster node,
|
|
|
|
but only the *reloadable* secure settings are applied. Changes to other
|
|
|
|
settings do not go into effect until the next restart. Once the call returns,
|
|
|
|
the reload has been completed, meaning that all internal data structures
|
|
|
|
dependent on these settings have been changed. Everything should look as if the
|
|
|
|
settings had the new value from the start.
|
2018-08-01 05:07:23 -04:00
|
|
|
|
2020-01-13 16:02:06 -05:00
|
|
|
When changing multiple *reloadable* secure settings, modify all of them on each
|
|
|
|
cluster node, then issue a `reload_secure_settings` call instead of reloading
|
|
|
|
after each modification.
|
2019-09-04 13:12:03 -04:00
|
|
|
|
|
|
|
There are reloadable secure settings for:
|
|
|
|
|
2019-09-05 13:44:21 -04:00
|
|
|
* {plugins}/repository-azure-client-settings.html[The Azure repository plugin]
|
2019-09-04 17:43:58 -04:00
|
|
|
* {plugins}/discovery-ec2-usage.html#_configuring_ec2_discovery[The EC2 discovery plugin]
|
2019-09-04 19:24:55 -04:00
|
|
|
* {plugins}/repository-gcs-client.html[The GCS repository plugin]
|
2019-09-04 17:43:58 -04:00
|
|
|
* {plugins}/repository-s3-client.html[The S3 repository plugin]
|