blocks|key|136051|text|这肯定是一个令人担忧的问题。Dockerfile通常签入到存储库并与其他人共享。另一种方法是提供任何凭据(用户名、密码、令牌、任何敏感内容)+as+environment+variables+at+runtime。这可以通过docker+run的-e参数(对于CLI上的单个var)或--env-file参数(对于文件中的多个变量)来实现。阅读this了解如何通过docker-compose使用环境。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|136052|使用--env-file绝对是一个更安全的选择，因为如果使用set+-x，它可以防止出现在ps或日志中的秘密。|136053|但是，env+var也不是特别安全。它们通过docker+inspect可见，因此任何可以运行docker命令的用户都可以使用它们。(当然，任何有权访问主机上的docker的用户也可以使用has+root。)|136054|我更喜欢的模式是使用包装器脚本作为ENTRYPOINT或CMD。包装器脚本可以首先在运行时将机密从外部位置导入到容器中，然后执行应用程序，提供机密。根据您的运行时环境的不同，具体的机制会有所不同。在亚马逊网络服务中，您可以使用IAM角色、Key+Management+Service和S3的组合在S3存储桶中存储加密的秘密。像HashiCorp+Vault或credstash这样的东西是另一种选择。|136055|AFAIK对于使用敏感数据作为构建过程的一部分，没有最佳模式。事实上，我有一个关于这个话题的SO+question。可以使用docker-squash从图像中删除图层。但Docker中没有用于此目的的原生功能。|136056|你可能会发现shykes+comments+on+config+in+containers很有用。|136057|entityMap|0|LINK|mutability|MUTABLE|url|https://docs.docker.com/engine/reference/commandline/run/#/set-environment-variables-e-env-env-file|1|https://docs.docker.com/compose/environment-variables/|2|https://docs.docker.com/engine/security/security/#/docker-daemon-attack-surface|3|https://aws.amazon.com/kms/|4|https://www.vaultproject.io/|5|https://github.com/fugue/credstash|6|https://stackoverflow.com/questions/26005028/how-to-idiomatically-access-sensitive-data-when-building-a-docker-image|7|https://github.com/jwilder/docker-squash|8|https://groups.google.com/forum/?fromgroups#!topic/docker-user/FyCWLC38Ueg^0|34|A|3F|2|3Y|A|1Z|Z|0|4S|4|1|0|2|A|U|6|19|2|0|M|E|1B|6|28|6|2M|8|2|0|H|A|S|3|3B|M|3|4J|F|4|4Z|9|5|0|1A|B|6|1Q|D|7|0|D|W|8|0^^$0|@$1|2|3|4|5|6|7|1D|8|@$9|1E|A|1F|B|C]|$9|1G|A|1H|B|C]|$9|1I|A|1J|B|C]]|D|@$9|1K|A|1L|1|1M]|$9|1N|A|1O|1|1P]]|E|$]]|$1|F|3|G|5|6|7|1Q|8|@$9|1R|A|1S|B|C]|$9|1T|A|1U|B|C]|$9|1V|A|1W|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|1X|8|@$9|1Y|A|1Z|B|C]|$9|20|A|21|B|C]|$9|22|A|23|B|C]]|D|@$9|24|A|25|1|26]]|E|$]]|$1|J|3|K|5|6|7|27|8|@$9|28|A|29|B|C]|$9|2A|A|2B|B|C]]|D|@$9|2C|A|2D|1|2E]|$9|2F|A|2G|1|2H]|$9|2I|A|2J|1|2K]]|E|$]]|$1|L|3|M|5|6|7|2L|8|@]|D|@$9|2M|A|2N|1|2O]|$9|2P|A|2Q|1|2R]]|E|$]]|$1|N|3|O|5|6|7|2S|8|@]|D|@$9|2T|A|2U|1|2V]]|E|$]]|$1|P|3|-4|5|6|7|2W|8|@]|D|@]|E|$]]]|Q|$R|$5|S|T|U|E|$V|W]]|X|$5|S|T|U|E|$V|Y]]|Z|$5|S|T|U|E|$V|10]]|11|$5|S|T|U|E|$V|12]]|13|$5|S|T|U|E|$V|14]]|15|$5|S|T|U|E|$V|16]]|17|$5|S|T|U|E|$V|18]]|19|$5|S|T|U|E|$V|1A]]|1B|$5|S|T|U|E|$V|1C]]]]

