这肯定是一个问题。dockerfile通常被签入存储库并与其他人共享。另一种方法是在运行时提供任何凭据(用户名、密码、令牌，任何敏感的东西)作为环境变量。这可以通过-e参数(用于CLI中的单个变量)或——env-file参数(用于文件中的多个变量)来运行docker。阅读这篇文章，了解如何在docker-compose中使用环境。

使用——env-file绝对是一个更安全的选择，因为如果使用set -x，它可以防止秘密显示在ps或日志中。

然而，环境变量也不是特别安全。通过docker inspect可以看到它们，因此任何可以运行docker命令的用户都可以使用它们。(当然，在主机上可以访问docker的任何用户都有root权限。)

我更喜欢的模式是使用包装器脚本作为ENTRYPOINT或CMD。包装器脚本可以首先在运行时将秘密从外部位置导入到容器中，然后执行应用程序，提供秘密。具体的机制取决于您的运行时环境。在AWS中，您可以使用IAM角色、密钥管理服务和S3的组合来将加密的秘密存储在S3桶中。HashiCorp Vault或credstash是另一种选择。

在构建过程中使用敏感数据没有最佳模式。事实上，我有一个关于这个话题的SO问题。您可以使用docker-squash从映像中删除图层。但是Docker中并没有用于此目的的本机功能。

您可能会发现在容器中对配置的shykes注释很有用。

永远不要向容器添加凭据，除非您可以将凭据广播给任何可以下载映像的人。特别是，执行并添加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.

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).

我们的团队避免将凭证放在存储库中，因此这意味着Dockerfile中不允许使用凭证。我们在应用程序中的最佳实践是使用来自环境变量的信用。

我们使用docker-compose来解决这个问题。

docker-compose之内。Yml，你可以为容器指定一个包含环境变量的文件:

 env_file:
- .env

确保将.env添加到.gitignore，然后在.env文件中设置凭据，如下所示:

SOME_USERNAME=myUser
SOME_PWD_VAR=myPwd

将.env文件存储在本地或其他团队成员可以获取它的安全位置。

见:https://docs.docker.com/compose/environment-variables/ / the-env-file

在Docker v1.9中，你可以使用ARG指令在构建操作时获取通过命令行传递给映像的参数。只需使用——build-arg标志。因此，您可以避免在Dockerfile中保留显式密码(或其他敏感信息)，并随时传递它们。

来源:https://docs.docker.com/engine/reference/commandline/build/ http://docs.docker.com/engine/reference/builder/#arg

例子:

Dockerfile

FROM busybox
ARG user
RUN echo "user is $user"

生成映像命令

docker build --build-arg user=capuccino -t test_arguments -f path/to/dockerfile .

在构建过程中打印

$ docker build --build-arg user=capuccino -t test_arguments -f ./test_args.Dockerfile .

Sending build context to Docker daemon 2.048 kB
Step 1 : FROM busybox
 ---> c51f86c28340
Step 2 : ARG user
 ---> Running in 43a4aa0e421d
 ---> f0359070fc8f
Removing intermediate container 43a4aa0e421d
Step 3 : RUN echo "user is $user"
 ---> Running in 4360fb10d46a
**user is capuccino**
 ---> 1408147c1cb9
Removing intermediate container 4360fb10d46a
Successfully built 1408147c1cb9

希望能有所帮助!再见。

使用环境变量的另一种替代方法是使用卷使容器中可以访问主机上的目录，如果环境变量太多，环境变量会变得很混乱。

如果您将所有凭据作为文件放在该文件夹中，那么容器就可以读取这些文件并根据需要使用它们。

例如:

$ echo "secret" > /root/configs/password.txt
$ docker run -v /root/configs:/cfg ...

In the Docker container:

# echo Password is `cat /cfg/password.txt`
Password is secret

许多程序都可以从一个单独的文件中读取它们的凭据，因此通过这种方式，您可以将程序指向其中一个文件。

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

kubernetes和DCOS也存在类似的特征

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

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

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

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

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

有一个新的docker命令用于“秘密”管理。但这只适用于蜂群。

docker service create
--name my-iis
--publish target=8000,port=8000
--secret src=homepage,target="\inetpub\wwwroot\index.html"
microsoft/iis:nanoserver 

仅运行时解决方案

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秘密

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

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

第13490期“秘密:记录最佳实践，做什么和不做什么，路线图”在2020年9月刚刚得到了新的更新，来自塞巴斯蒂安·范·斯泰因:

