FIPS checks should not be bootstrap checks

[jaymode]

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 @jasontedor

[elasticmachine]

Pinging @elastic/es-security

[jasontedor]

Yes!

[jkakavas]

I let that slip after 6.4 ,I'll be taking it up shortly

[LuisAlvelaMendes]

I'm not so sure I understand this issue .. I presume you're talking about classes like " FIPS140JKSKeystoreBootstrapCheck" and so forth, the ones called "FIPS140(..)". The idea would be to refactor them as subclasses of a FIPSChecks, changing their name but leaving all of their functionality the same?

Here's a somewhat illustrative diagram:
(I removed the FIPS140 repetition for subclasses and also the designation "Bootstrap".

[jkakavas]

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. FIPSChecks will not implement BootstrapCheck

In the benefit of not duplicating effort, note that I removed the help_wanted label a few days ago because I have this on my plate for one of the next minor releases. That said, I haven't actually started working on it yet so if this is something that interests you, I'd gladly work with you to get this merged if you still want to work on it

[LuisAlvelaMendes]

@jkakavas I'd like to work with you on this issue, yes,

[LuisAlvelaMendes]

@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?

[jkakavas]

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 ).
You can make decisions for the FIPS checks by looking at the settings only.

A fitting place to call the checks is in createComponents of the Security plugin

[LuisAlvelaMendes]

@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) {
return FIPSCheckResult.failure("FIPS mode is only allowed with a Platinum or Trial license");
}

Doesn't that require the context's metadata?

[jkakavas]

@LuisAlvelaMendes

We can use getLicenseState() from Security.java to get an XPackLicenseState and implement an isFipsAllowed() in there