We are looking to add support for FIPS 140-3 compliance to GeoServer in order to support clients who intend to run GeoServer in FedRAMP High environments.
This is mostly a JVM and web server configuration exercise which could be considered out of scope for the GeoServer project. However, there are required application level code changes required to support FIPS compliant crypto operations. Details here → Jira
NGS intends to introduce Bouncy Castle’s FIPS compliant library bc-fips so that users may configure GeoServer to operate in a FIPS compliant mode.
Backwards Compatibility: We intend to make this configuration an “opt-in” process. So if you don’t care about FIPS, there is no action required.
Migration: We will also provide a script for migrating secrets from existing non-compliant keystores (JCEKS) to compliant ones. Again, this will be an optional action, only required if you want to run in FIPS mode.
Any feedback and/or guidance for the implementation will be greatly appreciated. Thank you.
Hi @jnewmoyer glad you are finding the developer forum okay.
While I do not need to understand the operational details you need to meet; I do wish to see you succeed. It looks like GEOS-10512 has the start of a conversation that was not continued …
I encourage you to drop in to on of the GeoServer meetings. The result will be to outline what is required as a proposal for discussion.
Keep in mind the project is in the middle of setting up the codebase for GeoServer 3, so if you can schedule the work in time for GeoServer 2.28.0 September it would be advisable.
Hi Jason,
am I right in assuming this discussion is related to the following PR?
The code changes there looked permanent, with a relatively complex migration (for many users at least), here you’re discussing something that is opt-in instead.
Can you describe how you plan to switch it to an opt-in approach?
Connecting to what Jody said, we begun the GeoServer 3 refactorings, so far most are unrelated, but in a few months a large set of fundamental upgrades will follow (Spring 6, Jakarta EE and so on). I also encourage you to try and complete the FIPS compliane work before those changes hit the codebase (tentatively, sometimes between late September and December).
Another bit that you should consider, is future maitenance of these changes. As an opt-in process, the normal GeoServer build won’t follow the new code paths. Also important, there is no sort of manual testing in GeoServer releases. So in order to keep the changes operational, your team will have to write test that either simulate a migration and check basic operations with GeoServer involving password encryption, or start the tests with an empty data directory already in FIPS mode, and tests by setting up stores, users and the like.
Final note, in the contribution process mind the basic PR checklist and ensure every bit is covered, CLA, documentation (as RST, so that it lands in docs.geoserver.org), and testing.
As Jody said, you can drop on your bi-weekly meetings, while not mandatory,
it’s often a quicker way to discuss complex matters. But keeping the discussion here on list is also fine.
Thank you for the guidance. Yes, that’s the PR. Closed it for now as we rework the backwards compatibility aspects and documentation.
Backwards compatibility: We plan on adding a configuration variable (env var or D flag) that, when set, loads up the FIPS compliant keystore configuration.
Migration of secrets: A utility will be provided for migrating all secrets from the old keystores to the new FIPS compliant ones. This procedure will be documented in the “Production Considerations” section of the docs, and will be required before starting up in FIPS mode. A migration path backwards will also be provided in the case that new or updated secrets need to be migrated back to non-FIPS compliant keystores.
We do plan on completing internal testing by the end of July.
GEOS-10512 is the ticket and we’ll make updates there once the PR is opened.