❔ Environment variables vs configuration files for storing secrets
A project I am working on started out with very few, very simple (string) secrets and sensitive information - so I stored them as environment variables and accessed them via
IConfiguration and config.AddEnvironmentVariables("FOO_"); in my host builder. However, as the project has grown in size, the number and type of secrets has grown too, and some of them are too complex to store as the simple Key:Value format environment variables entail. At the moment, I have my original simple string secrets still stored as environment variables, but my more complex configuration and secret data has been tossed into a config.json file which I load and add to my IConfiguration via config.AddJsonFile("config.json");.
Is it dumb to use both like this, or should I just move my string secrets to this config.json file as well? I'm not concerned about leaking secrets in commits or anything, as I have already added this file to my .gitignore for the project, but I'm not extremely keen on best-practices for secrets when it comes to projects. I feel like doing both doesn't really make sense, since the point of the former (to me) was to avoid the latter, but now I have to do the latter, so I might as well put all my eggs in one basket.8 Replies
Looks like nothing has happened here. I will mark this as stale and this post will be archived until there is new activity.
I usually end up injecting confidential configuration through environment variables, but it depends on your hosting model I suppose. How do you currently get your config.json from your local machine (since it's not part of your git) to deployment? Sounds like you deploy by hand right now
Some deployment models (e.g. kubernetes) might also end up injecting your secrets through a configmap as a file on disk, but usually it's environment variables from what I usually use
I guess ultimately it's also not a big issue whether you put all your config in one place or another, since it all ends up in IConfiguration anyways, regardless of the source
What matters is that the secrets end up in your app without any leaks
I don't see anything is wrong with that approach. I sometimes use multiple config json files. You can also grab your environment and do like "AddJsonFile("config.{Environment}.json")"
I don't see an issue with this approach, the big benefit of the config system is that it lets you merge a bunch of different sources at runtime
How do you currently get your config.json from your local machine (since it's not part of your git) to deployment? Sounds like you deploy by hand right nowI currently do deploy by hand, for the most part. I'm currently in the process of learning about containerization and my intent is to deploy my bot over docker via Portainer (and a local container registry). So, for my case, a potential option could be to store my
config.json file on disk and mount that directory, since I will need to do some other binding stuff for logging, data files (images), etc. I heard about docker secrets but it seems they are locked behind running containers in Swarm mode (and honestly seem overkill for a single configuration file per-app, idk)
Upon further review, my config.json doesn't really contain actual sensitive information and secrets, but it DOES contain data structures that would be annoying to represent in an envvar (arrays, specifically). I just thought it was silly to split them up like it, but I guess envvars are fine for what I'm using them for, and splitting isn't so bad.
I just always have this weird thought in the back of my head screaming "NOBODY SHOULD SEE YOUR SECRETS, NOT EVEN YOU" which is why I normally use envvars. I love GitHub Secrets for the fact they are write-once, read-never (outside of an action, I mean), and would love a similar functionality for my containers going forward. But that's a question for a different time, methinksswarm mode doesn't add any overhead, and doesn't force you to do your apps in a particular way
literally just
docker swarm init and now you can use swarm featuresI'll have to do some more looking into things. I'm not really sure why there's a distinction at all if it really is THAT simple(?) - IE, why docker isn't just in swarm mode by default, but that's beyond the scope of my original question. Thanks all
Was this issue resolved? If so, run
/close - otherwise I will mark this as stale and this post will be archived until there is new activity.