Hardening security configurations

Engineering Lifecycle Management on Hybrid Cloud implements several security measures that are ready for use, enhancing the security of containers where Engineering Lifecycle Management applications operate.

Cluster security settings

Customer Responsibilities
The product does not manage cluster-level network security configurations. It is the customer's responsibility to define, implement, and manage egress and ingress network policies for pods and containers that run in Kubernetes or Red Hat OpenShift clusters. However it includes, but is not limited to
  • Restricting ingress and egress traffic to trusted namespaces or pods
  • Configuration of namespace isolation
  • Configuration of firewall rules and cloud provider security groups
  • Ensure compliance with organizational security standards
Security Best Practices
Security control depends on the capabilities and configurations that are provided by the underlying cloud provider or infrastructure platform. Customers must ensure that cluster networking, firewall settings, load balancer exposure, and related controls are properly configured in their environment. Following are the best practices to be followed
  1. Implementation of Default-Deny Network policies: Start with a default-deny policy for the ELM namespace and, then selectively allow only required traffic.
  2. Following Principle of Least Privilege: Allow communication only for explicitly required services to minimize security risk.
  3. Performing Regular Security Audits: Periodically review and update network policies.
Additional resources
For more information on setting up network policies in Kubernetes and Red Hat OpenShift environments, see

Application security settings

The following security features are supported by default.
  • The HTTP Strict-Transport-Security (HSTS) header is set.
  • The X-Powered-By header is disabled.
  • The uncommon $wsep header is disabled.
  • The Host header validation is enabled. The following Java™ properties are added to all Engineering Lifecycle Management application's web server (Liberty) configurations.
    • JAVA_OPTS="$JAVA_OPTS -Dcom.ibm.team.repository.servlet.disableHostHeaderValidation=false"
    • Dcom.ibm.team.repository.servlet.disableHostHeaderValidation=false -Dcom.ibm.team.repository.servlet.extraValidHostNames=ibm-elm-ccm,ibm-elm-jts,ibm-elm-dcc,ibm-elm-qm,ibm-elm-rm,ibm-elm-gc,ibm-elm-jas,ibm-elm-rb,ibm-elm-,ibm-elm-lqe,ibm-elm-eni

      This property allows the Engineering Lifecycle Management applications and supporting tools in containers to communicate with each other by using Kubernetes services for routing, which is quicker as it does not require traffic to break out of the local network. See also the Engineering Lifecycle Management URL Aliases advanced property where the service names are listed.

  • Enhanced admin security is enabled so that non admin users cannot view the Engineering Lifecycle Management server configurations.
  • User authentication is mandatory for the setup wizard so that a user cannot view the sensitive information that is used during setup without logging in.
  • Following are the security settings to be enabled during the installation
    • The Minimum Size and Maximum Size of the Liberty web server connection pool is set to 200. Example <connectionManager minPoolSize="200" maxPoolSize="200" />
    • The attributes cookieSecure and cookieHttpOnly are set to true in the server.xml file of all Engineering Lifecycle Management applications and JAS.
    • <cdi12 enableImplicitBeanArchives="false" /> is added to server.xml file of all Engineering Lifecycle Management applications to optimize the performance.

For more information about the security considerations in IBM® Engineering Lifecycle Management applications, see Security considerations for Engineering Insights.