63 lines
2.7 KiB
Plaintext
63 lines
2.7 KiB
Plaintext
[[secure-settings]]
|
|
=== Secure settings
|
|
|
|
Some settings are sensitive, and relying on filesystem permissions to protect
|
|
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.
|
|
|
|
IMPORTANT: Only some settings are designed to be read from the keystore. However,
|
|
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.
|
|
|
|
All the modifications to the keystore take affect only after restarting {es}.
|
|
|
|
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.
|
|
|
|
[discrete]
|
|
[[reloadable-secure-settings]]
|
|
=== Reloadable secure settings
|
|
|
|
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 <<cluster-nodes-reload-secure-settings, re-read and applied on a running node>>.
|
|
|
|
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:
|
|
|
|
[source,console]
|
|
----
|
|
POST _nodes/reload_secure_settings
|
|
{
|
|
"secure_settings_password": "s3cr3t" <1>
|
|
}
|
|
----
|
|
// NOTCONSOLE
|
|
|
|
<1> The password that the {es} keystore is encrypted with.
|
|
|
|
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.
|
|
|
|
When changing multiple *reloadable* secure settings, modify all of them on each
|
|
cluster node, then issue a <<cluster-nodes-reload-secure-settings, `reload_secure_settings`>>
|
|
call instead of reloading after each modification.
|
|
|
|
There are reloadable secure settings for:
|
|
|
|
* {plugins}/repository-azure-client-settings.html[The Azure repository plugin]
|
|
* {plugins}/discovery-ec2-usage.html#_configuring_ec2_discovery[The EC2 discovery plugin]
|
|
* {plugins}/repository-gcs-client.html[The GCS repository plugin]
|
|
* {plugins}/repository-s3-client.html[The S3 repository plugin]
|
|
* <<monitoring-settings>>
|