Definitely it is a concern. Dockerfiles are commonly checked in to repositories and shared with other people. An alternative is to provide any credentials (usernames, passwords, tokens, anything sensitive) <a href="https://docs.docker.com/engine/reference/commandline/run/#/set-environment-variables-e-env-env-file" rel="noreferrer">as environment variables at runtime</a>. This is possible via the <code>-e</code> argument (for individual vars on the CLI) or <code>--env-file</code> argument (for multiple variables in a file) to <code>docker run</code>. Read <a href="https://docs.docker.com/compose/environment-variables/" rel="noreferrer">this</a> for using environmental with docker-compose.

Using <code>--env-file</code> is definitely a safer option since this protects against the secrets showing up in <code>ps</code> or in logs if one uses <code>set -x</code>.

However, env vars are not particularly secure either. They are visible via <code>docker inspect</code>, and hence they are available to any user that can run <code>docker</code> commands. (Of course, any user that has access to <code>docker</code> on the host also <a href="https://docs.docker.com/engine/security/security/#/docker-daemon-attack-surface" rel="noreferrer">has root</a> anyway.)

My preferred pattern is to use a wrapper script as the <code>ENTRYPOINT</code> or <code>CMD</code>. The wrapper script can first import secrets from an outside location in to the container at run time, then execute the application, providing the secrets. The exact mechanics of this vary based on your run time environment. In AWS, you can use a combination of IAM roles, the <a href="https://aws.amazon.com/kms/" rel="noreferrer">Key Management Service</a>, and S3 to store encrypted secrets in an S3 bucket. Something like <a href="https://www.vaultproject.io/" rel="noreferrer">HashiCorp Vault</a> or <a href="https://github.com/fugue/credstash" rel="noreferrer">credstash</a> is another option.

AFAIK there is no optimal pattern for using sensitive data as part of the build process. In fact, I have an <a href="https://stackoverflow.com/questions/26005028/how-to-idiomatically-access-sensitive-data-when-building-a-docker-image">SO question</a> on this topic. You can use <a href="https://github.com/jwilder/docker-squash" rel="noreferrer">docker-squash</a> to remove layers from an image. But there's no native functionality in Docker for this purpose.

You may find shykes <a href="https://groups.google.com/forum/?fromgroups#!topic/docker-user/FyCWLC38Ueg" rel="noreferrer">comments on config in containers</a> useful.

blocks|key|4642802|text|您不应该向容器添加凭据，除非您同意将凭据广播给任何可以下载图像的人。特别是，执行和ADD+creds以及后来的RUN+rm+creds是不安全的，因为证书文件保留在中间文件系统层的最终映像中。对于任何有权访问该图像的人来说，提取它都很容易。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|4642803|我见过的典型的解决方案是，当你需要creds来签出依赖关系时，使用一个容器来构建另一个容器。也就是说，通常你在你的基本容器中有一些构建环境，你需要调用它来构建你的应用容器。因此，简单的解决方案是添加您的应用程序源代码，然后RUN构建命令。如果您需要该RUN中的证书，这是不安全的。相反，您要做的是将源文件放到本地目录中，运行(与docker+run中一样)容器来执行构建步骤，将本地源文件目录安装为卷，并将凭证注入或安装为另一个卷。构建步骤完成后，只需对本地源目录执行ADD操作即可构建最终的容器，该目录现在包含已构建的工件。|4642804|我希望Docker增加一些功能来简化这一切！|4642805|更新:看起来下一步的方法将是嵌套构建。简而言之，dockerfile将描述用于构建运行时环境的第一个容器，然后描述可以将所有片段组装到最终容器中的第二个嵌套容器构建。这样，构建时的东西就不在第二个容器中了。这是一个Java应用程序，您需要JDK来构建应用程序，但只需要JRE来运行它。有许多提案正在讨论中，最好从https://github.com/docker/docker/issues/7115开始，并遵循一些替代提案的链接。|4642806|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/docker/docker/issues/7115^0|15|9|1J|C|0|33|3|3H|3|4K|A|6I|3|0|0|4C|18|0|0^^$0|@$1|2|3|4|5|6|7|T|8|@$9|U|A|V|B|C]|$9|W|A|X|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|Y|8|@$9|Z|A|10|B|C]|$9|11|A|12|B|C]|$9|13|A|14|B|C]|$9|15|A|16|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|17|8|@]|D|@]|E|$]]|$1|J|3|K|5|6|7|18|8|@]|D|@$9|19|A|1A|1|1B]]|E|$]]|$1|L|3|-4|5|6|7|1C|8|@]|D|@]|E|$]]]|M|$N|$5|O|P|Q|E|$R|S]]]]

