我有一个基本的docker映像，用于运行映像分析软件。对于从映像创建的每个容器，都有一组配置设置，其中一些是机密（加密密钥，客户信息等），软件可以使用这些设置来分析和分发处理后的映像。我如何安全地将这些机密传递到容器？

评论

Hashicorp保险库

#1 楼

您有3种方法来获取Docker容器内应用程序的机密。前两个涉及docker配置。最后一个是让您的应用程序直接从秘密商店中获取秘密。

1-环境变量

根据“ 12因素应用程序”指南，秘密仅是配置，并且应该始终在环境中设置它们。您可以在docker运行期间将机密设置为环境变量，然后您的应用从那里访问它们。

2-装入的卷

您可以将机密全部存储在特定的环境中配置/秘密文件，然后将该文件作为已安装的卷安装到您的实例。

3-从秘密商店获取

如@ 030所述，您可以使用Hashicorp Vault（或“ Amazon Secrets Manager”或任何类似的服务）。
您的应用程序或Sidecar应用程序可以直接获取其所需的秘密，而无需处理Docker容器上的任何配置。此方法将允许您使用动态创建的机密（此类系统的一个非常吸引人的功能），而不必担心这些机密可以从文件系统查看或检查docker容器的env变量。

个人意见

我相信env变量是必经之路。它更易于管理，并且如果您具有CI构建系统，则仍可以从Hashicorp Vault之类的秘密商店中提取信息，并在构建过程中提取其秘密并在部署时进行设置。您将两全其美，并获得了开发人员无需编写应用程序代码来获取机密信息的额外好处。开发人员应专注于其代码功能，而不要处理诸如获取密码之类的管理任务。就像12个因子应用程序状态一样。

编辑：更改了最后一句，以消除Developer vs SysAdmin孤岛的含义。任务本身应该与代码角度分开，但是DevOps大约是同一个人，既要牢记又要不受限制。 Dirk的出色评论（将机密传递到Docker容器中），由于不想泄漏它们，因此有一个非常有力的理由将机密存储优先于ENV var。

评论

这促进了筒仓。 DevOps是一起做事，而不是把事情扔在墙上。

– 030
18年4月19日在15:24


该代码应与基础架构组件隔离。实际的人可以对基础结构自动化和应用程序代码库进行编码，但是任务本身应该分开。我看到我最初回答的最后一句话是孤立开发人员，即人民。那是一个错误。我将对其进行更清晰的编辑。

–BoomShadow
18年4月20日在15:03
将机密放入环境变量中可以为泄露它们提供各种可能性。一些示例：在运行容器的计算机上，有权访问Docker守护程序的每个人都可以使用inspect或exec命令查看它们。在某些调试模式下运行时，环境变量通常会转储到stdout或日志文件中。所有产生的子进程都可以读取和公开它们，这可能是您无法控制的。更多信息，例如此处：diogomonica.com/2017/03/27/…

–德克
19年2月1日在17:03
我也在解决这个问题。我不了解的是，即使您使用凭证保险库保护您的秘密，您仍然必须进行身份验证才能访问该保险库，并且大概需要一些秘密。同样的问题也适用于使用受密码保护的KeyStore文件。我们是否始终坚持在环境中至少传递“元凭据”？

–车轮
19年3月8日在17:43
@Wheezil比许多特定的凭证更容易保护元凭证。您可以经常自动旋转元凭证。元凭证可以转到安全主机上的保管库，并且可以具有ip白名单等功能，以便它仅接受来自生产子网的连接。您还可以确保保管库使用静态加密，运行中加密以及相互的tsl和证书固定以及所有其他使操作更安全的最佳做法。

–simbo1905
19 Mar 9 '19在6:15


#2 楼

还有一个仅使用管道的选项：

docker run -d -i --name $n alpine sh -c 'read A; echo "[$A]"; exec some-server'
docker exec -i $n sh -c 'cat > /proc/1/fd/0' <<< _a_secret_


首先，使用-i创建docker守护进程，命令read A将挂起，等待来自/proc/1/fd/0的输入；
然后运行第二个docker命令，从stdin中读取机密并重定向到最后一个挂起的进程。