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
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
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.
Hi Ben
CIP-I-321 appears to request a vault to be set up on the fly, by just passing on the credentials to openshift
APPC-I-1025 is for integrating with other vaults.
The last one does seem really usefull (I have now voted for that one as well), but for the first one I see an issue using that in pipelines. Adding the commands with passwords and all the sensitive information plaintext to a repo is not something I am a fan of.
My question is actually just an expansion of the current setup. Currently there is a resource configuration type, Vault type. This one takes a vault as a zip file (zo encrypted credentials ;) ) and injects it inside the container. Which works.
However, with the external vault looking more like the go-to setup for ACE vaults, shouldn't the operator also support a External Vault tupe configuration resource? So that you can simply zip that vault directory from your system and upload that one to openshift? As I understand it, the only real change for the operator would be to change the startup parameter of --vault-key to --external-vault-key.
Developers would then be free to either inject the external vault via configuration resources or a container mount or ... (if they update the override server.conf.yaml obviously)
Hi Matthias,
Thank you for taking the time to raise this idea. We actually have two ideas already in the system which potentially cover this topic.
https://integration-development.ideas.ibm.com/ideas/CIP-I-321
https://integration-development.ideas.ibm.com/ideas/APPC-I-1025
One (CIP-I-321) covers the idea of storing an entire ACE vault as a single configuration object (as opposed to separate credentials which are then "fried" into the container when it is started by the operator). The other (APPC-I-1025) covers the idea of communicating with an external (non IBM) vault technology such as Hashicorp at runtime dynamically or potentially sourcing credentials from there and injecting them into the ACE container's vault when started by the operator.
If we have misunderstood what you are after and you feel there are some unique aspects here then please either record those as comments on one of the above ideas, or raise a new unique idea making it clear what we've missed.
Cheers!