Reading config files (mostly secrets) from outside appsettings and env vars - bad idea?
Looking for best practices / existing features to avoid reinventing the wheel (more than we have).
Our app gets deployed into k8s pods and the team handling the deployment wants to use k8s secrets for secrets configuration (think GCP service_account.json, connection strings & keys for DB, blob storage, etc.).
We've acquiesced so far by allowing specific filenames that we then read from
/run/secrets/ as an alternative to just putting an appsettings.json into the same dir. So, for instance, we look for a service_account.json, a sqlserver_connection_string file containing the conn string, and a few more.
This means we've written some loaders which look for these files, load them into objects by searching through the dirs and falling back on appsettings.json, run fluentValidation, and then can be called to get the instance of the config which has been loaded into the app.
I'm not sure if this is the best idea, though.
If it were up to me, I'd prefer to strictly stick to appsettings.json, reading env variables, and reading (non-secret) values from the DB. I'd accomplish this by either requiring they store their own appsettings file in /run/secrets/ or loading env variables from the same, or even implementing something like S6 Overlay in our container, which handles setting env variables from files.
Has anyone run into this sort of request or implemented something similar before (in a business or large FOSS app) and have any suggestions - do we allow it and keep rolling our own loader for it, or should we shut down this as an anti-pattern which could cause undue headaches in the future?
Thanks!6 Replies
@noah use some sort of vault.
Don't vaults still require some form of authorization to access them? If yes you're pushing the problem somewhere else
Hoping to avoid adding extra dependencies as well. I don't have control over the decisions the deploying team is making, including telling them to use new technologies. Moreso looking for either:
- a more standardized way to load secrets from non-appsettings files
- to be told "just use appsettings and env vars",
- or to hear that I'm not alone in solving it the way we have (just using a custom file reader and then mapping to our config classes outside of standard config loaders) and that everything will be okay 🙂
Microsoft.Extensions.Configuration.KeyPerFile 8.0.6
Configuration provider that uses files in a directory for Microsoft.Extensions.Configuration.
This package was built from the source code at https://github.com/dotnet/aspnetcore/tree/b8139c5ee58f1708b0e3368a1b241400edd6cbc4
There are certain services such as managed identity which
azure provides. Basically, you specify which of your other app services can access certain resources such as the vault. The only thing you show in the appsettings.json is the vault-url and azure will automatically check if a certain resource has the correct authorization requirements to access the vault.I agree that in a different scenario that’s a good and even preferred option. And thanks jcotton, that’s a nice onei haven’t seen!