3 ms·
I think that this is right. I also think that storing configuration information in environment variables doesn't scale past a handful of settings. I'm also not
by hoov 13y ago
I think that this is right. I also think that storing configuration information in environment variables doesn't scale past a handful of settings. I'm also not sure that it's the best way of storing secrets. If you're working in a real SOA environment, you may have dozens of external services to talk to, and possibly secrets for each one. At that point, you probably can't use environment variables. And, even if you do -- you'll be managing them in some sort of persistent storage, probably with versioning.
- beat 13y agoAnother advantage of using environment rather than a config file for configuration is not leaving a file full of secrets lying around in your environment. And why is loading your environment so difficult? If I can put foo=bar in a config file, I can put export FOO='bar' in a startup script, and delete the startup script once the application has started.
- ibrahima 13y agoThis is wrong and dangerous. From whom are you trying to keep these variables secret? Assuming a sane sysadmin, sensitive files would only be readable by the user which needs to run the application. And environment variables can be read from the procfs file system by the same user that launched them: http://serverfault.com/questions/66363/environment-variables-of-a-running-process-on-unix http://serverfault.com/questions/66363/environment-variables... Not to mention that if an attacker has shell access to your application user account, you're already owned. So again, who are you trying to hide these variables from? Because it seems like this is just security theater and additional inconvenience (why delete and recreate the file on each deploy?) for literally no benefit.