Some settings are sensitive, and relying on filesystem permissions to protect
their values is not sufficient. For this use case, Elasticsearch provides a
keystore and the
elasticsearch-keystore tool to
manage the settings in the keystore.
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 Elasticsearch 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 Elasticsearch.
The Elasticsearch keystore currently only provides obfuscation. In the future, password protection will be added.
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.
Reloadable secure settingsedit
Just like the settings values in
elasticsearch.yml, changes to the keystore
contents are not automatically applied to the running Elasticsearch 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.
The values of all secure settings, reloadable or not, must be identical
across all cluster nodes. After making the desired secure settings changes,
bin/elasticsearch-keystore add command, call:
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
reload_secure_settings call instead of reloading
after each modification.
There are reloadable secure settings for: