我的方法似乎有效，但可能有些幼稚。告诉我为什么这是错的。

在docker构建过程中设置的arg是由history子命令公开的，所以不要去那里。但是，在运行容器时，run命令中给出的环境变量对容器是可用的，但不是映像的一部分。

因此，在Dockerfile中，执行不涉及秘密数据的设置。设置一个类似于/root/finish.sh的CMD。在run命令中，使用环境变量将秘密数据发送到容器中。sh使用这些变量来完成构建任务。

为了更容易地管理秘密数据，将其放入一个文件中，由docker使用——env-file开关加载。当然，要保密。gitignore之类的。

对我来说，finish.sh运行一个Python程序。它检查以确保之前没有运行过，然后完成设置(例如，将数据库名称复制到Django的settings.py中)。

仅运行时解决方案

Docker-compose还提供了一个非群模式的解决方案(自v1.11起: 秘密使用绑定安装)。

这些秘密被docker-compose挂载为/run/secrets/下面的文件。这可以在运行时(运行容器)解决问题，但不能在构建时(构建映像)解决问题，因为/run/secrets/在构建时没有被挂载。此外，此行为依赖于使用docker-compose运行容器。

例子:

Dockerfile

FROM alpine
CMD cat /run/secrets/password

docker-compose.yml

version: '3.1'
services:
  app:
    build: .
    secrets:
      - password

secrets:
  password:
    file: password.txt

要构建，执行:

docker-compose up -d

进一步阅读:

mikesir87的博客-在开发过程中使用Docker秘密

Docker现在(版本1.13或17.06或更高)支持管理秘密信息。下面是概述和更详细的文档

kubernetes和DCOS也存在类似的特征

While I totally agree there is no simple solution. There continues to be a single point of failure. Either the dockerfile, etcd, and so on. Apcera has a plan that looks like sidekick - dual authentication. In other words two container cannot talk unless there is a Apcera configuration rule. In their demo the uid/pwd was in the clear and could not be reused until the admin configured the linkage. For this to work, however, it probably meant patching Docker or at least the network plugin (if there is such a thing).

永远不要向容器添加凭据，除非您可以将凭据广播给任何可以下载映像的人。特别是，执行并添加creds并随后运行rm creds是不安全的，因为creds文件仍然保存在中间文件系统层的最终映像中。任何能接触到图像的人都能很容易地提取出来。

The typical solution I've seen when you need creds to checkout dependencies and such is to use one container to build another. I.e., typically you have some build environment in your base container and you need to invoke that to build your app container. So the simple solution is to add your app source and then RUN the build commands. This is insecure if you need creds in that RUN. Instead what you do is put your source into a local directory, run (as in docker run) the container to perform the build step with the local source directory mounted as volume and the creds either injected or mounted as another volume. Once the build step is complete you build your final container by simply ADDing the local source directory which now contains the built artifacts.

我希望Docker添加一些功能来简化这一切!

Update: looks like the method going forward will be to have nested builds. In short, the dockerfile would describe a first container that is used to build the run-time environment and then a second nested container build that can assemble all the pieces into the final container. This way the build-time stuff isn't in the second container. This of a Java app where you need the JDK for building the app but only the JRE for running it. There are a number of proposals being discussed, best to start from https://github.com/docker/docker/issues/7115 and follow some of the links for alternate proposals.

12因素应用程序方法告诉我们，任何配置都应该存储在环境变量中。

Docker compose可以在配置中进行变量替换，因此可以用来将密码从主机传递到Docker。