
12 factor app configuration vs. leaking environment variables (2014) - cimnine
https://gist.github.com/telent/9742059
======
cimnine
For me, there are two compelling points in this:

    
    
      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?

------
cyberpanther
One of the organizational problems I've seen with ENVs are when there are too
many of them. When someone starts up a new environment for staging or
production, they just copy all the ENVs from another environment and don't
bother going through each one to see if it is valid or safe to copy. So you
end up with a testing environment that can send real money. What fun! Been
there!

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.

