Secrets in Configuration

1

This might be a touch off-topic technically, but I think its relevant to building great services.

I am looking around for great solutions for helping store configuration, that includes better protection for secrets, and can easily be integrated into development/production flows, that also meets these goals:

  1. Services load their configuration settings through a single interface (i.e. IAppSettings) when they start, and even cache settings for a period of time.
  2. Some of these configuration settings can come from files in source code. (for example: Web.Config)
  3. Some of these configuration settings (i.e. connectionstrings, passwords, apikeys etc) need to come from a secure storage/vault, but must be aggregated through same IAppSettings interface. A hierarchy of stores might be searched, for settings for example.
  4. In desktop development, the configuration can come from a local offline source (i.e. filesystem, library, or simple stubbed service that can be started in testing) and the configuration settings and secrets can be stored in source control (assuming that these secrets will never compromise real production secrets - i.e. just used in testing).
  5. When deployed, the configuration settings can come from static files, but the secrets must come from a secure online source (i.e. Azure Key Vault, etc), that a developer would not generally have access to, nor accidentally access.

We want to try to minimize any out-of-band configuration for desktop development, to make local development and testing straightforward, so favor configuration and secrets stored in files and source control for local dev and test. To get developers up and running quickly.

In ServiceStack, we have IAppSettings of course, and we can engineer anything we want, but what are the common solutions and solutions out there that can be integrated into ServiceStack for this, that meet these basic requirements?

2

As a first step we have started down this track:

  1. We created our own IAppSettings implementation for our runtime environment (which happens to be Azure Cloud Services) where the configuration for a service is contained within ServiceConfiguration.<environment>.cscfg files. (similar to a web.config file). (the out of the box AppSettings never worked for us anyhow.)
  2. Now if the value of the keypair is $secret$ we simply delegate to another implementation of IAppSettings that connects to Azure Key Vault to look for a secret with the same name as the keypair. If it finds one, it returns the secret value.
  3. In development, our secrets will be stored in test Azure Key Vault also, so we just have different configuration for the different vaults.
  4. In production, our secrets will be stored in production Azure Key Vault, so we have a different config for that, which devs have no access to.
  5. We have integration tests, that enumerate over the various setting keys found in the config files and ensure the ones that are $secret$ are defined in Azure Kay Vault, to mitigate the issue of devs forgetting to update the Key Vault for Production.

Developers need to do things no different than before, except that they need online access (to Azure) to test at the moment, but will resolve that with local secret store shortly.

Its a good start we think, but still curious to see what others are doing in this space.

3

We are not on azure, but with .Net Core
I’m working to follow this technique:

That I found thru this link:

If you have other technique to share don’t hesitate…