FIPS Support is OSO 18:

• No change during adoption (off → off / on → on)
• Gets its FIPS value from the underlying OCP for Greenfield deployments. Customers must decide when deploying OCP.
• Day-1 operation, no switch once deployed.
• Requires testing that FIPS + HSM works.
• Need to create Epics for each DFGs

Regarding Paramiko, it requires upstream investigation to move OSO toward "Designed for FIPS" status.

This epic replaces OSP-29473 - RHOSO FIPS Compatibility, which had this description:

_This feature covers the move of OSP toward a layered product on OCP, with respect to FIPS support.

RHOSO should deploy in FIPS mode and obey FIPS requirements at least equivalent to those of OSP 17.1 (i.e. RHOSO is quite near to be "Designed for FIPS" and uses the proper cryptographic modules everywhere BUT for paramiko).

The work covers:

Feature parity of FIPS support from OSP 17.1 to RHOSO
Proper operator code operating in FIPS mode according to OCP operator FIPS best practices
Proper container images based on RHEL ELS and its openssl binary operating in FIPS mode
Tests
Documentation
with respect to:

development
QE
documentation
Each DFG is responsible for their parts.

Definition of done:

RHOSO deploys in FIPS mode and obey all OSP and OCP FIPS requirements
Progress tracking:

Periodic sync with one representative of each DFG to track progress
Cadence meeting (proposed every month)
Async updates on slack ( channel )
Jira FIPS board
FIPS work:

Epics:
https://issues.redhat.com/browse/OSP-600
https://issues.redhat.com/browse/OSP-9821
QE
https://issues.redhat.com/browse/OSP-20760
Upstream
https://issues.redhat.com/browse/OSP-26955_

RHOSO18 Defaults & adoptoin https://docs.google.com/document/d/1xJ8A8cSdZXiGanuDDFkHNmj9IN0LXCsd-m-FwzwV6a0/edit?usp=sharing