-
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
FIPS checks should not be bootstrap checks #34772
Comments
Pinging @elastic/es-security |
Yes! |
I let that slip after 6.4 ,I'll be taking it up shortly |
Hi @LuisAlvelaMendes, thank you for your interest in this issue. The idea is that we want to remove all the FIPS 140 related checks (the ones you have correctly identified above) from being Bootstrap Checks as the FIPS checks are always enforced. In the benefit of not duplicating effort, note that I removed the |
@jkakavas I'd like to work with you on this issue, yes, |
@jkakavas I understand now that FIPSChecks will require it's own FIPSInterface - however, my problem is understanding "BootstrapContext" better. I suppose these FIPS 140 related checks will have to receive a FIPSContext to make decisions on instead of a BootstrapContext - I simply don't understand what the difference between a FIPS context and a Bootstrap one is, won't they both need the settings and metadata of the node? |
Hi @LuisAlvelaMendes , apologies for the late reply. This fell through the cracks of my to-do list. There is a conceptual difference. Bootstrap checks are meant to be enforced only on production mode ( not on development mode ) and thus adding the FIPS checks as Bootstrap checks in the beginning was an abuse of the interface ( as FIPS checks should always be enforced ). A fitting place to call the checks is in |
@jkakavas What about the license check? Where it reads: License license = LicenseService.getLicense(context.metaData); if (license != null && ALLOWED_LICENSE_OPERATION_MODES.contains(license.operationMode()) == false) { Doesn't that require the context's metadata? |
We can use |
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
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
We currently have FIPS bootstrap checks, but really these do not fit as a bootstrap check since they are always enforced. We should refactor these checks into a
FIPSChecks
class that can be instantiated on startup. cc @jasontedorThe text was updated successfully, but these errors were encountered: