search

IBM-Cloud / terraform-provider-ibm

https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs
Mozilla Public License 2.0
341 stars 666 forks source link

Code Engine: Ability to manage secrets and service bindings #4431

Closed saevarb closed 1 year ago

saevarb commented 1 year ago

Hi.

I know that the CE resources aren't released yet, but while I've been awaiting the release I've built the provider locally and started playing around with it while referring to the markdown docs in the repo.

As far I can tell, there is nothing here that lets me create a secret instead of a normal config map, even though run_env_variables's type lets me specify secret_full_reference and the like. I figured it might be possible that the secrets were stored in another service(like the Secrets Manager) and I would need to create them that way, but from looking in my SM instance, there are no references to any of the secrets I've created via Code Engine. Am I missing something?

Another thing I'd also like is the ability to create service bindings. None of the new code engine resources that were added seem to have anything to do with service bindings, but from looking in the provider docs, there are a couple of possibilities, like ibm_service_key, ibm_iam_service_id/ibm_iam_service_api_key and possibly ibm_container_bind_service, but I'm not sure which would be the right ones and what combination allows me to create what amounts to a Code Engine service binding.

hkantare commented 1 year ago

@michael-magrian Can you look into this

michael-magrian commented 1 year ago

Hello @saevarb, your observations are correct. We don't directly support secrets as a Code Engine resource in this upcoming Terraform version. This is a high priority item we are already working on and you can expect it in one of the following releases. As you have also seen we already support a full secret reference in apps and jobs though. This would allow you to reference secrets in an existing project you have configured previously.

Regarding the second topic: This is something we will have to think through thoroughly. It's an important concept that we will work out the details for and provide guidance how to achieve the integration.

Thanks by the way for being so quick to pick up our new service and being eager to provide feedback, much appreciated. If you want I'd be happy to help in the future, you can reach me via email.

saevarb commented 1 year ago

Hi @michael-magrian - thank you for your prompt response.

This is really rather unfortunate because it means the provider is lacking one of the main features we were anticipating. In fact, it would probably have been more useful to us if the provider had only included the ability to manage secrets and config. Do you have a rough timeline for when we could expect support for secret management?

To add some context: We are a small team and we have ~8 services per environment and 3 environments(dev, staging, prod) and managing secrets and config across all the services is easily the most tedious and error prone part of the process. "Error-prone" and "secret managment" are not two things one usually likes to see together in a sentence. The churn of managing all our services in code engine manually means that we have actually been holding out for CE support to be published as part of the provider. We have services we'd like to split up further and more services we would like to add.

After experimenting with the provider, it seems like it would probably just add more churn for us to have some of the resources managed in TF and others manually, while also having to ensure that the terraform files are updated to match what is added manually.

To be completely honest, this decision probably means we'll be looking into transitioning away from Code Engine and IBM Cloud to a more mature platform.

Thank you for your assistance and your time.

michael-magrian commented 1 year ago

Hello again @saevarb,

sorry to hear that. I agree that this is an important feature, which is why delivering secret resource types is on top of our priority list for Terraform. Looking at the brief description of your use case, I still see potential to make your current "error-prone" process easier to maintain, for example use our public API, CLI or our SDKs. My offer stands to help you with onboarding resources into our service and bringing up your environment. If you want we can set something up, just reach out.