12 factor app configuration vs. leaking environment variables (2014)

For me, there are two compelling points in this:<p><pre><code> 1) Environment variables are &#x27;exported by default&#x27;, making it easy to do silly things like sending database passwords to Airbrake. Sure we could introduce code to filter them out, but it&#x27;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 </code></pre> and<p><pre><code> 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&#x27;t update config in environment variables and do a Unicorn &quot;zero downtime&quot; restart. This can cause confusion </code></pre> While the restart&#x2F;reload problem can be circumvented using multiple instances, the leaking problem can&#x27;t be easily solved in a generic way.<p>That&#x27;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?

One of the organizational problems I&#x27;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&#x27;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!<p>This can happen with configuration in code too but at least it gets checked in and there is usually a better review process.<p>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&#x27;t be committed to code, use ENVs or a secure key store if you can handle the extra process complexity.<p>This approach can still have holes but at least the surface area is reduced.