Configuring FIPS support on OpenShift

Configure support for FIPS (Federal Information Processing Standards) on the cluster where you will install IBM API Connect.

Before you begin

API Connect supports FIPS with the following limitations:

Only FIPS version 140 is supported
FIPS must be configured on the cluster before you install API Connect
For the most up-to-date information on DataPower FIPS support, see Known limitations and restrictions.
- Cloud Pak for Integration - Gateway instance additionally notes the FIPS and FIPS-Wall status

Attention: Developer Portal does not support FIPS in API Connect 12.1.1.0.

About this task

To be FIPS compliant, an organization must adhere to the various data security and computer system standards outlined in the FIPS requirements. FIPS compliance for API Connect is supported by implementing a "FIPS wall".

What is 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.

API Connect supports version 140 of the FIPS requirements, implemented using the "FIPS wall" approach.

What is a FIPS wall?

The "FIPS wall" is a boundary approach to FIPS compliance that is used by IBM products. All pods in the cluster are FIPS-tolerant (the pods can run without issues on a FIPS-enabled OpenShift cluster), while creating a compliant "boundary" that is secured at external points of contact (known as "touch points").

Traffic inside the boundary is secure because the communication between nodes is automatically encrypted at the OpenShift Container Platform level using the IPSec protocol. Traffic within any node happens in-memory, so it never leaves the node. The following diagram illustrates a typical OpenShift cluster that is configured to support the FIPS wall. In the diagram, the "wall" is represented with a heavy black border. Communications between pods within the border are secured with IPSec encryption, and communications that cross the border to external devices are secured using other means for example, TLS encryption).

What are the cluster requirements to support a FIPS wall?

FIPS is enabled on the cluster during installation (by setting fips: true in the install-config.yaml file)
FIPS is enabled for node-to-node communication (using the OVN-Kubernetes Container Network Interface cluster network provider, and with IPSec enabled)
The etcd key-value store is encrypted with aescbc
Storage is encrypted with FIPS ciphers
Runtimes are managed using Kubernetes CRI-O (all OCP deployments use CRI-O by default)

What are the Red Hat OpenShift Container Platform dependencies?

API Connect 12.1.1.0 can be deployed with the following version of OpenShift Container Platform (OCP):

version 4.19 - 4.21 on-going certification for FIPS 140.

For more information about OpenShift support for FIPS, see

Current status on FIPS certification: Compliance Activities and Government Standards in the Red Hat Customer Portal

Install and configure OpenShift Container Platform

Configure settings for FIPS and IPSec, install the OpenShift cluster, and then configure the cluster to enable encryption and provide storage.

Procedure

Configure settings in the install-config.yaml file.
Edit the install-config.yaml and make the following changes:
- Set fips: true
- Set the networkType to OVNKubernetes
For example:
```
networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  networkType: OVNKubernetes
  serviceNetwork:
  - 172.30.0.0/16
fips: true
```
For an example of the install-config.yaml file, see Sample install-config.yaml file for bare metal in the Red Hat OpenShift documentation.
Create the IPSec installation manifests to allow IPSec tunneling for node-to-node communication in the OpenShift cluster.
1. Generate the manifests from install-config.yaml by running the following command:
```
openshift-install create manifests
```
2. Create a cluster-network-03-config.yaml file with the following content, and save it in the manifests directory:
```
apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  defaultNetwork:
    type: OVNKubernetes
    ovnKubernetesConfig:
      ipsecConfig: {}
      mtu: 1400
```
Deploy the OpenShift cluster.
Install the OpenShift cluster, and then install the OpenShift CLI.
1. Install the OpenShift cluster as explained in Chapter 2. Installing the system in FIPS mode in the Red Hat OpenShift "FIPS support" documentation.
2. Install the OpenShift CLI (oc) as explained in Installing the OpenShift CLI in the Red Hat OpenShift documentation.
Log in to the cluster as a user with cluster-admin privileges.

Validate the OpenShift cluster.

Verify that FIPS is enabled on the OpenShift cluster.

Run the following command to verify the fips setting:

oc get cm cluster-config-v1 -n kube-system -o json | jq -r '.data."install-config"' | grep -i "fips"

