Docker 容器、环境变量和数据库

信息安全 密码 码头工人
2021-08-17 01:13:47

Docker 容器中的环境变量(用 设置-e)可用于每个链接的容器。

考虑一个典型的用例,一个数据库。MySQL 官方镜像给出了这个示例命令:

docker run --name some-mysql -e MYSQL_ROOT_PASSWORD=my-secret-pw -d mysql:tag

我刚刚将密码作为明文放入环境变量中。可以肯定的是,你需要docker inspect看到它,如果你能做到这一点,这意味着你有主机操作系统的 root 访问权限,无论如何这已经结束了......所以让我们继续吧。

现在我也想建立一个wiki。让我们使用这个 MediaWiki 图像我们还需要链接数据库:

docker run --name some-mediawiki --link some-mysql:mysql -d synctree/mediawiki

哎呀!当我链接some-mysql时,环境变量传播了,现在some-mediawiki也可以看到MYSQL_ROOT_PASSWORD了!这意味着,如果有人要破坏 wiki,他们可能还可以找到 root 密码,然后通过链接进入数据库。

Docker 开发人员对此进行了一些讨论,得出的结论是环境变量从来都不是用来安全地共享秘密的,以这种方式使用它们是错误的。然而,我一直看到图像将密码作为环境变量传递,甚至许多官方数据库图像都这样做。为什么?

2个回答

您的问题的明确答案实际上只能来自“错误”的单个图像的维护者 - 使用此功能,但是一些可能的解释是

  • 他们没有意识到风险。Docker 对很多人来说是一项相对较新的技术,“最佳实践”并不总是对每个人都很清楚,尽管 Docker 开发人员在这方面做出了很好的努力,比如 CIS 指南
  • 他们意识到风险,但认为这对他们的特定架构来说不是一个严重的问题。这可能是这种情况,例如,系统的其他方面意味着链接的容器需要相互信任,因此一个容器的妥协很容易导致另一个容器的妥协,而不管环境变量共享如何。
  • 他们意识到风险,但缺乏更好的选择。最终,服务密码管理是一个难以解决的棘手问题,并且取决于容器上使用的软件,可能没有维护人员认为可以像使用环境变量一样工作的选项。

如果您不在多租户机器上,那么这应该不是问题。另一方面,一项服务的妥协意味着两者都会受到影响。这是使用单独的虚拟机或其他地方的微服务进行多机设置的主要原因。