I started a thread over here not so long ago, and got no bites at all.
Not sure if that was because this is not on anyone’s radar or its something no one encounters, or cares about, or perhaps there are already well-known solution that are deployed to resolve? hard to tell.
In the meantime, we embarked on resolving our problems in this area and it turns out we have a rather elegant solution for resolving this problem that could be a general mechanism for any ServiceStack deployment.
Now that we have that deployed live, I just wanted to circle back here and see if there is any appetite or interest from this community for us to share a general solution that others could use to solve this problem themselves. Perhaps as an extension to the core ServiceStack framework, or as a new plugin.
Without getting in the weeds at this stage about how it all works under the covers, would there be any interest in this community in a solution that allows you to extend AppSettings, to read secrets in your config files from a secure store (e.g. Azure Key Vault, Amazon KMS or Vault, or your own custom store/service etc) with minimal setup, no extra coding (just add a plugin to your AppHost) and without disrupting local development flows?
I’m sure some people will find it useful if a seamless drop-in solution exists, I just don’t think it’s an area with a lot of interest as it adds configuration complexity/overhead without direct tangible benefits.
For a Docker deployments we embed our connection strings in Environment variables in the generated Docker images that is in addition protected by firewall rules to limit access to our RDBMS’s to our App Servers which works well for us, so we don’t see the need to store it in a cloud key storage ourselves. But it might be useful for Customers who have a requirement where they must use a Cloud Key Provider.
I think there might be use cases for: developers who discover that they have secrets defined in their existing configurations files (retrospectively) and now need to get them out of there. Or, when a developer needs to define a secret in their configuration (prospectively), but can’t/shouldn’t: i.e. in open-sourced projects.
In these cases, which I would guess are going to be quite common, especially as solutions/products mature, they are going to be looking for drop-in solutions to easily get the secrets out of their configuration, without getting overwhelmed with having to take on new configuration technologies and additional security processes that will certainly slow things down with what they are used to.
However, would be good to hear from the community on whether there is value here or not.
