-
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
Refactor FIPS BootstrapChecks to simple checks #47499
Conversation
FIPS 140 bootstrap checks should not be bootstrap checks as they are always enforced. This commit moves the validation logic within the security plugin. The FIPS140SecureSettingsBootstrapCheck was not applicable as the keystore was being loaded on init, before the Bootstrap checks were checked, so an elasticsearch keystore of version < 3 would cause the node to fail in a FIPS 140 JVM before the bootstrap check kicked in, and as such hasn't been migrated. Resolves: elastic#34772
Pinging @elastic/es-security (:Security/Security) |
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.
LGTM.
@@ -326,8 +326,11 @@ public Security(Settings settings, final Path configPath) { | |||
|
|||
} | |||
|
|||
private static void runStartupChecks(Settings settings) { |
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.
Why is this no longer static? validateForFips
is static, so I can't see why this method needs to change.
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.
Leftover change from uncompleted attempt I'd guess, wasn't left on purpose
} | ||
Settings keystorePathSettings = settings.filter(k -> k.endsWith("keystore.path")) | ||
.filter(k -> settings.hasValue(k.replace(".path", ".type")) == false); | ||
// Default Keystore type is JKS in JDK8 and PKCS12 in > JDK9 if not explicitly set |
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.
This is not the case. We explicitly set the keystore type to JKS, and don't depend on the JVM default.
Lines 245 to 252 in 9945d5c
private static String inferKeyStoreType(String path) { | |
String name = path == null ? "" : path.toLowerCase(Locale.ROOT); | |
if (name.endsWith(".p12") || name.endsWith(".pfx") || name.endsWith(".pkcs12")) { | |
return PKCS12_KEYSTORE_TYPE; | |
} else { | |
return DEFAULT_KEYSTORE_TYPE; | |
} | |
} |
Perhaps we should call inferKeyStoreType
here instead.
@@ -303,19 +307,15 @@ public Security(Settings settings, final Path configPath) { | |||
this.env = new Environment(settings, configPath); | |||
this.enabled = XPackSettings.SECURITY_ENABLED.get(settings); | |||
if (enabled) { | |||
runStartupChecks(settings); | |||
runStartupChecks(settings, getLicenseState()); |
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.
Is license state meaningful at this point during node start up?
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.
I see your point. Should we just remove checks for license on node startup and only leave ValidateLicenseForFIPS
on node joins ?
} | ||
|
||
if (licenseState != null && FIPS_ALLOWED_LICENSE_OPERATION_MODES.contains(licenseState.getOperationMode()) == false) { | ||
validationErrors.add("FIPS mode is only allowed with a Platinum or Trial license"); |
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.
The error message should be built from FIPS_ALLOWED_LICENSE_OPERATION_MODES
@@ -273,6 +275,8 @@ | |||
DiscoveryPlugin, MapperPlugin, ExtensiblePlugin { | |||
|
|||
private static final Logger logger = LogManager.getLogger(Security.class); | |||
static final EnumSet<License.OperationMode> FIPS_ALLOWED_LICENSE_OPERATION_MODES = | |||
EnumSet.of(License.OperationMode.PLATINUM, License.OperationMode.TRIAL); |
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.
Can we move this to XPackLicenseState
? We ought to keep licensing decisions centralised.
@@ -253,7 +255,7 @@ public void testJoinValidatorForFIPSLicense() throws Exception { | |||
new Security.ValidateLicenseForFIPS(false).accept(node, state); | |||
|
|||
final boolean isLicenseValidForFips = | |||
FIPS140LicenseBootstrapCheck.ALLOWED_LICENSE_OPERATION_MODES.contains(license.operationMode()); | |||
Security.FIPS_ALLOWED_LICENSE_OPERATION_MODES.contains(license.operationMode()); |
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.
This (existing) test is testing 2 different scenarios based on randomness in the license type.
Can we move it to 2 explicit test cases?
@tvernum I believe I have addressed your comments, if you want to take another look at this |
@elasticmachine run elasticsearch-ci/packaging-sample-matrix |
2 similar comments
@elasticmachine run elasticsearch-ci/packaging-sample-matrix |
@elasticmachine run elasticsearch-ci/packaging-sample-matrix |
|
@elasticmachine run elasticsearch-ci/packaging-sample-matrix |
@elasticmachine run elasticsearch-ci/packaging-sample-matrix |
@elasticmachine run elasticsearch-ci/packaging-sample |
@elasticmachine run elasticsearch-ci/packaging-sample |
@elasticmachine run elasticsearch-ci/packaging-sample-matrix |
2 similar comments
@elasticmachine run elasticsearch-ci/packaging-sample-matrix |
@elasticmachine run elasticsearch-ci/packaging-sample-matrix |
@elasticmachine update branch |
@elasticmachine run elasticsearch-ci/packaging-sample-matrix |
FIPS 140 bootstrap checks should not be bootstrap checks as they are always enforced. This commit moves the validation logic within the security plugin. The FIPS140SecureSettingsBootstrapCheck was not applicable as the keystore was being loaded on init, before the Bootstrap checks were checked, so an elasticsearch keystore of version < 3 would cause the node to fail in a FIPS 140 JVM before the bootstrap check kicked in, and as such hasn't been migrated. Resolves: elastic#34772
FIPS 140 bootstrap checks should not be bootstrap checks as they are always enforced. This commit moves the validation logic within the security plugin. The FIPS140SecureSettingsBootstrapCheck was not applicable as the keystore was being loaded on init, before the Bootstrap checks were checked, so an elasticsearch keystore of version < 3 would cause the node to fail in a FIPS 140 JVM before the bootstrap check kicked in, and as such hasn't been migrated. Resolves: #34772
* elastic/master: [Docs] Fix opType options in IndexRequest API example. (elastic#48290) Simplify Shard Snapshot Upload Code (elastic#48155) Mute ClassificationIT tests (elastic#48338) Reenable azure repository tests and remove some randomization in http servers (elastic#48283) Use an env var for the classpath of jar hell task (elastic#48240) Refactor FIPS BootstrapChecks to simple checks (elastic#47499) Add "format" to "range" queries resulted from optimizing a logical AND (elastic#48073) [DOCS][Transform] document limitation regarding rolling upgrade with 7.2, 7.3 (elastic#48118) Fail with a better error when if there are no ingest nodes (elastic#48272) Fix executing enrich policies stats (elastic#48132) Use MultiFileTransfer in CCR remote recovery (elastic#44514) Make BytesReference an interface (elastic#48171) Also validate source index at put enrich policy time. (elastic#48254) Add 'javadoc' task to lifecycle check tasks (elastic#48214) Remove option to enable direct buffer pooling (elastic#47956) [DOCS] Add 'Selecting gateway and seed nodes' section to CCS docs (elastic#48297) Add Enrich Origin (elastic#48098) fix incorrect comparison (elastic#48208)
FIPS 140 bootstrap checks should not be bootstrap checks as they
are always enforced. This commit moves the validation logic within
the security plugin.
The FIPS140SecureSettingsBootstrapCheck was not applicable as the
keystore was being loaded on init, before the Bootstrap checks
were checked, so an elasticsearch keystore of version < 3 would
cause the node to fail in a FIPS 140 JVM before the bootstrap check
kicked in, and as such hasn't been migrated.
Resolves: #34772
Replaces: #36677