You should never add credentials to a container unless you're OK broadcasting the creds to whomever can download the image. In particular, doing and <code>ADD creds</code> and later <code>RUN rm creds</code> is not secure because the creds file remains in the final image in an intermediate filesystem layer. It's easy for anyone with access to the image to extract it.

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 <code>RUN</code> the build commands. This is insecure if you need creds in that <code>RUN</code>. Instead what you do is put your source into a local directory, run (as in <code>docker run</code>) 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 <code>ADD</code>ing the local source directory which now contains the built artifacts.

I'm hoping Docker adds some features to simplify all this!

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 <a href="https://github.com/docker/docker/issues/7115">https://github.com/docker/docker/issues/7115</a> and follow some of the links for alternate proposals.

blocks|key|4642831|text|虽然我完全同意没有简单的解决方案。仍然存在单点故障。dockerfile、etcd等。Apcera有一个看起来像伙伴-双重身份验证的计划。换句话说，除非存在Apcera配置规则，否则两个容器无法通信。在他们的演示中，uid/pwd是明文的，在管理员配置链接之前无法重用。然而，这可能意味着要修补Docker或至少是网络插件(如果有这样的东西)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4642832|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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

blocks|key|4642882|text|我们的团队避免将凭据放入存储库中，因此这意味着它们在Dockerfile中是不允许的。我们在应用程序中的最佳实践是使用来自环境变量的证书。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|4642883|我们使用docker-compose来解决这个问题。|4642884|在docker-compose.yml中，您可以指定一个包含容器环境变量的文件：|4642885|+env_file:
-+.env|code-block|syntax|javascript|4642886|确保将.env添加到.gitignore，然后在.env文件中设置凭据，如下所示：|4642887|SOME_USERNAME=myUser
SOME_PWD_VAR=myPwd|4642888|将.env文件存储在本地或团队其他成员可以获取的安全位置。|4642889|请参阅：https://docs.docker.com/compose/environment-variables/#/the-env-file|4642890|entityMap|0|LINK|mutability|MUTABLE|url|https://docs.docker.com/compose/environment-variables/#/the-env-file^0|Q|A|0|4|E|0|1|I|0|0|3|4|A|A|O|4|0|0|1|4|0|4|1W|0|0^^$0|@$1|2|3|4|5|6|7|14|8|@$9|15|A|16|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|17|8|@$9|18|A|19|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|1A|8|@$9|1B|A|1C|B|C]]|D|@]|E|$]]|$1|J|3|K|5|L|7|1D|8|@]|D|@]|E|$M|N]]|$1|O|3|P|5|6|7|1E|8|@$9|1F|A|1G|B|C]|$9|1H|A|1I|B|C]|$9|1J|A|1K|B|C]]|D|@]|E|$]]|$1|Q|3|R|5|L|7|1L|8|@]|D|@]|E|$M|N]]|$1|S|3|T|5|6|7|1M|8|@$9|1N|A|1O|B|C]]|D|@]|E|$]]|$1|U|3|V|5|6|7|1P|8|@]|D|@$9|1Q|A|1R|1|1S]]|E|$]]|$1|W|3|-4|5|6|7|1T|8|@]|D|@]|E|$]]]|X|$Y|$5|Z|10|11|E|$12|13]]]]

Our team avoids putting credentials in repositories, so that means they're not allowed in <code>Dockerfile</code>. Our best practice within applications is to use creds from environment variables.

We solve for this using <code>docker-compose</code>.

Within <code>docker-compose.yml</code>, you can specify a file that contains the environment variables for the container:

<pre><code> env_file:
- .env
</code></pre>

Make sure to add <code>.env</code> to <code>.gitignore</code>, then set the credentials within the <code>.env</code> file like:

<pre><code>SOME_USERNAME=myUser
SOME_PWD_VAR=myPwd
</code></pre>

Store the <code>.env</code> file locally or in a secure location where the rest of the team can grab it.

