Docker数据安全隐患分析

Docker容器为应用的编写、分发和部署带来真正翻天覆地的变化。容器的目的是灵活性，让应用可按需启用，无论何时以及何地。当然无论我们在哪里使用应用，我们都需要数据。

对于数据应该如何映射到容器主要有两个流派。***个流派称我们将数据保留在容器中;第二个称我们在容器外保存***性数据，这些数据可超越任何单个容器的使用寿命。在这两种情况下，安全问题给数据和容器管理带来大问题。

[[184096]]

▲Image: Pexels/Pixabay

管理数据访问

现在有很多技术可用于分配存储到Docker容器。临时存储容量，本地到运行容器的主机，可在运行时分配到容器。存储卷存储在映射到应用的特定子目录的主机内。卷可在容器实例化时创建，或者使用“docker volume”命令提前创建。

另外，本地存储可作为安装点映射到容器。在这种情况下，“docker run”命令可指定本地目录作为容器内的安装点。第三种选择是使用存储插件直接关联外部存储与容器。

开放访问

在每种方法中，Docker框架都没有提供针对数据的内在安全模型。例如，任何主机目录可安装到容器，包括敏感系统文件夹，例如/etc。这意味着容器可能修改这些文件，因为使用标准简单的Unix权限设置来授予权限。对此，另一种更好的做法是使用非根容器，这涉及在不同的Linux用户ID(UID)下运行容器。这比较容易做，但这意味着构建一种方法来保护每个容器，使用组ID(GID)或者UID作为权限检查。

在这里我们遇到另一个问题：使用非根容器，而本地卷无法正常工作，除非用于运行容器的UID有权限访问/var/lib/docker/volumes 目录。如果不这样做，数据无法访问或创建。打开这个目录会有安全风险;然而，并没有固有方法来按卷设置单独的权限。

如果我们看看外部存储如何安装到容器，很多解决方案只需向运行容器的主机展示块设备(LUN)以及格式化文件系统。这随后展示到容器作为安装点。在这一点上，目录和文件的安全性可在容器内设置，减少我们已经讨论的问题。然而，如果这个LUN/volume在其他地方重复使用，则对其如何安装和使用没有安全控制，因为没有安全模型直接构建到容器/卷映射关系。一切都取决于信任主机上运行的命令。

这里还有一个问题：缺乏多租户性。当我们运行容器时，每个容器实例可能为单独的应用运行。在传统存储部署中，分配到容器的存储应该有一定程度的分离，以确保数据不会被无意或恶意访问。目前没有简单的方法在主机级别做到这一点，只有信任编排工具来运行容器以及映射到数据。

寻找解决方案

这里有些问题是特定于Linux/Unix。例如，安装命名空间的抽象化为我们的数据提供了不同的入口点，然而，并没有权限的抽象化–我无法映射用户1000到用户1001-如果没有物理升级与每个文件及目录相关的ACL(访问控制列表)数据。大规模ACL变更可能会影响性能。对于本地卷来说，Docker可简单地设置主机目录的权限，新卷匹配正在启动容器的UID。

外部卷提供了很好的机会，让我们可以从运行容器主机中的权限结构转移。然而，这意味着我们需要一种机制来映射卷数据到特定容器实例中已知可信应用。请记住，容器并没有固有的“身份”，可根据意愿开始和停止。这使得它很难确定任何单个容器是否是数据卷的所有者。

目前主要解决方案是依靠编排平台来管理容器的运行。我们信任这些系统来映射卷和容器，在很多方面，这并不像传统SAN存储或者虚拟磁盘映射到虚拟机那样。但容器的区别在于其可便携性，以及需要安全机制延伸到公共云。

我们仍然有很多工作要做。对于Docker，对存储初创公司Infinit的收购可能启发他们如何保护持久性数据。这应该可能意味着开发接口让所有供应商可致力于此。