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:
  • API Connect must be installed on Red Hat OpenShift Container Platform 4.12 or 4.14
  • Only FIPS version 140-2 is supported
  • FIPS must be configured on the cluster before you install API Connect
  • You must deploy API Connect 10.0.7.0 or later, with DataPower Gateway 10.5.3 or later
    For DataPower, refer to the following documentation for the most up-to-date information on DataPower FIPS support:

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-2 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).

FIPS wall diagram
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 10.0.8.0 can be deployed with the following versions of OpenShift Container Platform (OCP):
  • version 4.12: supported on Red Hat Enterprise Linux 8.6; on-going certification for FIPS 140-2 and 140-3
  • version 4.14: supported on Red Hat Enterprise Linux 8.6, 8.7, and 8.8; on-going certification for FIPS 140-2 and 140-3
For more information about OpenShift support for FIPS, see

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

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

  2. 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
      
  3. 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.
  4. Log in to the cluster as a user with cluster-admin privileges.

  5. Validate the OpenShift cluster.
    1. Verify that FIPS is enabled on the OpenShift cluster.
      1. 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
      2. 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
    2. Verify that IPSec is enabled on the OpenShift cluster.
      1. 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
        
      2. 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>
  6. Enable etcd encryption with aescbc as explained in Encrypting etcd data in the Red Hat OpenShift documentation.

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

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

  2. 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
    apic-a7s-ai-endpoint       apic-a7s-ai-endpoint-apic.apps.fips-apic.cp.fyre.ibm.com              apic-a7s-mtls-gw        4443   passthrough          None
    apic-gw-gateway            apic-gw-gateway-apic.apps.fips-apic.cp.fyre.ibm.com                   apic-gw-datapower       9443   passthrough          None
    apic-gw-gateway-manager    apic-gw-gateway-manager-apic.apps.fips-apic.cp.fyre.ibm.com           apic-gw-datapower       3000   passthrough          None
    apic-mgmt-admin            apic-mgmt-admin-apic.apps.fips-apic.cp.fyre.ibm.com                   apic-mgmt-juhu          2005   reencrypt/Redirect   None
    apic-mgmt-api-manager      apic-mgmt-api-manager-apic.apps.fips-apic.cp.fyre.ibm.com             apic-mgmt-juhu          2006   reencrypt/Redirect   None
    apic-mgmt-consumer-api     apic-mgmt-consumer-api-apic.apps.fips-apic.cp.fyre.ibm.com            apic-mgmt-juhu          2001   reencrypt/Redirect   None
    apic-mgmt-platform-api     apic-mgmt-platform-api-apic.apps.fips-apic.cp.fyre.ibm.com            apic-mgmt-juhu          2000   reencrypt/Redirect   None
    apic-ptl-portal-director   apic-ptl-portal-director-apic.apps.fips-apic.cp.fyre.ibm.com          apic-ptl-nginx          4443   passthrough          None
    apic-ptl-portal-web        apic-ptl-portal-web-apic.apps.fips-apic.cp.fyre.ibm.com               apic-ptl-b1aab746-www   4443   reencrypt/Redirect   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