Secure settings

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 effect only after restarting Elasticsearch.

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 settings

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, using the bin/elasticsearch-keystore add command, call:

  1. POST _nodes/reload_secure_settings
  2. {
  3.   "secure_settings_password": "s3cr3t" 
  4. }

The password that the Elasticsearch 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 reload_secure_settings call instead of reloading after each modification.

There are reloadable secure settings for: