从版本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
......

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

在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

希望能有所帮助!再见。

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

kubernetes和DCOS也存在类似的特征

仅运行时解决方案

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

我们的团队避免将凭证放在存储库中，因此这意味着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