General FAQ for OpenShift and FIPS compliance

Q: How does OpenShift achieve Federal Information Processing Standards (FIPS) compliance?

A: Products are not FIPS validated, cryptographic components are. When Red Hat OpenShift 4 is deployed on FIPS-enabled Red Hat Enterprise Linux CoreOS (RHCOS) nodes or Red Hat Enterprise Linux (RHEL) worker nodes, correctly compiled OpenShift platform golang binaries will use RHEL FIPS validated or Modules in Process OpenSSL instead of the standard golang cryptographic module.

Some components include OpenSSL directly in their builds and use it for cryptography regardless of whether the cluster is booted in FIPS mode, with one such component being HAProxy.

Q: Which RHEL cryptographic modules are FIPS validated?

A: Red Hat has five RHEL cryptographic modules that are submitted for FIPS testing by the accredited test lab and validation by [NIST’s Cryptographic Module Validation Program] (https://csrc.nist.gov/Projects/cryptographic-module-validation-program/validated-modules) (CMVP):
- OpenSSL
- The kernel crypto API
- Network Security Services (NSS)
- GnuTLS
- libgcrypt

Q: What is FIPS 140-2 vs FIPS 140-3?

A: NIST moved to validate against FIPS 140-3, effective 22 September 2019. RHEL 8 cryptographic modules were submitted for FIPS 140-2 validation; only security non-relevant changes and CVE fixes are allowed for submission under FIPS 140-2. Red Hat froze the userspace modules and only released limited security-relevant changes to continue FIPS 140-2; however, this was not possible for kernel Crypto API. The RHEL 8.6 kernel module will be the first FIPS 140-3 validated module for RHEL 8. It is currently on the Implementation Under Test list. In the FIPS 140-3 Transition Effort, existing FIPS 140-2 validations are active through 21 September 2026. RHEL 9.0 cryptographic modules have been submitted for FIPS 140-3 validation, starting with OpenSSL and NSS, both of which are pending review by the CMVP on the Modules In Process list. We expect the remaining modules to be submitted by 15 July 2023.

Red Hat submits OpenSSL and the kernel crypto API for FIPS validation in all minor RHEL releases when the module binary is changed, and has done so beginning with RHEL 8.1. Current information on completed validations and certifications can be found on the Red Hat Government Standards page.

RHCOS is included in submissions, as RHCOS uses the same cryptographic libraries as RHEL. RHEL CoreOS is listed in the Security Policy document because it uses a validated cryptographic module and its binary is unchanged.

Q: What versions of RHEL binaries map to Red Hat OpenShift versions?

A: The following versions of RHEL and OpenShift binaries are mapped:
- OpenShift 4.7 uses RHEL 8.4 binaries as of z stream 4.7.21
- OpenShift 4.8, 4.9, and 4.10 use RHEL 8.4 binaries
- OpenShift 4.11 and 4.12 use RHEL 8.6 binaries
- OpenShift 4.13 uses RHEL 9.2 binaries

Q: What OpenShift components are out of scope for FIPS compliance?

A: OpenShift Container Platform 4.13 is based on Red Hat Enterprise Linux (RHEL) 9.2. RHEL 9.2 has not yet been submitted for FIPS validation. Red Hat expects, though cannot commit to a specific timeframe, to obtain FIPS validation for RHEL 9.0 and RHEL 9.2 modules, and later even minor releases of RHEL 9.x. Updates will be available on the Compliance Activities and Government Standards page.

Not all layered solutions and optional operators build for or claim FIPS compliance. The following components are not FIPS compliant:
OpenShift command line (oc CLI) running in a non-FIPS environment
Windows servers running the Windows Operating System.
OpenShift 3.x

Q: How can I verify that my custom images are FIPS-ready?

A: To build golang images that are FIPS ready, start by viewing section 4.5 in the Red Hat Enterprise Linux 8 Security Hardening Guide.

Go containers rely on OpenSSL to detect whether the system is in FIPS mode, so without OpenSSL in the custom image, FIPS mode will not be detected. Ensure that you include RHEL OpenSSL in your container image.

Follow the steps below:

1.Use the RHEL golang compiler or container image to build your binary
2.Set CGO_ENABLED=1
3.Ensure there is no extldflags -static set for the build
4.Ensure no -tags no_openssl