Secrets Management and Key Handling

Red Hat OpenShift Secrets vs Vault for Secrets

FTM supports storing sensitive configuration values in Kubernetes secrets or in an external vault. Use the method that aligns with your enterprise security policies.

By default, Kubernetes secrets in Red Hat® OpenShift® store sensitive configuration values required by FTM, such as database passwords, IBM® MQ credentials, and keystore passwords. The FTM operator looks for certain secret names or secret references that are provided in the (CR), and loads them into environment variables or config files. For example, the main FTM application secret usually contains keys like DB_PASSWORD, DB_USER, QMGR_PASSWORD, and FXH_PASSWORD.

Alternatively, if Kubernetes secrets are not preferred, FTM provides an init container integration with HashiCorp vault that can retrieve secrets from an external vault and feed them to FTM at startup. Use vault integration to adopt a centralized and secure secret management pattern, especially in enterprise environments that already use vault.

External secrets vault integration through init containers

When vault integration is enabled, the vault init container runs before the main FTM containers start. It connects to your vault and retrieves the necessary secrets. These secrets are written to a shared file, which is mounted in a shared emptyDir volume, usually at /ftm-init-shared/secrets/vault_secrets.env. This file contains the necessary secrets as environment variable declarations.

When the main FTM container starts, it detects this file loads those secrets into its environment, updates the application configuration with the secrets retrieved from the vault and deletes the .env file. If the vault secrets file is not available, when the main container starts, FTM defaults behavior to using native Red Hat OpenShift secrets.

For more information about FTM init container support and secrets management by using a vault init container, see FTM init container support.

Protecting keystore and truststore passwords

The TLS keystore and truststore are created by the operator in a secret, which is called ftm-store by default, and secured with passwords. By default, these passwords are randomly generated and are unknown to human operators. However, you can choose to override them if required.

To override the default passwords, specify spec.config.security.keyStorePassword and trustStorePassword in the custom resource (CR). Regardless of how they are set, these passwords must be treated like any other secret.

If you use a vault for secret management, use KSTORE_PASSWORD and TSTORE_PASSWORD as the keys. These passwords can be rotated. When generating a new keystore with a new password, update the secret and the custom resource, and restart the application to ensure that all components receive the updated password.

OIDC Client secret

The OIDC client secret is the password or client secret that is used for FTM’s registration with your OIDC provider. Store this secret in a Kubernetes secret. Within that secret, the key must be exactly clientsecret because the operator looks for .data["clientsecret"].

In the FTM custom resource (CR), refer to this secret by name in the oidc.oAuth2ClientSecret. Ensure that the secret is created before deploying FTM and that it is available in the same namespace.

Keep this client secret safe and rotate it if you regenerate client credentials with your identity provider (IdP). If you use vault, store the client secret under OIDC_CLIENT_SECRET in the vault secrets file so that it is available in the environment for the Control Center container. For more information about Creating an OIDC secret, see Create an OIDC secret for your FTM installation on Red Hat OpenShift.

Certificate Management

Generate unique X.509 certificates for each FTM deployment environment. This requirement includes the certificate that is used by FTM’s HTTPS endpoints. Always use a different set of certificates for each deployment, even if they are self-signed. This approach helps prevent an attacker who compromises one environment’s certificate or key from affecting others.

Store these certs and keys in Kubernetes secrets or vault. Typically, the ftm-store secret holds a keystore (such as ftm.p12 or similar) that contains the TLS certificate and private key for FTM’s endpoints.

If you want to supply your own cert, you can replace or override this secret before installation. For example, you can create a PKCS#12 or JKS keystore with your cert and key, store it in a secret, and then specify the secret in the custom resource (CR) using spec.config.security.keystoreSecret. If you are providing only a certificate, you can use the additionalCertificates field to provide the base64-encoded certificate. The truststore should include any necessary certificate authorities (CAs).

Creating FTM Certificates

You can use a certificate manager to create and manage the TLS certificates for the FTM offerings. For more information, see Creating FTM Certificates.

Liberty TLS configuration

When you integrate FTM with other systems through Liberty, update Liberty’s TLS configuration to include the required certificates. For example, in the custom LDAP registry XML, the <keyStore> and <trustStore> entries require passwords to access the respective stores. These keystore and truststore files, such as LdapSSLTrustStore.jks, must contain the correct certificates that are needed for secure communication.

Provide the keystore and truststore files by using a persistent volume or a ConfigMap before you deploy FTM. Verify that the password values defined in the Liberty configuration exactly match the passwords that are stored in the corresponding vault or secret. Use keys such as TSTORE_PASSWORD or another defined key to store these passwords securely. Store all Liberty configuration files in a secure location and apply strict access controls to prevent unauthorized access.

Image signature verification key

Red Hat OpenShift supports cluster-wide image signature verification policies. When this policy is enabled, the cluster runs only container images that are signed by trusted keys. If your Red Hat OpenShift security policy requires image signature verification, you must obtain IBM’s public signing certificate for FTM container images and add it to Red Hat OpenShift’s trusted keys. This step is typically performed by creating an image signature config or by using the oc adm signature add command.

Using trusted images is a security best practice and is recommended for all environments. This practice ensures supply-chain integrity by verifying that the FTM images that run in your cluster are authentic and untampered after IBM releases them.

For more information about adding the public key for the signed images, see Add the public key for the signed images for your FTM offering.