mirror of
https://github.com/honeymoose/OpenSearch.git
synced 2025-02-08 22:14:59 +00:00
* Use standard format for reload settings API The reload-secure-settings API page was not reorganized for the standard API format, so this commit is reorganizing the page and adding some links to the page in related documentation. * Fix broken links * Reorder examples to correctly check API response * Note that only certain settings are reloadable * [DOCS] Edits layout * [DOCS] Removes unnecessary callouts Co-authored-by: Lisa Cawley <lcawley@elastic.co> Co-authored-by: Lisa Cawley <lcawley@elastic.co>
This commit is contained in:
parent
d293980a09
commit
ba2810f23d
@ -4,8 +4,51 @@
|
|||||||
<titleabbrev>Nodes reload secure settings</titleabbrev>
|
<titleabbrev>Nodes reload secure settings</titleabbrev>
|
||||||
++++
|
++++
|
||||||
|
|
||||||
|
Reloads the keystore on nodes in the cluster.
|
||||||
|
|
||||||
The cluster nodes reload secure settings API is used to re-load the keystore on each node.
|
[[cluster-nodes-reload-secure-settings-api-request]]
|
||||||
|
==== {api-request-title}
|
||||||
|
|
||||||
|
`POST _nodes/reload_secure_settings` +
|
||||||
|
`POST _nodes/<nodes/reload_secure_settings`
|
||||||
|
|
||||||
|
[[cluster-nodes-reload-secure-settings-api-desc]]
|
||||||
|
==== {api-description-title}
|
||||||
|
|
||||||
|
<<secure-settings,Secure settings>> are stored in an on-disk keystore. Certain
|
||||||
|
of these settings are <<reloadable-secure-settings,reloadable>>. That is, you
|
||||||
|
can change them on disk and reload them without restarting any nodes in the
|
||||||
|
cluster. When you have updated reloadable secure settings in your keystore, you
|
||||||
|
can use this API to reload those settings on each node.
|
||||||
|
|
||||||
|
When the {es} keystore is password protected and not simply obfuscated, you must
|
||||||
|
provide the password for the keystore when you reload the secure settings.
|
||||||
|
Reloading the settings for the whole cluster assumes that all nodes' keystores
|
||||||
|
are protected with the same password; this method is allowed only when
|
||||||
|
<<tls-transport,inter-node communications are encrypted>>. Alternatively, you can
|
||||||
|
reload the secure settings on each node by locally accessing the API and passing
|
||||||
|
the node-specific {es} keystore password.
|
||||||
|
|
||||||
|
[[cluster-nodes-reload-secure-settings-path-params]]
|
||||||
|
==== {api-path-parms-title}
|
||||||
|
|
||||||
|
`<nodes>`::
|
||||||
|
(Optional, string) The names of particular nodes in the cluster to target.
|
||||||
|
For example, `nodeId1,nodeId2`. For node selection options, see
|
||||||
|
<<cluster-nodes>>.
|
||||||
|
|
||||||
|
NOTE: {es} requires consistent secure settings across the cluster nodes, but
|
||||||
|
this consistency is not enforced. Hence, reloading specific nodes is not
|
||||||
|
standard. It is justifiable only when retrying failed reload operations.
|
||||||
|
|
||||||
|
[[cluster-nodes-reload-secure-settings-api-request-body]]
|
||||||
|
==== {api-request-body-title}
|
||||||
|
|
||||||
|
`reload_secure_settings`::
|
||||||
|
(Optional, string) The password for the {es} keystore.
|
||||||
|
|
||||||
|
[[cluster-nodes-reload-secure-settings-api-example]]
|
||||||
|
==== {api-examples-title}
|
||||||
|
|
||||||
[source,console]
|
[source,console]
|
||||||
--------------------------------------------------
|
--------------------------------------------------
|
||||||
@ -15,50 +58,6 @@ POST _nodes/nodeId1,nodeId2/reload_secure_settings
|
|||||||
// TEST[setup:node]
|
// TEST[setup:node]
|
||||||
// TEST[s/nodeId1,nodeId2/*/]
|
// TEST[s/nodeId1,nodeId2/*/]
|
||||||
|
|
||||||
The first command reloads the keystore on each node. The seconds allows
|
|
||||||
to selectively target `nodeId1` and `nodeId2`. The node selection options are
|
|
||||||
detailed <<cluster-nodes,here>>.
|
|
||||||
|
|
||||||
NOTE: {es} requires consistent secure settings across the cluster nodes, but this consistency is not enforced.
|
|
||||||
Hence, reloading specific nodes is not standard. It is only justifiable when retrying failed reload operations.
|
|
||||||
|
|
||||||
==== Reload Password Protected Secure Settings
|
|
||||||
|
|
||||||
When the {es} keystore is password protected and not simply obfuscated, the password for the keystore needs
|
|
||||||
to be provided in the request to reload the secure settings.
|
|
||||||
Reloading the settings for the whole cluster assumes that all nodes' keystores are protected with the same password
|
|
||||||
and is only allowed when {ref}/configuring-tls.html#tls-transport[node to node communications are encrypted]
|
|
||||||
|
|
||||||
[source,js]
|
|
||||||
--------------------------------------------------
|
|
||||||
POST _nodes/reload_secure_settings
|
|
||||||
{
|
|
||||||
"reload_secure_settings": "s3cr3t" <1>
|
|
||||||
}
|
|
||||||
--------------------------------------------------
|
|
||||||
// NOTCONSOLE
|
|
||||||
|
|
||||||
<1> The common password that the {es} keystore is encrypted with in every node of the cluster.
|
|
||||||
|
|
||||||
Alternatively the secure settings can be reloaded on a per node basis, locally accessing the API and passing the
|
|
||||||
node-specific {es} keystore password.
|
|
||||||
|
|
||||||
[source,js]
|
|
||||||
--------------------------------------------------
|
|
||||||
POST _nodes/_local/reload_secure_settings
|
|
||||||
{
|
|
||||||
"reload_secure_settings": "s3cr3t" <1>
|
|
||||||
}
|
|
||||||
--------------------------------------------------
|
|
||||||
// NOTCONSOLE
|
|
||||||
|
|
||||||
<1> The password that the {es} keystore is encrypted with on the local node.
|
|
||||||
|
|
||||||
|
|
||||||
[float]
|
|
||||||
[[rest-reload-secure-settings]]
|
|
||||||
==== REST Reload Secure Settings Response
|
|
||||||
|
|
||||||
The response contains the `nodes` object, which is a map, keyed by the
|
The response contains the `nodes` object, which is a map, keyed by the
|
||||||
node id. Each value has the node `name` and an optional `reload_exception`
|
node id. Each value has the node `name` and an optional `reload_exception`
|
||||||
field. The `reload_exception` field is a serialization of the exception
|
field. The `reload_exception` field is a serialization of the exception
|
||||||
@ -82,3 +81,27 @@ that was thrown during the reload process, if any.
|
|||||||
--------------------------------------------------
|
--------------------------------------------------
|
||||||
// TESTRESPONSE[s/"my_cluster"/$body.cluster_name/]
|
// TESTRESPONSE[s/"my_cluster"/$body.cluster_name/]
|
||||||
// TESTRESPONSE[s/"pQHNt5rXTTWNvUgOrdynKg"/\$node_name/]
|
// TESTRESPONSE[s/"pQHNt5rXTTWNvUgOrdynKg"/\$node_name/]
|
||||||
|
|
||||||
|
The following example uses a common password for the {es} keystore on every
|
||||||
|
node of the cluster:
|
||||||
|
|
||||||
|
[source,js]
|
||||||
|
--------------------------------------------------
|
||||||
|
POST _nodes/reload_secure_settings
|
||||||
|
{
|
||||||
|
"reload_secure_settings": "s3cr3t"
|
||||||
|
}
|
||||||
|
--------------------------------------------------
|
||||||
|
// NOTCONSOLE
|
||||||
|
|
||||||
|
The following example uses a password for the {es} keystore on the local node:
|
||||||
|
|
||||||
|
[source,js]
|
||||||
|
--------------------------------------------------
|
||||||
|
POST _nodes/_local/reload_secure_settings
|
||||||
|
{
|
||||||
|
"reload_secure_settings": "s3cr3t"
|
||||||
|
}
|
||||||
|
--------------------------------------------------
|
||||||
|
// NOTCONSOLE
|
||||||
|
|
||||||
|
@ -25,7 +25,7 @@ are node-specific settings that must have the same value on every node.
|
|||||||
Just like the settings values in `elasticsearch.yml`, changes to the keystore
|
Just like the settings values in `elasticsearch.yml`, changes to the keystore
|
||||||
contents are not automatically applied to the running {es} node. Re-reading
|
contents are not automatically applied to the running {es} node. Re-reading
|
||||||
settings requires a node restart. However, certain secure settings are marked as
|
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.
|
*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
|
The values of all secure settings, *reloadable* or not, must be identical
|
||||||
across all cluster nodes. After making the desired secure settings changes,
|
across all cluster nodes. After making the desired secure settings changes,
|
||||||
@ -50,8 +50,8 @@ dependent on these settings have been changed. Everything should look as if the
|
|||||||
settings had the new value from the start.
|
settings had the new value from the start.
|
||||||
|
|
||||||
When changing multiple *reloadable* secure settings, modify all of them on each
|
When changing multiple *reloadable* secure settings, modify all of them on each
|
||||||
cluster node, then issue a `reload_secure_settings` call instead of reloading
|
cluster node, then issue a <<cluster-nodes-reload-secure-settings, `reload_secure_settings`>>
|
||||||
after each modification.
|
call instead of reloading after each modification.
|
||||||
|
|
||||||
There are reloadable secure settings for:
|
There are reloadable secure settings for:
|
||||||
|
|
||||||
|
Loading…
x
Reference in New Issue
Block a user