Skip to Main Content
Integration


This is an IBM Automation portal for Integration products. 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 Future consideration
Workspace API Connect
Created by Guest
Created on May 31, 2024

Provide missing functionality to automate replacement of TLS certificates for the internal gateway using GitOps CRD

Currently you have to manually create a new keystore in order to assign that to a manually created new TLS server profile which can then be manually assigned to the existing service endpoint. This steps could be automated through administration REST API in order to be included within some jobs within the GitOps automation.

From my point of view it would be even better to have Custom Resource Definition CRD that are able to reference to existing Secrets of the OpenShift itself.

Idea priority High
  • Guest
    Reply
    |
    Jun 3, 2024

    We definitely need this automation. Please put this on priority list.

  • Guest
    Reply
    |
    May 31, 2024

    Automating the process of creating and managing keystores in Red Hat OpenShift can significantly enhance security, streamline deployment workflows, and improve overall efficiency. Let’s delve into the reasons why this feature is important:

    Security Enhancement:

    • Keystores play a crucial role in securing communication between services. By automating their creation and management, you ensure consistent security practices across your applications.
    • Manually creating keystores introduces room for error, such as misconfigurations or incorrect certificate entries. Automation reduces the risk of such mistakes.
    • With automation, you can enforce best practices, like using strong encryption algorithms and regularly rotating certificates.

    Efficiency and Consistency:

    • Manual processes are time-consuming and error-prone. Automating keystore creation and assignment saves valuable time for developers and administrators.
    • Consistent deployment practices are essential for maintaining a healthy and reliable system. Automation ensures that every service follows the same security protocols.

    GitOps and CI/CD Integration:

    • GitOps relies on declarative configurations stored in version-controlled repositories. Automating keystore management aligns with GitOps principles by treating infrastructure as code.
    • Integrating keystore automation into CI/CD pipelines ensures that security configurations are part of the deployment process. This consistency prevents drift between development, staging, and production environments.

    Custom Resource Definitions (CRDs):

    • CRDs allow you to extend Kubernetes and OpenShift with custom resources. By defining a CRD for keystores, you can create and manage them declaratively.
    • A CRD could reference existing Secrets within OpenShift, simplifying the process. For example, a keystore CRD might specify a Secret containing the necessary certificates and keys.
    • This approach abstracts the complexity of keystore management, making it easier for developers to focus on application logic.

    In summary, automating keystore creation and assignment not only enhances security but also aligns with modern deployment practices. Custom Resource Definitions can further simplify the process by allowing developers to work with familiar abstractions. Implementing this feature would be a valuable addition to OpenShift’s capabilities