[[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>>