Review the results and verify that the fips setting is set to true:

fips: true
  name: fips-apic
  root@fips-apic

Run the following command to get the names of the machine configurations:

oc get mcp

In the result, the configuration name appears in the CONFIG column; for example:

NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
master   rendered-master-41831cf684b6e570518728abd24b9006   True      False      False      3              3                   3                     0                      15h
worker   rendered-worker-2a4937983238e94a74307abc3eed2080   True      False      False      7              7                   7                     0                      15h

For each configuration listed in the result, run the following command to verify that Fips is set to true:

oc describe mc <CONFIG> | grep Fips

The previous example returned two configurations, so run the command on each configuration:

oc describe mc rendered-master-41831cf684b6e570518728abd24b9006 | grep Fips
  Fips:  true

oc describe mc rendered-worker-2a4937983238e94a74307abc3eed2080 | grep Fips
  Fips:  true

Verify that IPSec is enabled on the OpenShift cluster.

Check the ovn-ipsec daemonset that manages the daemons responsible for configuring IPSec:

oc get ds -n openshift-ovn-kubernetes ovn-ipsec

A successful result looks like the following example:

NAME        DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR                 AGE
ovn-ipsec   66666           beta.kubernetes.io/os=linux   3d3h

Verify that IPSec pods are running in all of the nodes in your OpenShift cluster:

oc get pod -n openshift-ovn-kubernetes -o wide | grep ipsec

A successful result looks like the following example:

 ovn-ipsec-4qp86        1/1     Running   0          38m   192.168.7.23   master2.ocp4.rober.lab   <none>           <none>
 ovn-ipsec-pk7vh        1/1     Running   0          38m   192.168.7.21   master0.ocp4.rober.lab   <none>           <none>
 ovn-ipsec-q4mwj        1/1     Running   0          22m   192.168.7.11   worker0.ocp4.rober.lab   <none>           <none>
 ovn-ipsec-trz5m        1/1     Running   0          22m   192.168.7.12   worker1.ocp4.rober.lab   <none>           <none>
 ovn-ipsec-vjmw8        1/1     Running   0          38m   192.168.7.22   master1.ocp4.rober.lab   <none>           <none>

Enable etcd encryption with aescbc as explained in Encrypting etcd data in the Red Hat OpenShift documentation.
For local storage, choose either RHEL-provided disk encryption or Container Native Storage that uses RHEL-provided disk encryption.

By storing all data in volumes that use RHEL-provided disk encryption and enabling FIPS mode for your cluster, both data at rest and data in motion (network data) are protected by FIPS-validated or Modules In Process encryption. You can configure your cluster to encrypt the root filesystem of each node, as described in Customizing nodes in the Red Hat OpenShift documentation.

Install API Connect

Install API Connect on the OpenShift cluster, and ensure that server connections support FIPS.

Procedure

Install API Connect.

For instructions on installing API Connect with the top-level CR, see Installing with the top-level CR on OpenShift in this documentation. For instructions on installing API Connect with subsystem CRs, see Installing API Connect in a single namespace on OpenShift or Installing API Connect subsystems in different namespaces or environments on OpenShift in this documentation.

Ensure that all server connections support FIPS.

Inbound connections: ensure that the Gateway API invocation endpoint supports FIPS

The following list shows the inbound connections to an API Connect deployment:

% oc get routes

NAME                                          HOST/PORT                                          PATH             SERVICES       PORT         TERMINATION           WILDCARD

analytics-ai-endpoint               ai.apps.dnath-fedtest2.cp.fyre.ibm.com                      analytics-mtls-gw                4443        passthrough/None         None

devportal-devportal-admin           api.devportal.apps.dnath-fedtest2.cp.fyre.ibm.com           devportal-proxy                  4443        passthrough/None         None

devportal-devportal-web             devportal.apps.dnath-fedtest2.cp.fyre.ibm.com               devportal-devportal              8443        reencrypt/None           None

fam-admin-endpoint                  api.fam.apps.dnath-fedtest2.cp.fyre.ibm.com                 fam-ingw                         4443        passthrough/None         None

fam-ui-endpoint                     fam.apps.dnath-fedtest2.cp.fyre.ibm.com                     fam-ingress                      8443        reencrypt/None           None