See: <a href="https://docs.docker.com/compose/environment-variables/#/the-env-file" rel="noreferrer">https://docs.docker.com/compose/environment-variables/#/the-env-file</a>

blocks|key|4642922|text|使用环境变量的另一种方法是使用卷，使主机上的目录可以在容器中访问。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4642923|如果您将所有凭据作为文件放在该文件夹中，则容器可以读取这些文件并随心所欲地使用它们。|4642924|例如：|4642925|$+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|code-block|syntax|javascript|4642926|许多程序可以从单独的文件中读取它们的凭据，因此通过这种方式，您只需将程序指向其中一个文件。|4642927|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|Q|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|R|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|S|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

An alternative to using environment variables, which can get messy if you have a lot of them, is to use volumes to make a directory on the host accessible in the container.

If you put all your credentials as files in that folder, then the container can read the files and use them as it pleases.

For example:

<pre><code>$ echo "secret" &gt; /root/configs/password.txt
$ docker run -v /root/configs:/cfg ...

In the Docker container:

# echo Password is `cat /cfg/password.txt`
Password is secret
</code></pre>

Many programs can read their credentials from a separate file, so this way you can just point the program to one of the files.

blocks|key|4642945|text|Docker现在(版本1.13或17.06及更高版本)支持管理秘密信息。下面是一个overview和更详细的documentation|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|4642946|在kubernetes和DCOS中也存在类似的功能|4642947|entityMap|0|LINK|mutability|MUTABLE|url|https://blog.docker.com/2017/02/docker-secrets-management/|1|https://docs.docker.com/engine/swarm/secrets/|2|https://kubernetes.io/docs/concepts/configuration/secret/|3|https://docs.mesosphere.com/1.9/security/secrets/^0|15|8|0|1I|D|1|0|1|A|2|C|4|3|0^^$0|@$1|2|3|4|5|6|7|T|8|@]|9|@$A|U|B|V|1|W]|$A|X|B|Y|1|Z]]|C|$]]|$1|D|3|E|5|6|7|10|8|@]|9|@$A|11|B|12|1|13]|$A|14|B|15|1|16]]|C|$]]|$1|F|3|-4|5|6|7|17|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]|N|$5|I|J|K|C|$L|O]]|P|$5|I|J|K|C|$L|Q]]|R|$5|I|J|K|C|$L|S]]]]

Docker now (version 1.13 or 17.06 and higher) has support for managing secret information. Here's an <a href="https://blog.docker.com/2017/02/docker-secrets-management/" rel="noreferrer">overview</a> and more detailed <a href="https://docs.docker.com/engine/swarm/secrets/" rel="noreferrer">documentation</a>

Similar feature exists in <a href="https://kubernetes.io/docs/concepts/configuration/secret/" rel="noreferrer">kubernetes</a> and <a href="https://docs.mesosphere.com/1.9/security/secrets/" rel="noreferrer">DCOS</a>

blocks|key|136309|text|我的方法似乎是有效的，但可能是天真的。告诉我为什么它是错的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|136310|docker构建过程中设置的参数是由history子命令公开的，所以不会去那里。但是，在运行容器时，run命令中给出的环境变量可用于容器，但不是映像的一部分。|136311|因此，在Dockerfile中，进行不涉及机密数据的设置。设置一个类似/root/finish.sh的CMD。在run命令中，使用环境变量将秘密数据发送到容器中。finish.sh本质上使用变量来完成构建任务。|offset|length|style|CODE|136312|为了简化秘密数据的管理，请将其放入一个文件中，该文件由docker+run与--env-file开关一起加载。当然，要对文件保密。.gitignore之类的。|136313|对我来说，finish.sh运行一个Python程序。它检查以确保它以前没有运行过，然后完成设置(例如，将数据库名称复制到Django的settings.py中)。|136314|entityMap^0|0|0|Z|F|29|9|0|12|A|1T|A|0|5|9|1W|B|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@$F|S|G|T|H|I]|$F|U|G|V|H|I]]|9|@]|A|$]]|$1|J|3|K|5|6|7|W|8|@$F|X|G|Y|H|I]|$F|Z|G|10|H|I]]|9|@]|A|$]]|$1|L|3|M|5|6|7|11|8|@$F|12|G|13|H|I]|$F|14|G|15|H|I]]|9|@]|A|$]]|$1|N|3|-4|5|6|7|16|8|@]|9|@]|A|$]]]|O|$]]

