Skip to Main Content
IBM Sterling


This portal is to open public enhancement requests for IBM Sterling products and services. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).


Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas
  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.


Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.

ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Status Under review
Created by Guest
Created on Jun 2, 2026

Enhancement Request: Enable GitOps-driven Route Creation with TLS Secrets (Replace oc patch approach from IBM documentation)

Problem Statement


• Attempted to implement a GitOps-based approach by defining OpenShift routes via Helm overlays with the provided sample configuration.

• However, the current behaviour is not aligning with expected GitOps and certificate management patterns.


Observed Issues


• Duplicate Route Creation

○ Routes defined via Helm overlays are getting created in addition to the default routes generated by the Helm chart, resulting in duplication.

• Missing TLS Configuration in Helm-Generated Routes

○ Routes created through the standard Helm GitOps deployment do not include the required TLS certificates, leading to incomplete and insecure configuration.

• No Option to Disable Default Route Creation

○ The Helm chart does not provide a configurable option (via values.yaml) to disable automatic route generation, preventing full control through GitOps.

• Overlay Routes Not Properly Injecting Certificates

○ Routes defined in overlays are not consistently patched with the required TLS certificates, especially when certificates are sourced dynamically from HashiCorp Vault.

• Inconsistent Certificate Propagation

○ Certificate integration from Vault into the route definitions is not being reflected correctly, leading to incomplete TLS setup on the exposed endpoints.

What is your industry? Banking
How will this idea be used?

Route patching must have GitOps Principles

  • Admin
    James Joseph
    Jun 10, 2026

    Thank you for taking the time to share your ideas to IBM. We truly value our relationship with you and appreciate your efforts and willingness to share details about your experience, your recommendations, and ideas. We will soon review the same in the coming weeks and shall get back with a response.
    Thanks,

    James

  • Admin
    James Joseph
    Jun 4, 2026

    To rephrase the request:

    This applies to the patch of routes to configure SSL for ASI and API pods in an Openshift environment. The documented approach is

    Configure SSL for Openshift Route

    If SSL is enabled by setting asi.ingress.ssl.enabled/ ac.ingress.ssl.enabled/ api.ingress.ssl.enabled parameter to true, routes are created with https URL. Also, the routes will be exposed with the cluster's default certificate. However, for production environments it is strongly recommended to obtain a CA certified TLS certificate and update the routes manually as below.

    <Steps Provided with example script that runs oc patch command>

    However, at the customer's organisation; oci is not allowed; hence the oc patch command cannot be run by the application team. They are also not allowed to manually update the routes as Openshift console access is not provided to the application teams. All deployments must be done via gitops (ArgoCD) and through helm charts.

    We've tried creating overlay kustomizations; but were not successful in getting the routes patched correctly.

    Ideally, the enhancement request would be to enable the setting of the above route attributes through values.yaml by pointing to the appropriate Openshift secret that contains the certificate, key and cabundles. This will also reduce the manual steps in the deployment process and streamline the setup of SSL for SFG/B2Bi

    ----------------------------------------

    Best Regards,

    Vivek Mittal