为什么ARG在DOCKERFILE中不推荐用于传递秘密？ [英] Why is ARG in a DOCKERFILE not recommended for passing secrets?

问题描述

在 http://docs.docker.com/engine/reference/builder/#arg，它建议秘密不通过ARGS。

注意：不建议使用构建时变量来传递秘密，如github密钥，用户凭据等。

什么时候通过构建时间变量在危险中传递的秘密？

解决方案

更新2015年1月：

Docker（swarm）1.13具有 docker secret 。

但是， commented 由 Steve Hoffman（ bacoboy ）：

[...]秘密命令只帮助群组用户不是一个mo通常的解决方案（如他们附加持久的卷）。

你如何管理你的秘密（他们是谁，谁有权访问它们）是非常依赖系统的，取决于付费和/或OSS你拼凑在一起，使您的平台。

随着Docker公司进入提供平台，我并不感到惊讶的是，他们的第一个实现是基于群集，就像Hashicorp将Vault集成到Atlas - 这是有道理的。

真正的秘密传递落在 docker run 的空间之外。

AWS通过使用角色和策略来授予/拒绝权限加上一个SDK这样的事情。

厨师使用加密的数据库和加密引导到auth。

K8S有自己的版本，刚刚在1.13中发布。

我确定mesos将及时添加类似的实现。

这些实现似乎落入2个阵营。

• 通过平台提供的卷安装传递秘密，或（厨师/码头机密/ k8s


• 通过凭证与外部服务通话在启动时得到东西（iam / credstash / etc）

---

原始答案：2015年11月

这是在 commit 54240f8 （docker 1.9，2015年11月），来自 PR 15182 ，

构建环境是为了帮助高速缓存查找而添加到中间执行器的命令字符串中。

它也有助于构建可追溯性。但是这也使得从传递构建时间秘密的角度来看，这个功能不太安全。

issue 13490 重申：

构建环境变量：构建时环境变量不是用来处理秘密的。由于缺乏其他选择，人们正在计划将其用于此。为了防止给人一种适合秘密的印象，决定在这个过程中故意不加密这些变量。

如上所述在 9176 评论：

env变量是错误的方式传递秘密。我们不应该试图重新发明轮子，并提供一个破坏性的安全分发机制，开箱即用。

当您将密钥存储在环境中时，您是容易意外暴露他们 - 正是我们想要避免的：

• 鉴于环境是隐式可用的，这是非常困难的如果不是不可能，跟踪访问以及内容的暴露方式


• 应用程序抓住整个环境并将其打印出来是非常常见的，因为它可以用于调试，甚至是有用的作为错误报告的一部分发送。许多秘密泄露给PagerDuty，他们有一个很好的内部流程来从他们的基础设施中进行刷新。


• 环境变量被传递给子进程，这允许非预期的访问和中断最低特权原则想象一下，作为您的应用程序的一部分，您可以致电第三方工具执行某些操作，突然之间，第三方工具就可以访问您的环境，而上帝知道它将如何处理。


• 对日志文件中存储环境变量的应用程序进行以后调试是非常常见的。这意味着在磁盘上的纯文本中的秘密。


• 将env变量中的秘密快速变成部落知识。新工程师不知道他们在那里，并且不知道处理环境变量时应该小心（过滤到子进程等）。

$总而言之，env变量的秘密破坏了最不惊奇的原则，是一种不好的做法，并将导致最终泄露秘密。

In http://docs.docker.com/engine/reference/builder/#arg , It recommendeds secrets are not passed through ARGS.

Note: It is not recommended to use build-time variables for passing secrets like github keys, user credentials etc.

At what point are secrets passed through build-time variables in danger?

解决方案

Update January 2017:

Docker (swarm) 1.13 has docker secret.

However, as commented by Steve Hoffman (bacoboy):

[...]The secret command only helps swarm users is not a more general solution (like they did with attaching persistent volumes).
How you manage your secrets (what they are and who has access to them) is very system dependent and depends on which bits of paid and/or OSS you cobble together to make your "platform".
With Docker the company moving into providing a platform, I'm not surprised that their first implementation is swarm based just as Hashicorp is integrating Vault into Atlas -- it makes sense.

Really how the secrets are passed falls outside the space of docker run.
AWS does this kind of thing with roles and policies to grant/deny permissions plus an SDK.
Chef does it using encrypted databags and crypto "bootstrapping" to auth.
K8S has their own version of what just got released in 1.13.
I'm sure mesos will add a similar implementation in time.

These implementations seem to fall into 2 camps.

• pass the secret via volume mount that the "platform" provides or (chef/docker secret/k8s
• pass credentials to talk to an external service to get things at boot (iam/credstash/etc)

---

Original answer: Nov. 2015

This was introduced in commit 54240f8 (docker 1.9, Nov 2015), from PR 15182,

The build environment is prepended to the intermediate continer's command string for aiding cache lookups.
It also helps with build traceability. But this also makes the feature less secure from point of view of passing build time secrets.

issue 13490 reiterates:

Build-time environment variables: The build-time environment variables were not designed to handle secrets. By lack of other options, people are planning to use them for this. To prevent giving the impression that they are suitable for secrets, it's been decided to deliberately not encrypt those variables in the process.

As mentioned in 9176 comments:

env variables are the wrong way to pass secrets around. We shouldn't be trying to reinvent the wheel and provide a crippled security distribution mechanism right out of the box.

When you store your secret keys in the environment, you are prone to accidentally expose them -- exactly what we want to avoid:

• Given that the environment is implicitly available to the process, it's incredibly hard, if not impossible, to track access and how the contents get exposed
• It is incredibly common having applications grabbing the whole environment and print it out, since it can be useful for debugging, or even send it as part of an error report. So many secrets get leaked to PagerDuty that they have a well-greased internal process to scrub them from their infrastructure.
• Environment variables are passed down to child processes, which allows unintended access and breaks the principle of least privilege. Imagine that as part of your application you call to third-party tool to perform some action, all of a sudden that third-party tool has access to your environment, and god knows what it will do with it.
• It is very common for applications that crash to store the environment variables in log-files for later debugging. This means secrets in plain-text on disk.
• Putting secrets in env variables quickly turns into tribal knowledge. New engineers don't know they are there, and are not aware they should be careful when handling environment variables (filtering them to sub-processes, etc).

Overall, secrets in env variables break the principle of least surprise, are a bad practice and will lead to the eventual leak of secrets.

这篇关于为什么ARG在DOCKERFILE中不推荐用于传递秘密？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！