I have an ASP Dotnet Core Web API that I have created that needs to connect to a SQL database. I have a Test, Staging, and Production environment that I want to be able to deploy to and have a different connection string for each environment. What is the best way to handle secrets in Habitat without having to rebuild the plan for each environment. I want to build the hart file once, but be able to apply the secret for those environments. For the time being, this hart file will be running on a Linux VM, but we are building out a Kubernetes cluster that I could end up running on in the future. Here are the options I have been exploring and struggling with.
- Origin Secrets (Only available during build time as environment variables)
- Azure Key Vault with Non-Prod and Production Certificate (When and how do I swap out certificates for the different environments)
- User.toml, but these don’t keep the connection string secret
- core/Vault, (I don’t know enough about this option but realized @Defilan is the maintainer, so I will dig here more)
The only one I have been able to get working is the Azure Key Vault, but that stored the non-prod certificate in the package. I am open to any thoughts and suggestions as I continue to dig around and figure this out. I have read the Consuming Secrets in Habitat post already. I am wondering if anything new has come to light since then.