My approach seems to work, but is probably naive. Tell me why it is wrong.

ARGs set during docker build are exposed by the history subcommand, so no go there. However, when running a container, environment variables given in the run command are available to the container, but are not part of the image.

So, in the Dockerfile, do setup that does not involve secret data. Set a CMD of something like <code>/root/finish.sh</code>. In the run command, use environmental variables to send secret data into the container. <code>finish.sh</code> uses the variables essentially to finish build tasks.

To make managing the secret data easier, put it into a file that is loaded by docker run with the <code>--env-file</code> switch. Of course, keep the file secret. <code>.gitignore</code> and such.

For me, <code>finish.sh</code> runs a Python program. It checks to make sure it hasn't run before, then finishes the setup (e.g., copies the database name into Django's <code>settings.py</code>).

blocks|key|136348|text|有一个新的docker+command用于“秘密”管理。但这只适用于集群。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|136349|docker+service+create
--name+my-iis
--publish+target=8000,port=8000
--secret+src=homepage,target="\inetpub\wwwroot\index.html"
microsoft/iis:nanoserver+|code-block|syntax|javascript|136350|entityMap|0|LINK|mutability|MUTABLE|url|https://docs.docker.com/engine/swarm/secrets/^0|C|7|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@$A|R|B|S|1|T]]|C|$]]|$1|D|3|E|5|F|7|U|8|@]|9|@]|C|$G|H]]|$1|I|3|-4|5|6|7|V|8|@]|9|@]|C|$]]]|J|$K|$5|L|M|N|C|$O|P]]]]

There is a new docker <a href="https://docs.docker.com/engine/swarm/secrets/" rel="nofollow noreferrer">command</a> for "secrets" management. But that only works for swarm clusters.

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

blocks|key|4643039|text|12-Factor+app+methodology告诉我们，任何配置都应该存储在环境变量中。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|4643040|docker+compose可以在配置中执行variable+substitution，因此可以用来将密码从主机传递到Docker。|4643041|entityMap|0|LINK|mutability|MUTABLE|url|https://12factor.net/|1|https://docs.docker.com/compose/compose-file/#variable-substitution^0|0|P|0|0|M|L|1|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@$A|Q|B|R|1|S]]|C|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@$A|U|B|V|1|W]]|C|$]]|$1|F|3|-4|5|6|7|X|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]|N|$5|I|J|K|C|$L|O]]]]

The <a href="https://12factor.net/" rel="nofollow noreferrer">12-Factor app methodology</a> tells, that any configuration should be stored in environment variables. 

Docker compose could do <a href="https://docs.docker.com/compose/compose-file/#variable-substitution" rel="nofollow noreferrer">variable substitution</a> in configuration, so that could be used to pass passwords from host to docker.

blocks|key|136441|text|如果是bash+shell，我想像这样简单的东西就可以工作了。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|136442|阅读-sp+"db_password:“password+%7C+docker+run+-itd+--name++--build-arg+mysql_db_password=$db_password高山/bin/bash|136443|只需静默读取并在Docker镜像中作为参数传递即可。您需要在Dockerfile中将变量接受为ARG。|136444|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Something simply like this will work I guess if it is bash shell.
read -sp &quot;db_password:&quot; password | docker run -itd --name &lt;container_name&gt; --build-arg mysql_db_password=$db_password alpine /bin/bash
Simply read it silently and pass as argument in Docker image. You need to accept the variable as ARG in Dockerfile.

I've been experimenting with Docker recently on building some services to play around with and one thing that keeps nagging me has been putting passwords in a Dockerfile. I'm a developer so storing passwords in source feels like a punch in the face. Should this even be a concern? Are there any good conventions on how to handle passwords in Dockerfiles?

Docker and securing passwords

文件存储

身份验证

文件系统

数据库

容器

Docker

Django

Python

Java

我最近一直在尝试使用Docker来构建一些服务，有一件事一直困扰着我，那就是把密码放在Dockerfile中。我是一名开发人员，所以在源代码中存储密码感觉就像是在脸上打了一拳。这是否应该引起人们的关注？关于如何处理Dockerfile中的密码，有什么好的约定吗？

问Docker和安全密码
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Docker和安全密码EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Docker和安全密码
EN