mirror of
https://github.com/elastic/elasticsearch.git
synced 2025-04-24 23:27:25 -04:00
c0b24df307
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.
63 lines
2.8 KiB
Text
63 lines
2.8 KiB
Text
[[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 effect 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": "keystore-password" <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>>
|
|
* <<notification-settings>>
|