Secure Deployment and Configuration

Security must be considered before deploying FTM on Red Hat® OpenShift®, especially in production environments. This section covers preparatory steps and runtime configuration choices that harden the deployment.

Pre-Deployment checklist

Before you install the FTM operators and create the FTM instance, complete all necessary security setup:
Create required secrets
Ensure that all required secrets are created in the namespace. This includes the OIDC client secret, the main ftm-application-secret (containing Db2® credentials, IBM® MQ credentials, default user passwords), and any other integration secrets. For more information about creating FTM application secret on Red Hat OpenShift, see Create an application secret for your FTM installation on Red Hat OpenShift.
Prepare certificates and keys
Generate the TLS certificates needed for FTM’s use. Decide whether to use a certificate signed by your organization’s certificate authority (CA) or a self-signed cert for the FTM UI endpoint. Create the keystore and truststore secrets. If image signature verification is used, obtain IBM's signing public key and configure it in the cluster before deploying FTM images. For more information about creating certificates, see Create certificates.
Plan storage security
Ensure that persistent volumes are on secure storage classes. This may include encrypted storage or at least setting appropriate access modes and permissions. For example, if using Portworx or another container storage for FTM, configure it such that the data is replicated and encrypted if required by your organization’s policy.
Understand required network access
Identify the endpoints that FTM components must access so that you can define appropriate network policies in advance.

Network policies

On Red Hat OpenShift, by default, pods can communicate freely within the cluster. To enable Financial Transaction Manager (FTM) to connect to external servers, such as IBM MQ or Db2 outside the cluster, you must create egress rules. By default, FTM implements network policies that block egress communication to protect critical and confidential applications.

The FTM operator does not configure any default egress rules. All required egress rules must be defined in the custom resource (CR) during instance creation and can be updated as needed. The sample CR provided includes example rules only. If egress rules are not configured in the CR, external connections are blocked.

Egress rules must be reapplied with each FTM deployment. To avoid repeated configuration, you can define and manage your own network policy. After applying policies, test that all components still function. This isolates FTM from any unexpected connections and significantly reduces the attack surface at the network level.

For more information about configuring rules for egress access, see Configuring the rules for egress access.

Pod Security and Hardening

Follow these guidelines to ensure that FTM containers run with the least privileges required:
  • The IBM FTM containers do not require root privileges. They can run as non-root users. Verify this by checking the SecurityContext settings in the pod specifications.
  • Avoid running pods as root unless necessary.
  • Use a dedicated ServiceAccount for FTM deployments. Do not run under the default service account.
  • Limit that ServiceAccount's permissions by using Roles and RoleBindings. This prevents a compromised pod from having broad cluster access.

Configuration Hardening

Use configuration settings that prioritize security over convenience. Follow these best practices:
Avoid storing secrets in plain text
Do not store secrets as plain text in the CR YAML or ConfigMaps. Instead, use secret references. The CR supports valueFrom.secretKeyRef for most sensitive fields. This prevents secrets from being exposed in Git or visible in the Red Hat OpenShift console to users with access to the CR.
Rotate default tokens or keys
For example, FTM has an internal webServer token (spec.config.webServer.token) used by internal services. The operator may generate a default value, but you should replace it with a secure, randomly generated token. Store this value in a secret so it can be rotated as needed.
Change default passwords
Replace any autogenerated credentials with your own strong passwords. Use a dedicated secrets manager to manage credentials securely and reduce the risk of exposure.