Considerations for FIPS


Federal Information Processing Standards (FIPS) are standards and guidelines issued by the National Institute of Standards and Technology (NIST) for federal government computer systems. The standards are developed when there are compelling federal government requirements for standards, such as for security and interoperability, but acceptable industry standards or solutions do not exist. Government agencies and financial institutions use these standards to ensure that products conform to specified security requirements.


FIPS Wall: Current IBM approach to FIPS compliance

Our current approach to FIPS compliance is a boundary approach, enabled by the "FIPS Wall". This is an approach to FIPS compliance where all pods are FIPS tolerant (that is, pods can run without issues on a FIPS-enabled Red Hat® OpenShift® cluster), while creating a compliant "boundary" that is secured at external touchpoints.

Traffic inside the boundary is still secure, as traffic between nodes is automatically encrypted at the OpenShift Container Platform level using IPSec, while traffic inside a given node happens in-memory and thus never leaves the node.

Figure 1. FIPS Wall

Ensuring foundational services meets FIPS compliance requirements

  1. The OpenShift cluster must be deployed in FIPS mode. Set fips: true in the install-config.yaml file before you deploy your cluster (see Support for FIPS cryptography).

    Validation – Connect to the master or worker node by using oc debug node/<node name>:

     sh-4.4# cat /proc/sys/crypto/fips_enabled
     sh-4.4# sysctl crypto.fips_enabled
     crypto.fips_enabled = 1

    Alternatively, you can look for the FIPS setting in the cluster-config-v1 configmap oc get cm cluster-config-v1 -n kube-system and ensure fips:true in the data section.

  2. Foundational services routes must be configured using re-encrypt instead of passthrough. This guarantees the external communication between the client (such as a browser or a terminal) and the service uses OpenShift FIPS cryptography for TLS. If the route is a passthrough, the route's target service must use a FIPS-validated module, or support being re-configured to be a re-encrypt route. The route certificate must use FIPS-approved algorithm and key size such as 2048-bit RSA certificate.

  3. Pod-to-pod communication must be TLS protected at all times. FIPS is preferred but not mandatory for internal communication. Optionally, pod-to-pod communication across nodes can be protected at the network layer by enabling IPSec and using the OVN Kubernetes CNI plugin. IPSec encrypts the data packets using FIPS validated module from the operating system. For more information, see Encrypting traffic between nodes with IPsec.

  4. Local storage and etcd encryption use Red Hat FIPS-validated module. If the customer chooses to use a vendor-specific storage solution, then they should follow the vendor-provided procedure to turn on the FIPS mode.

Enable FIPS between nodes

  1. Switch the default Container Network Interface (CNI), OpenShift SDN, to OVN-Kubernetes CNI by changing the install-config.yaml to the following:

      - cidr:
        hostPrefix: 23
      networkType: OVNKubernetes
  2. Create a manifest for the installation so that you can add cluster-network-03-config.yml to the manifest:

    kind: Network
      name: cluster
          ipsecConfig: {}
  3. Complete the install.

  4. For more information on network configuration, see Network configuration phases.

FIPS compliance scenarios

The following diagrams illustrate FIPS compliance scenarios.

  1. OpenShift is running on FIPS mode. The OpenShift Container Platform route is re-encrypt.

    FIPS cluster reencrypt
    Figure 2. FIPS cluster reencrypt

  2. OpenShift is running on FIPS mode. The OpenShift Container Platform route is passthrough and the target service is running on FIPS mode.

    FIPS cluster passthrough
    Figure 3. FIPS cluster passthrough

  3. OpenShift is running on FIPS mode. In addition, IPSec FIPS encryption is turned on.

    FIPS cluster IPSec
    Figure 4. FIPS cluster IPSec

FIPS Mode in foundational services

There IM component in foundational services can be FIPS enabled. The settings are independent from OpenShift FIPS, which means that even if the cluster host operating system is not FIPS enabled, these components can still run in FIPS mode.

More information on FIPS