为什么不建议将 DOCKERFILE 中的 ARG 用于传递秘密? [英] Why is ARG in a DOCKERFILE not recommended for passing secrets?
问题描述
在 http://docs.docker.com/engine/reference/builder/#arg , 建议不要通过 ARGS 传递秘密.
In http://docs.docker.com/engine/reference/builder/#arg , It recommendeds secrets are not passed through ARGS.
注意:不建议使用构建时变量来传递 github 密钥、用户凭据等秘密.
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?
推荐答案
2018 年 8 月更新:
Update August 2018:
您现在拥有 docker build --secret id=mysecret,src=/secret/file.
请参阅在 Docker 中使用构建时参数的安全方法".
You now have docker build --secret id=mysecret,src=/secret/file.
See "safe way to use build-time argument in Docker".
2017 年 1 月更新:
Update January 2017:
Docker (swarm) 1.13 具有 docker secret.
Docker (swarm) 1.13 has docker secret.
但是，正如 评论 由 史蒂夫霍夫曼 (bacoboy):
However, as commented by Steve Hoffman (bacoboy):
[...]secret 命令仅帮助 swarm 用户不是更通用的解决方案(就像他们在附加持久卷时所做的那样).
您如何管理您的秘密(它们是什么以及谁可以访问它们)非常依赖于系统，并且取决于您拼凑哪些付费和/或 OSS 来构建您的平台".
随着 Docker 公司开始提供平台，我并不惊讶他们的第一个实现是基于 swarm 的，就像 Hashicorp 将 Vault 集成到 Atlas 中一样——这是有道理的.
[...]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.
真正传递秘密的方式超出了 docker run 的空间.
AWS 使用角色和策略来授予/拒绝权限以及开发工具包来执行此类操作.
Chef 使用加密的数据包和加密引导"进行身份验证.
K8S 有自己的 1.13 版本.
我相信 mesos 会及时添加类似的实现.
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.
- 通过平台"提供的卷挂载或(chef/docker secret/k8s)传递秘密
- 传递凭据以与外部服务通信以在启动时获取信息 (iam/credstash/etc)
<小时>
原始答案:2015 年 11 月
Original answer: Nov. 2015
这是在 commit 54240f8(docker 1.9，2015 年 11 月)中引入的，来自 PR 15182,
This was introduced in commit 54240f8 (docker 1.9, Nov 2015), from PR 15182,
构建环境被添加到中间 continer 的命令字符串之前，以帮助进行缓存查找.
它还有助于建立可追溯性.但是，从传递构建时间机密的角度来看，这也会降低该功能的安全性.
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.
问题 13490 重申:
构建时环境变量:构建时环境变量不是为处理机密而设计的.由于缺乏其他选择，人们正计划为此使用它们.为了防止给人以它们适合秘密的印象，我们决定在此过程中故意不对这些变量进行加密.
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.
env 变量是传递秘密的错误方式.我们不应该试图重新发明轮子并提供开箱即用的残缺安全分发机制.
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:
- 鉴于环境对进程是隐式可用的，因此很难(即使不是不可能)跟踪访问以及内容是如何暴露的
- 让应用程序抓取整个环境并将其打印出来是非常常见的，因为它可以用于调试，甚至可以将其作为错误报告的一部分发送.如此多的秘密被泄露给 PagerDuty，以至于他们有一个很好的内部流程来清除他们的基础设施.
- 环境变量被传递给子进程，这允许意外访问并打破最小权限原则.想象一下，作为应用程序的一部分，您调用第三方工具来执行某些操作，突然间，第三方工具可以访问您的环境，天知道它会用它做什么.
- 崩溃的应用程序将环境变量存储在日志文件中以供以后调试是很常见的.这意味着磁盘上的纯文本机密.
- 将秘密放入环境变量中很快就会变成部落知识.新工程师不知道他们在那里，也不知道他们在处理环境变量时应该小心(将它们过滤到子流程等).
总体而言，环境变量中的秘密违反了最小意外原则，是一种不好的做法，最终会导致秘密泄露.
Overall, secrets in env variables break the principle of least surprise, are a bad practice and will lead to the eventual leak of secrets.
这篇关于为什么不建议将 DOCKERFILE 中的 ARG 用于传递秘密?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
