Docker中通过环境变量传递秘密的安全风险

44次阅读

问题描述

是一个Docker的新手，想要将自己的Django Web应用程序放入容器中。他在过去几天一直在努力安全地传递凭据给容器。他在网上看到的提示是不要将秘密作为环境变量传递，因为可以通过inspect或从镜像中检索到。他希望在他的设置中可以忽略这个问题。他提供了以下设置信息：
– 他通过docker-compose的.env文件提供凭据。这个文件不在版本控制中。
– 容器以非特权用户（一个不同的特殊用户）运行。
– 主机上的Docker命令只能以root身份使用。
– 他是主机服务器的唯一用户（Ubuntu 18.04）。
– 他认为入侵主机比入侵Django应用程序的容器要困难得多。
– 他不想使用Kubernetes或Swarm。

用户是Docker的新手，不是安全专家。他想知道是否有什么遗漏的地方，以及为什么在这个设置中要关心docker inspect或镜像。

解决方案

请注意以下操作注意版本差异及修改前做好备份。

方案1

将凭据作为环境变量传递给容器是一种不错的方式。你所不希望做的是直接将凭据嵌入到镜像中。正如你所做的那样，不要将凭据存储在源代码控制库中。除了环境变量，你还可以考虑使用外部的凭据存储库，比如Hashicorp的Vault，或者甚至是AWS的凭据。参考Vault的GitHub页面。你的容器仍然需要一个用于与密钥存储进行身份验证/授权的令牌/凭据，但如果需要，这些令牌/凭据可以设置为过期/轮换。

所以你走在正确的道路上。此时值得阅读一些额外的资料：
– https://medium.com/@mccode/dont-embed-configuration-or-secrets-in-docker-images-7b2e0f916fdd
– https://techbeacon.com/how-keep-your-container-secrets-secure

方案2

只要没有其他人登录到服务器或能够对主机运行docker命令，那么将凭据作为环境变量传递到仅存储在主机上的容器中是相对安全的。我能想到的唯一风险是它是明文值存储在磁盘上，所以你有硬盘丢失或备份的风险。

Docker的Swarm模式的秘密相对于环境变量和其他管理秘密的方式具有以下优势：
– 值在管理器硬盘上进行加密，尽管通常解密密钥也在那里，以便更容易重新启动管理器。
– 值不会写入工作节点上的磁盘，它们作为一个文件注入到容器中挂载的tmpfs文件系统中。
– 值无法通过inspect命令在服务、容器或秘密本身上显示。您必须部署一个带有秘密的服务才能访问该秘密。
– 秘密会根据需要从管理器发送到工作节点，无需构建一个外部进程来在主机之间同步文件。
– 秘密文件可以通过Unix文件系统权限进行限制，例如只允许root读取访问，并在加载秘密后使容器放弃对其他用户的访问权限。

也就是说，无论如何，所有的秘密管理解决方案都是为应用程序提供明文密码或其他凭据的一种方式。而且，每种方法都有一定程度的风险。减少风险的最佳方法之一是确保每个服务都有自己的独立秘密，只提供该特定服务所需的访问权限，并经常进行轮换。此外，还可以考虑其他安全层，如使用服务网格解决方案配置的网络策略。