Expose a flag from Security Plugin that will let consumers know Kibana is running in FIPS mode

[kc13greiner]

Describe the feature: Kibana can be configured to run in FIPS mode. When configured to run in FIPS mode, unsupported hashing algorithms, such as MD5 will cause Node to throw an error.

If plugins still want to provide MD5 hashes in their features, they will need a way to check if Kibana is running in FIPS mode and conditionally hide that feature.

The Security plugin should expose which mode Kibana is running in: Standard or FIPS

[elasticmachine]

Pinging @elastic/kibana-security (Team:Security)

[legrego]

@elastic/kibana-core @elastic/kibana-security Would y'all like this flag to be available from core.security.*, or should we keep it within the security plugin contracts until we determine a need for pushing this into core?

More broadly (😅), is our goal for Core to expose all necessary security contracts (making the security plugin an implementation detail), or is our goal for Core to expose a meaningful subset, while leaving some services exposed from the security plugin?

[azasypkin]

More broadly (😅), is our goal for Core to expose all necessary security contracts (making the security plugin an implementation detail), or is our goal for Core to expose a meaningful subset, while leaving some services exposed from the security plugin?

Conceptually, I see security features as an indispensable part of the core, meaning that I'd expect the security plugin to eventually become a group of security-related domains/modules within the core itself (even though I'm not a fan of the packages-hell we have today 🙈). Exposing some security-related functionality from the core and some from the security plugin is a reasonable intermediate step, but it will keep confusing our consumers and make our lives harder until we fully consolidate security-related logic in one area.

With that, using core.security.* namespace or similar for the FIPS flag makes sense to me in the long term. That being said, I could see us having core.security.unstable.*, or core.security.experimental.*, or temporarily keeping stuff in security plugin land (while we have it) for anything that we need to expose ASAP, but still want to take some time to discuss and stabilize the requirements for.

Just my two cents, I'd like to hear what the rest of the team think.

[pgayvallet]

I agree with @azasypkin, I think it would make sense to expose this from core.security.*

Also, I'd say that overall, given the security-in-core initiative, we probably want to try exposing new security feature directly from Core (and also probably not at all from the security plugin if we can), unless we have a technical of functional reason to not follow those rules for specific cases.

WDYT?

[azasypkin]

Also, I'd say that overall, given the security-in-core initiative, we probably want to try exposing new security feature directly from Core (and also probably not at all from the security plugin if we can), unless we have a technical of functional reason to not follow those rules for specific cases.

I agree.

Regarding the FIPS feature, I believe we have two main components: the fipsMode.enable boolean configuration flag that we'd like to expose to other plugins and a licensing check. The configuration flag and its associated validation logic could be implemented in Core and exposed directly from there. This time, we need to, and I believe we can, expose it from the setup contracts. The licensing check will remain in the Security plugin for now, as it doesn't seem feasible to implement it in Core at this point (and it's internal-only, so shouldn't be a big deal). @kc13greiner please keep me honest here.

[pgayvallet]

This time, we need to, and I believe we can, expose it from the setup contracts

If the logic is fully held in Core, and the API doesn't need to delegates anything to the security plugin, then exposing from Core's setup contract shouldn't be an issue