noah
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!7 replies