Secrets management by using a vault init container

You can use external vault software to manage your FTM secrets instead of using the Red Hat® OpenShift® secrets. Provide an init container image that interfaces with the vault software and makes its information available to the Financial Transaction Manager (FTM) application containers. The FTM images do not provide this interface.

If you use external vault software to manage the FTM secrets, deploy IBM® Db2® and IBM MQ external to Red Hat OpenShift.

Note:

For the solutions that use IBM App Connect, the truststore and keystore passwords need to be stored in Red Hat OpenShift secrets so the IBM App Connect components can access them. If those passwords are not specified in the FTM custom resource, the FTM operator creates random passwords and stores them in a secret to use for the truststore and keystore passwords.

When you use an external secure vault, FTM stores its certificates, keys, and passwords in the external vault instead of Red Hat OpenShift secrets. The FTM TLS CA certificate, however, must be stored in an Red Hat OpenShift secret. Reference this secret using the spec.config.security.certificate key in the FTM custom resource.

A vault init container reads the secrets from an external vault and makes that information available for the FTM application containers to use. After the vault init container reads the secrets from the external vault, it puts the secrets in a file named /shared/vars.env. If this file exists, the FTM containers read the secrets from the file and ignore the values that are in the Red Hat OpenShift secrets.

The init container must mount a volume that is named ftm-shared. The FTM containers also mount this volume and read the vars.env file that the init container created in this volume.

Init containers that are used to interface with external vault software must be named ftm-init-secrets.

Create the vault secrets file for the FTM containers

The init container makes the FTM secrets that are in the external vault available to the FTM containers by creating the /shared/vars.env file. This file contains the secrets as name-value pairs with the format that is shown in the following sample.

DB_PASSWORD=db2pw
QMGR_PASSWORD=mqpw
KSTORE_PASSWORD=kspw
TSTORE_PASSWORD=tspw
FXH_PASSWORD=fxhpw
KEY_P12=Base64 encoded value
TRUSTSTORE_JKS=Base64 encoded value

Add values to the vars.env file as plain text, except for the values for the key names that represent binary files. Add the values for these key names as Base64 encoded values. For example, the KEY_P12 and TRUSTSTORE_JKS key names represent binary files.

The entrypoint script of the FTM containers uses the keys as key names. The entrypoint either uses the values from these key names in the component configuration or uses them to update the configuration. The keys include the certificate or keystore files that the Red Hat OpenShift Container Platform secrets support. For example, the KEY_P12 and TRUSTSTORE_JKS key names. These key names are made available as environment variables to the FTM process that is running inside the FTM container.

For more information about the keys, see Key names for the vault secrets file.

Deploy init container with FTM

Add this YAML section to the spec structure of the custom resource. Make sure that the init.default.initContainers[0].image parameter is configured with the init container image. You can use this section of the YAML to add any other environment variables that the init container needs.

  init:
    default:
      initContainers:
        - name: ftm-init-secrets
          image: <init-image>
          volumeMounts:
            - name: ftm-shared
              mountPath: /shared
          env:
            - name: SHARED_FILE
              value: /shared/vars.env

Verify that the vault data was received by the FTM containers

If init container support is enabled and the FTM secrets were successfully retrieved from the external vault, you see specific log messages in the container logs. The following examples show the format of the vault data messages that are logged in the container logs.

For the Java™ Platform, Standard Edition and Java Platform, Enterprise Edition containers, the vault data messages in the container log have the following format.

[Info] Following Keys are found in the shared file
<Key1> <Key2> <Key3>
.......

.......

<KeyN>