2018年8月更新：

您现在有了docker build --secret id=mysecret,src=/secret/file 。

2017年1月更新：

Docker（swarm）1.13具有dockersecret。

然而，正如评论由史蒂夫·霍夫曼（bacoboy）：

[…] secret命令只能帮助群集用户，而不是更通用的解决方案（就像他们附加持久卷一样）。
您如何管理您的秘密（它们是什么，谁可以访问它们）在很大程度上取决于系统，并且取决于您拼凑哪些付款和/或OSS来构成“平台”。
随着Docker公司开始提供平台，我并不感到惊讶，因为Hashicorp将Vault集成到Atlas时，他们的第一个实现是基于群体的-这很有意义。

秘密的传递方式真的不在太空的范围内docker run。
AWS通过授予/拒绝权限的角色和策略以及一个SDK来执行此类操作。
Chef使用加密的数据包和加密“引导程序”进行身份验证。
K8S具有自己的版本，该版本刚在1.13中发布。
我确定mesos会及时添加类似的实现。

这些实现似乎分为两个阵营。

• 通过“平台”提供的卷装载传递秘密（或（厨师/码头工人秘密/ k8s
• 传递凭据以与外部服务对话以在启动时进行操作（iam / credstash / etc）
  

原始答案：2015年11月

这是在PR 54182的commit
54240f8（docker
1.9，2015年11月）中引入的，

构建环境位于中间容器的命令字符串之前，以帮助查找缓存。
它还有助于构建可追溯性。但是，从传递构建时间秘密的角度来看，这也使功能不太安全。

第13490期重申：

构建时环境变量
：构建时环境变量并非旨在处理机密信息。由于缺乏其他选择，人们正计划将其用于此目的。为了避免给人以它们适合秘密的印象，已决定在此过程中不对那些变量进行加密。

如9176条
评论中所述：

env变量是传递秘密的错误方法。我们不应该试图重新发明轮子，并立即提供一个严重的安全分发机制。

当您将秘密密钥存储在环境中时，您很容易不小心暴露它们-正是我们想要避免的事情：

• 鉴于该环境对于该过程隐式可用，因此很难（即使不是不可能）跟踪访问以及如何公开内容
  * 让应用程序获取整个环境并打印出来是非常常见的，因为它对于调试非常有用，甚至可以作为错误报告的一部分发送。如此多的机密泄露给PagerDuty，以至于他们拥有一个完善的内部流程来将其从基础结构中清除。
  * 环境变量向下传递给子进程，这允许意外访问并破坏了最小特权原则。想象一下，在您的应用程序中，您调用了第三方工具来执行某些操作，突然之间，第三方工具可以访问您的环境，而上帝知道该怎么做。
• 对于崩溃的应用程序，将环境变量存储在日志文件中以供以后调试是很常见的。这意味着磁盘上的纯文本机密。
• 将秘密放入环境变量中很快就会变成部落知识。新工程师不知道他们在那里，也不知道在处理环境变量（将它们过滤到子流程等）时应该小心。
  

总体而言，env变量中的机密违反了最不令人惊讶的原则，是一种不良做法，并会最终导致机密泄露。