Docker容器给应用程序的编写、分发和部署带来了真正翻天覆地的变化。容器的目的是灵活性，以便应用程序可以按需启动，何时何地。当然，无论我们在哪里使用应用程序，我们都需要数据。关于如何将数据映射到容器，有两种主要的思想流派。第一种观点认为我们将数据保存在容器中；第二个说我们将永久数据保存在容器之外，这些数据比任何单个容器的寿命都长。在这两种情况下，安全问题都会给数据和容器管理带来大问题。▲图片：Pexels/Pixabay管理数据访问有许多技术可用于将存储分配给Docker容器。运行容器的主机本地的临时存储容量可以在运行时分配给容器。存储卷存储在映射到特定于应用程序的子目录的主机中。卷可以在容器实例化时创建，也可以使用“dockervolume”命令提前创建。或者，本地存储可以作为挂载点映射到容器。在这种情况下，“dockerrun”命令指定一个本地目录作为容器内的挂载点。第三种选择是使用存储插件直接将外部存储与容器相关联。开放访问在每种方法中，Docker框架都不为数据提供固有的安全模型。例如，任何主机目录都可以挂载到容器中，包括/etc等敏感的系统文件夹。这意味着容器可以修改这些文件，因为权限是使用标准的简单Unix权限设置授予的。一种更好的方法是使用非根容器，这涉及在不同的Linux用户ID(UID)下运行容器。这更容易做到，但它意味着构建一种方法来保护每个容器，使用组ID(GID)或UID作为权限检查。在这里我们遇到了另一个问题：对于非根容器，本地卷不起作用，除非用于运行容器的UID具有访问/var/lib/docker/volumes目录的权限。如果不这样做，则无法访问或创建数据。打开这个目录会有安全风险；但是，没有固有的方法来按卷设置个人权限。如果我们看一下外部存储是如何挂载到容器的，许多解决方案只是简单地提供块设备(LUN)并将文件系统格式化为运行容器的主机。然后将其作为挂载点暴露给容器。此时，可以在容器内设置目录和文件的安全性，减少我们已经讨论过的问题。但是，如果此LUN/卷在其他地方重复使用，则无法对其安装和使用方式进行安全控制，因为没有直接内置到容器/卷映射中的安全模型。一切都取决于信任主机上运行的命令。这是另一个问题：缺乏多租户。当我们运行容器时，每个容器实例可能会运行一个单独的应用程序。在传统的存储部署中，分配给容器的存储应该有一定程度的分离，以确保数据不会被无意或恶意访问。目前没有简单的方法可以在主机级别做到这一点，只能信任编排工具来运行容器并映射到数据。寻找解决方案这里的一些问题是Linux/Unix特有的。例如，挂载命名空间的抽象为我们的数据提供了不同的入口点，然而，没有权限的抽象——我不能将用户1000映射到用户1001——没有与每个文件和目录关联的物理升级ACL（访问控制列表）数据。大规模的ACL更改可能会影响性能。对于本地卷，Docker只需在主机目录上设置权限，新卷与正在启动的容器的UID相匹配。外部卷提供了一个很好的机会，可以摆脱运行容器的主机中的权限结构。然而，这意味着我们需要一种机制来将卷数据映射到特定容器实例中的已知可信应用程序。请记住，容器没有固有的“身份”，可以随意启动和停止。这使得很难确定任何单个容器是否是数据卷的所有者。目前主要的解决方案是依靠编排平台来管理容器的运行。我们相信这些系统可以映射卷和容器，并且在很多方面，它不像传统的SAN存储或虚拟磁盘映射到虚拟机。但容器的不同之处在于它们的可移植性和对扩展到公共云的安全机制的需求。我们还有很多工作要做。对于Docker来说，收购存储初创公司Infinit可能会阐明他们如何保护持久数据。这可能意味着开发供所有供应商使用的接口。
