不应将ENV变量用于机密数据(2017)

十二要素应用程序宣言建议您将应用程序配置作为ENV变量传递。但是，如果您的应用程序需要密码、SSH私钥、TLS证书或任何其他类型的敏感数据，则不应将其与配置一起传递。

当您将密钥存储在环境变量中时，很容易意外地暴露它们-这正是我们想要避免的。以下是ENV变量不利于保密的几个原因：

由于环境对进程是隐式可用的，因此很难(如果不是不可能)跟踪访问以及内容是如何公开的(PS-EWW<；PID&>T；)。

让应用程序抓取整个环境并将其打印出来以进行调试或报告错误是很常见的。如此多的秘密被泄露给PagerDuty，以至于他们有一个很好的内部流程来将它们从基础设施中清除出去。

环境变量向下传递给子进程，从而允许意外访问。这违反了最低特权的原则。想象一下，作为应用程序的一部分，您调用第三方工具来执行某些操作-突然之间，该第三方工具可以访问您的环境，天知道它将如何处理它。

当应用程序崩溃时，它们通常将环境变量存储在日志文件中以供以后调试。这意味着磁盘上的纯文本机密。

将秘密放入ENV变量很快就会变成部落知识。没有意识到特定环境变量的敏感性质的新工程师将不会适当/谨慎地处理它们(将它们过滤到子流程等)。

总体而言，ENV变量中的机密违反了最小意外原则，是一种糟糕的做法，最终会导致机密泄露。

在以前的工作中，我用一个非常优雅的解决方案帮助解决了这个问题：Keywhiz。在Docker，我们更进一步，直接在Docker中构建了类似的解决方案。如果您正在使用Sroom，那么现在您就有了一种简单的方式来安全地管理您的秘密：

并让您的应用程序从/run/secrets/secure-ret下创建的内存中的TMP中读取机密内容：

通过将秘密集成到Docker中，我们能够提供遵循以下原则的秘密管理解决方案：

拥有一种易于使用、默认安全的秘密分发机制正是开发人员和运营者一劳永逸地解决秘密管理问题所需要的。