gwv6-gateway                        rgw.apps.dnath-fedtest2.cp.fyre.ibm.com                     gwv6-datapower                   9443        passthrough/None         None

gwv6-gateway-manager                rgwd.apps.dnath-fedtest2.cp.fyre.ibm.com                    gwv6-datapower                   3000        passthrough/None         None

management-admin                    admin.apps.dnath-fedtest2.cp.fyre.ibm.com                   management-juhu                  2005        reencrypt/None           None

management-api-discovery-service    api.apps.dnath-fedtest2.cp.fyre.ibm.com/discovery           management-juhu                  2083        reencrypt/None           None

management-api-manager              manager.apps.dnath-fedtest2.cp.fyre.ibm.com                 management-juhu                  2006        reencrypt/None           None

management-compliance-api           api.apps.dnath-fedtest2.cp.fyre.ibm.com /governance         management-juhu                  2077        reencrypt/None           None

management-consumer-api             consumer.apps.dnath-fedtest2.cp.fyre.ibm.com                management-juhu                  2001        reencrypt/None           None

management-consumer-catalog         consumer-catalog.apps.dnath-fedtest2.cp.fyre.ibm.com        management-juhu                  2013        reencrypt/None           None

management-platform-api             api.apps.dnath-fedtest2.cp.fyre.ibm.com                     management-juhu                  2000        reencrypt/None           None

ngw-mgmt-endpoint                   apic-gateway-proxy.apps.dnath-fedtest2.cp.fyre.ibm.com      ngw-nanogw-gateway-proxy         4443        passthrough/None         None

ngw-nanogw                          wildcard.nanogw.apps.dnath-fedtest2.cp.fyre.ibm.com         ngw-nanogw-svc              port-443-to-3443  passthrough/None         Subdomain

portal-portal-director              api.portal.apps.dnath-fedtest2.cp.fyre.ibm.com              portal-nginx                     4443        passthrough/None         None

portal-portal-web                   portal.apps.dnath-fedtest2.cp.fyre.ibm.com                  portal-34e9911c-www              4443        reencrypt/None           None

wmapigateway-gateway-endpoint       wmapigateway-gw.apps.dnath-fedtest2.cp.fyre.ibm.com         wmapigateway-apigateway          5543        passthrough/None         None

wmapigateway-mgmt-endpoint          wmapigateway-mgmt.apps.dnath-fedtest2.cp.fyre.ibm.com       wmapigateway-proxy               4443        passthrough/None         None

wmapigateway-ui-endpoint            wmapigateway-ui.apps.dnath-fedtest2.cp.fyre.ibm.com         wmapigateway-apigateway          9073        reencrypt/None           None

All of the inbound connections support FIPS by default, except for the Gateway API invocation endpoint.

The TLS server profile used by the DataPower Gateway for API invocation is configured from the Cloud Manager when you create a gateway service. To be FIPS compliant, the TLS server profile used with a gateway service must be configured with FIPS-only ciphers to ensure that the server only accepts FIPS connections.

To configure the TLS server profile, use the Cloud Manager's Register Service > DataPower Gateway page, which you can access from the Topology menu. Locate the API invocation endpoint section and use the Server Name Indication (SNI) - TLS server profile setting to create the server profile. Use a TLS server profile that is FIPS-compliant (for example, do not use: TLS_CHACHA20_POLY1305_SHA256, which is not compliant). For information on configuring the TLS server profile, see Registering a gateway service in this documentation.

Outbound connections: Ensure that all of the outbound connections support FIPS

For outbound connections, it is your responsibility to ensure that the external servers configured with API Connect accept only FIPS connections. The following list shows the typical outbound connections for an API Connect deployment

OIDC providers (Google, Facebook, Keycloak etc.)
LDAP providers
Authentication URLs
External user registry
Target URLs used in APIs
Remote backups
Auditing endpoints
SMTP endpoints
Analytics offloading
Analytics backup to S3 storage
Automated API behavior testing tool (ATM) - calls out to the APIs being tested
Portal - Potential drupal extensions installed by customer
Portal - SFTP and S3 backups
2-data-center deployments - Calls to other clusters