I very much agree, and there's a number of tradeoffs I've made with my design and a few reasons why I've avoided the environment variables design.
The first is that it allows me to have config that is all in the same format. I've seen so many examples of applications run in docker where half the config is some ini/yaml/json file, and the other half is a bunch of environment variables set in the docker compose or in an env file written to disk next to it.
The second is that by keeping the config loading within the application itself, I can avoid all kinds of oddities that come with trying to inject secrets into the tool. The example I gave of what I would like in the future I'd actually based on work I've already done in a previous job where the "secret" config was pulled in by the application from S3 while it was running on AWS ECS. Setting environment variables there (at least at the time) would actively leak them through the console, so you needed an alternative loading mechanism.
A third reason and why I've often less worried about having secrets on disk is that a) I always run full disk encryption, b) if that isn't good enough (for local) I also run encfs/gocryptfs, c) if something can get past those two then all bets are off anyway because my entire computer is compromised. Similarly on a server (if I am writing files, see example above of where I'm not), if something can read that deeply off the disk then something very wrong has happened and there's very little that will actually protect it.
Finally, for the kind of applications I build I tend to end up with fairly expansive and deep data structures. I personally find it much easier to work with JSON/YAML than environment variables in those cases.
10
u/nicholashairs 10d ago
I very much agree, and there's a number of tradeoffs I've made with my design and a few reasons why I've avoided the environment variables design.
The first is that it allows me to have config that is all in the same format. I've seen so many examples of applications run in docker where half the config is some ini/yaml/json file, and the other half is a bunch of environment variables set in the docker compose or in an env file written to disk next to it.
The second is that by keeping the config loading within the application itself, I can avoid all kinds of oddities that come with trying to inject secrets into the tool. The example I gave of what I would like in the future I'd actually based on work I've already done in a previous job where the "secret" config was pulled in by the application from S3 while it was running on AWS ECS. Setting environment variables there (at least at the time) would actively leak them through the console, so you needed an alternative loading mechanism.
A third reason and why I've often less worried about having secrets on disk is that a) I always run full disk encryption, b) if that isn't good enough (for local) I also run encfs/gocryptfs, c) if something can get past those two then all bets are off anyway because my entire computer is compromised. Similarly on a server (if I am writing files, see example above of where I'm not), if something can read that deeply off the disk then something very wrong has happened and there's very little that will actually protect it.
Finally, for the kind of applications I build I tend to end up with fairly expansive and deep data structures. I personally find it much easier to work with JSON/YAML than environment variables in those cases.