mirror of
https://github.com/elastic/elasticsearch.git
synced 2025-04-25 07:37:19 -04:00
bd873698bc
We were depending on the BouncyCastle FIPS own mechanics to set
itself in approved only mode since we run with the Security
Manager enabled. The check during startup seems to happen before we
set our restrictive SecurityManager though in
org.elasticsearch.bootstrap.Elasticsearch , and this means that
BCFIPS would not be in approved only mode, unless explicitly
configured so.
This commit sets the appropriate JVM property to explicitly set
BCFIPS in approved only mode in CI and adds tests to ensure that we
will be running with BCFIPS in approved only mode when we expect to.
It also sets xpack.security.fips_mode.enabled to true for all test clusters
used in fips mode and sets the distribution to the default one. It adds a
password to the elasticsearch keystore for all test clusters that run in fips
mode.
Moreover, it changes a few unit tests where we would use bcrypt even in
FIPS 140 mode. These would still pass since we are bundling our own
bcrypt implementation, but are now changed to use FIPS 140 approved
algorithms instead for better coverage.
It also addresses a number of tests that would fail in approved only mode
Mainly:
Tests that use PBKDF2 with a password less than 112 bits (14char). We
elected to change the passwords used everywhere to be at least 14
characters long instead of mandating
the use of pbkdf2_stretch because both pbkdf2 and
pbkdf2_stretch are supported and allowed in fips mode and it makes sense
to test with both. We could possibly figure out the password algorithm used
for each test and adjust password length accordingly only for pbkdf2 but
there is little value in that. It's good practice to use strong passwords so if
our docs and tests use longer passwords, then it's for the best. The approach
is brittle as there is no guarantee that the next test that will be added won't
use a short password, so we add some testing documentation too.
This leaves us with a possible coverage gap since we do support passwords
as short as 6 characters but we only test with > 14 chars but the
validation itself was not tested even before. Tests can be added in a followup,
outside of fips related context.
Tests that use a PKCS12 keystore and were not already muted.
Tests that depend on running test clusters with a basic license or
using the OSS distribution as FIPS 140 support is not available in
neither of these.
Finally, it adds some information around FIPS 140 testing in our testing
documentation reference so that developers can hopefully keep in
mind fips 140 related intricacies when writing/changing docs.
92 lines
3.1 KiB
Text
92 lines
3.1 KiB
Text
[[cluster-nodes-reload-secure-settings]]
|
|
=== Nodes reload secure settings API
|
|
++++
|
|
<titleabbrev>Nodes reload secure settings</titleabbrev>
|
|
++++
|
|
|
|
Reloads the keystore on nodes in the cluster.
|
|
|
|
[[cluster-nodes-reload-secure-settings-api-request]]
|
|
==== {api-request-title}
|
|
|
|
`POST _nodes/reload_secure_settings` +
|
|
`POST _nodes/<node_id>/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}
|
|
|
|
`<node_id>`::
|
|
(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}
|
|
|
|
`secure_settings_password`::
|
|
(Optional, string) The password for the {es} keystore.
|
|
|
|
[[cluster-nodes-reload-secure-settings-api-example]]
|
|
==== {api-examples-title}
|
|
|
|
The following examples assume a common password for the {es} keystore on every
|
|
node of the cluster:
|
|
|
|
[source,console]
|
|
--------------------------------------------------
|
|
POST _nodes/reload_secure_settings
|
|
{
|
|
"secure_settings_password":"keystore-password"
|
|
}
|
|
POST _nodes/nodeId1,nodeId2/reload_secure_settings
|
|
{
|
|
"secure_settings_password":"keystore-password"
|
|
}
|
|
--------------------------------------------------
|
|
// TEST[setup:node]
|
|
// TEST[s/nodeId1,nodeId2/*/]
|
|
|
|
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`
|
|
field. The `reload_exception` field is a serialization of the exception
|
|
that was thrown during the reload process, if any.
|
|
|
|
[source,console-result]
|
|
--------------------------------------------------
|
|
{
|
|
"_nodes": {
|
|
"total": 1,
|
|
"successful": 1,
|
|
"failed": 0
|
|
},
|
|
"cluster_name": "my_cluster",
|
|
"nodes": {
|
|
"pQHNt5rXTTWNvUgOrdynKg": {
|
|
"name": "node-0"
|
|
}
|
|
}
|
|
}
|
|
--------------------------------------------------
|
|
// TESTRESPONSE[s/"my_cluster"/$body.cluster_name/]
|
|
// TESTRESPONSE[s/"pQHNt5rXTTWNvUgOrdynKg"/\$node_name/]
|