12 factor app configuration vs. leaking environment variables (2014)
gist.github.com
gist.github.com
1) Environment variables are 'exported by default', making it easy to do silly things like sending database passwords to Airbrake. Sure we could introduce code to filter them out, but it's another thing we need to remember to update every time we add one - not robust in the face of code changes. Better not to put them there in the first place
and 4) if you restart an app by sending it a signal (e.g. SIGHUP) from an unrelated shell that causes it to re-exec itself, it will still have the environment of the original process. So for example, you can't update config in environment variables and do a Unicorn "zero downtime" restart. This can cause confusion
While the restart/reload problem can be circumvented using multiple instances, the leaking problem can't be easily solved in a generic way.That's why I would suggest not to put secrets into environment variables. Systems like Kubernetes or Docker Swarm have great support for such kind of secrets. Is there someone who researched this concern in more depth?
This can happen with configuration in code too but at least it gets checked in and there is usually a better review process.
So I usually go for a hybrid approach. Have most configurations committed and tracked in code in different files, one for development, production, etc. This makes it really clear which configurations are more important. Any configurations that can't be committed to code, use ENVs or a secure key store if you can handle the extra process complexity.
This approach can still have holes but at least the surface area is reduced.