当使用buildkit作为构建器时，构建时间秘密现在是可能的;请参阅2018年11月Tõnis Tiigi的博客文章“在Docker 18.09中构建秘密和SSH转发”。

文档更新:“用BuildKit构建图像”

用于秘密的RUN——mount选项将很快升级为默认的(稳定的)Dockerfile语法。

最后一部分是新的(2020年9月)

New Docker Build secret information The new --secret flag for docker build allows the user to pass secret information to be used in the Dockerfile for building docker images in a safe way that will not end up stored in the final image. id is the identifier to pass into the docker build --secret. This identifier is associated with the RUN --mount identifier to use in the Dockerfile. Docker does not use the filename of where the secret is kept outside of the Dockerfile, since this may be sensitive information. dst renames the secret file to a specific file in the Dockerfile RUN command to use. For example, with a secret piece of information stored in a text file: $ echo 'WARMACHINEROX' > mysecret.txt And with a Dockerfile that specifies use of a BuildKit frontend docker/dockerfile:1.0-experimental, the secret can be accessed. For example:

# syntax = docker/dockerfile:1.0-experimental
FROM alpine

# shows secret from default secret location:
RUN --mount=type=secret,id=mysecret cat /run/secrets/mysecret

# shows secret from custom secret location:
RUN --mount=type=secret,id=mysecret,dst=/foobar cat /foobar

这个Dockerfile只是为了证明这个秘密可以被访问。正如您可以在构建输出中看到的那样。最终构建的图像将没有秘密文件:

$ docker build --no-cache --progress=plain --secret id=mysecret,src=mysecret.txt .
...
#8 [2/3] RUN --mount=type=secret,id=mysecret cat /run/secrets/mysecret
#8       digest: sha256:5d8cbaeb66183993700828632bfbde246cae8feded11aad40e524f54ce7438d6
#8         name: "[2/3] RUN --mount=type=secret,id=mysecret cat /run/secrets/mysecret"
#8      started: 2018-08-31 21:03:30.703550864 +0000 UTC
#8 1.081 WARMACHINEROX
#8    completed: 2018-08-31 21:03:32.051053831 +0000 UTC
#8     duration: 1.347502967s

#9 [3/3] RUN --mount=type=secret,id=mysecret,dst=/foobar cat /foobar
#9       digest: sha256:6c7ebda4599ec6acb40358017e51ccb4c5471dc434573b9b7188143757459efa
#9         name: "[3/3] RUN --mount=type=secret,id=mysecret,dst=/foobar cat /foobar"
#9      started: 2018-08-31 21:03:32.052880985 +0000 UTC
#9 1.216 WARMACHINEROX
#9    completed: 2018-08-31 21:03:33.523282118 +0000 UTC
#9     duration: 1.470401133s
...

我想，如果它是bash shell，像这样简单的东西就可以工作。

读取-sp "db_password:" password | docker run -itd——name <container_name>——build-arg mysql_db_password=$db_password alpine /bin/bash

只需默读它，并在Docker映像中作为参数传递。你需要在Dockerfile中接受变量作为ARG。

从版本20.10开始，除了使用secret-file，您还可以直接使用env提供秘密。

Buildkit: secrets:允许提供秘密与env moby/moby#41234 docker/cli#2656 moby/ Buildkit #1534 支持——secret id=foo,env=MY_ENV作为将秘密值存储到文件的替代方案。 ——secret id=GIT_AUTH_TOKEN将加载env，如果它存在，而文件不存在。

秘密文件:

THIS IS SECRET

Dockerfile：

# syntax = docker/dockerfile:1.3
FROM python:3.8-slim-buster
COPY build-script.sh .
RUN --mount=type=secret,id=mysecret ./build-script.sh

build-script.sh:

cat /run/secrets/mysecret

执行:

$ export MYSECRET=theverysecretpassword
$ export DOCKER_BUILDKIT=1
$ docker build --progress=plain --secret id=mysecret,env=MYSECRET -t abc:1 . --no-cache
......
#9 [stage-0 3/3] RUN --mount=type=secret,id=mysecret ./build-script.sh
#9 sha256:e32137e3eeb0fe2e4b515862f4cd6df4b73019567ae0f49eb5896a10e3f7c94e
#9 0.931 theverysecretpassword#9 DONE 1.5s
......