-
Notifications
You must be signed in to change notification settings - Fork 24.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[DOCS] Reloadable Secure Settings #31713
Changes from 1 commit
e9c6c47
85b4ff3
49823b3
eeee21c
529af80
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -11,7 +11,7 @@ include::install_remove.asciidoc[] | |
==== Azure Repository | ||
|
||
To enable Azure repositories, you have first to define your azure storage settings as | ||
{ref}/secure-settings.html[secured settings]: | ||
{ref}/secure-settings.html[secure settings], before starting up the node: | ||
|
||
[source,sh] | ||
---------------------------------------------------------------- | ||
|
@@ -20,6 +20,7 @@ bin/elasticsearch-keystore add azure.client.default.key | |
---------------------------------------------------------------- | ||
|
||
Where `account` is the azure account name and `key` the azure secret key. | ||
These settings are used by the repository's internal azure client. | ||
|
||
Note that you can also define more than one account: | ||
|
||
|
@@ -31,7 +32,18 @@ bin/elasticsearch-keystore add azure.client.secondary.account | |
bin/elasticsearch-keystore add azure.client.secondary.key | ||
---------------------------------------------------------------- | ||
|
||
`default` is the default account name which will be used by a repository unless you set an explicit one. | ||
`default` is the default account name which will be used by a repository, | ||
unless you set an explicit one in the | ||
<<repository-azure-repository-settings, repository settings>>. | ||
|
||
Both `account` and `key` storage settings are | ||
{ref}/secure-settings.html#reloadable-secure-settings[reloadable]. After the | ||
reload call returns, all internal azure clients will use the latest | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Unless you follow that "reloadable" link, it's not clear what "the reload call" is. I recommend something like this: "After you reload the settings, all....". Ditto in other pages where this text is used. |
||
settings from the keystore. | ||
|
||
NOTE: In progress snapshot/restore jobs will not be preempted by a *reload* | ||
of the storage secure settings. They will complete using the client as it was built | ||
when the operation started. | ||
|
||
You can set the client side timeout to use when making any single request. It can be defined globally, per account or both. | ||
It's not set by default which means that Elasticsearch is using the | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -35,9 +35,9 @@ PUT _snapshot/my_s3_repository | |
==== Client Settings | ||
|
||
The client used to connect to S3 has a number of settings available. Client setting names are of | ||
the form `s3.client.CLIENT_NAME.SETTING_NAME` and specified inside `elasticsearch.yml`. The | ||
default client name looked up by a `s3` repository is called `default`, but can be customized | ||
with the repository setting `client`. For example: | ||
the form `s3.client.CLIENT_NAME.SETTING_NAME`. The default client name, which is looked up by | ||
an `s3` repository, is called `default`. It can be modified using the | ||
<<repository-s3-repository, repository setting>> `client`. For example: | ||
|
||
[source,js] | ||
---- | ||
|
@@ -53,17 +53,27 @@ PUT _snapshot/my_s3_repository | |
// CONSOLE | ||
// TEST[skip:we don't have s3 setup while testing this] | ||
|
||
Some settings are sensitive and must be stored in the {ref}/secure-settings.html[elasticsearch keystore]. | ||
For example, to use explicit AWS access keys: | ||
Most client settings are specified inside `elasticsearch.yml`, but some are | ||
sensitive and must be stored in the {ref}/secure-settings.html[elasticsearch keystore]. | ||
For example, to use explicit AWS access keys, execute: | ||
|
||
[source,sh] | ||
---- | ||
bin/elasticsearch-keystore add s3.client.default.access_key | ||
bin/elasticsearch-keystore add s3.client.default.secret_key | ||
---- | ||
|
||
The following are the available client settings. Those that must be stored in the keystore | ||
are marked as `Secure`. | ||
to add settings value to the keystore, before starting up the node. Any existing `s3` | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'd suggest moving this sentence fragment up above the code block. e.g. Change to something like this: "For example, before you start the node, run these commands to add AWS access key settings to the keystore:" |
||
repositories, as well as any newly created ones, will pick up the values stored | ||
in the keystore. *All* client secure settings of this plugin are | ||
{ref}/secure-settings.html#reloadable-secure-settings[reloadable]. After the | ||
reload call returns, `s3` clients will use the latest settings from the keystore. | ||
|
||
NOTE: In progress snapshot/restore jobs will not be preempted by a *reload* | ||
of the client's secure settings. They will complete using the client as it was | ||
built when the operation started. | ||
|
||
The following is the list of all the available client settings. | ||
Those that must be stored in the keystore are marked as `Secure` and are *reloadable*. | ||
|
||
`access_key`:: | ||
|
||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -75,3 +75,34 @@ To remove a setting from the keystore, use the `remove` command: | |
bin/elasticsearch-keystore remove the.setting.name.to.remove | ||
---------------------------------------------------------------- | ||
|
||
[float] | ||
[[reloadable-secure-settings]] | ||
=== Reloadable secure settings | ||
|
||
Just like the settings values in `elasticsearch.yml`, changes to the | ||
keystore contents will not be automatically applied to the running | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not a big deal, but I'd change "will not be" to "are not" |
||
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: | ||
[source,js] | ||
---- | ||
POST _nodes/reload_secure_settings | ||
{ | ||
"secure_settings_password": "" | ||
} | ||
---- | ||
// CONSOLE | ||
This API will decrypt and re-read the entire keystore, on every cluster node, | ||
but only the *reloadable* secure settings will be applied. Changes to other | ||
settings will not get into effect until the next restart. Once the call returns, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. s/get/go |
||
the reload has been completed, meaning that all internal datastructures dependent | ||
on these settings have been changed. The reload operation is defined in | ||
relation with each *reloadable* secure setting. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not sure I understand the last sentence (The reload operation is defined...). What are the implications? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It is an artifact, from back when I was trying to explain too much here instead of going into details on each individual plugin. |
||
|
||
When changing multiple *reloadable* secure settings, modify all of them, on | ||
each cluster node, and then issue a `reload_secure_settings` call, instead | ||
of reloading after each modification. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems like there's a word missing here. What will be using an sdk client?