Considerations for FIPS

• FIPS Wall: Current IBM approach to FIPS compliance
• How foundational services meets FIPS Compliance requirements
• Enable FIPS between Nodes
• FIPS Compliance scenarios
• FIPS Mode in foundational services

Prerequisites

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.

Important:

• Foundational services complies with the security and privacy assessments, which may or may not apply to all add-on services on foundational services.

• Customers are responsible for ensuring their own readiness for the laws and regulations that apply to them.

• Customers are responsible for identifying and interpreting any relevant laws and regulations that might affect their users and any actions their users might need to take to comply with these laws and regulations.

• Customers must track whether personal information is present in their data. Foundational services is not aware of the presence of personal information in the data that it handles.

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.

• Is IBM Cloud Pak FIPS compliant?: Yes, our overall product is FIPS compliant. The internals are treated as a black box, and anything exposed externally (outside the boundary) is FIPS compliant. The black box itself is secure, as any traffic that leaves the box (that is, to communicate across nodes) is also transparently secured.
• Note that the outbound communication to external services requires the external service to be configured for FIPS compliant connections only to ensure compliant communication.

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
    1
    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:

   networking:
     clusterNetwork:
     - cidr: 10.128.0.0/14
       hostPrefix: 23
     networkType: OVNKubernetes
     serviceNetwork:
     - 172.30.0.0/16
   

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

   apiVersion: operator.openshift.io/v1
   kind: Network
   metadata:
     name: cluster
   spec:
     defaultNetwork:
       ovnKubernetesConfig:
         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.

   

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

   

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

   

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

• Services that support FIPS: FIPS compliant encryption is validated for some services in foundational services. Find information about your service.

• Enabling FIPS: Learn how to enable FIPS and run foundational services on a FIPS compliant system.