Security Best Practices and Compliance
Maintain operational best practices to keep the deployment secure and compliant over time.
Principle of Least Privilege (PoLP)
Apply the principle of least privilege at all levels to minimize security risks. Follow these
best practices to enforce PoLP:
- Assign only the minimum required privileges to users for FTM application roles.
- Restrict the permissions of Kubernetes service accounts and users. Grant the team deploying or managing FTM only the namespace-level rights required.
- Use Red Hat® OpenShift® project quotas and restrictions to prevent abuse.
- Create dedicated service accounts with limited rights for FTM in external systems, such as Db2® and IBM® MQ.
- Secure encryption keys and secrets. Do not allow all administrators to access Vault tokens or Kubernetes secrets. Limit access to a small subset of authorized security personnel.
- Review access permissions of data and systems regularly and revoke access when they are no longer required.
Secure OIDC clients
Follow these best practices to secure OIDC clients and control access to FTMControl Center:
- Restrict redirect URIs, validate token issuers
(iss)and audiences(aud), and use only trusted identity providers IdPs. - Use short-lived ID tokens.
- Restrict access to secrets to ensure that only the application and necessary users or service accounts can read them.
- Validate and configure token expiration settings at the OIDC provider level.
- Monitor OIDC authentication failures and anomalies.
Regular secret rotation
Follow these best practices to rotate sensitive credentials and maintain secure operations:
- Rotate all sensitive credentials on a schedule. This includes database passwords, IBM MQ passwords, OIDC client secrets, keystore passwords, and TLS certificates or keys.
- Use an external secrets vault to facilitate automatic rotation if dynamic secrets are used. If automatic rotation is not available, plan manual rotations, update Kubernetes secrets, and restart pods to apply changes.
- Always follow change management procedures and validate after rotations.
Patch Management
Follow these best practices to keep FTM and its components secure and up
to date:
- Keep FTM and its components up to date. IBM periodically releases interim fixes.
- Apply interim fixes when feasible after testing, as they often include security updates.
- Ensure that all supporting components such as Red Hat OpenShift, Db2, IBM MQ, the operating system, and other deployment layers are also regularly patched.
- Patch all layers in the environment regularly, including the application, middleware, base OS, and container platform.
Use external vault or Secret Manager
Follow these best practices to securely manage secrets for FTM:
- Integrate with a robust secret management solution, such as Vault, to manage FTM secrets securely. Use Vault integration to dynamically pull secrets and avoid storing them long term in the cluster. Use Vault features like lease and revoke to automatically rotate credentials regularly.
- If Vault is not used, enable
etcdencryption and configure strict RBAC when using Kubernetes secrets. - Avoid hardcoding passwords or keys in code, Docker images, or
ConfigMaps.
Periodic security reviews and testing
Follow these best practices to maintain a security posture and validate your FTM deployment against vulnerabilities:
- Review the FTM CR and Liberty configs periodically to ensure alignment with security best practices.
- Develop a threat model for your deployment to analyze the attack surface and identify unmitigated vulnerabilities.
- Perform vulnerability scans on the FTM container images to detect known vulnerabilities.
- Conduct periodic penetration tests to identify misconfigurations and unknown vulnerabilities in the deployment.