Docker数据安全隐患剖析
发布时间：2022-05-18 10:01:41 所属栏目：安全 来源：互联网
导读：Docker容器为应用的编写、分发和部署带来真正翻天覆地的变化。容器的目的是灵活性，让应用可按需启用，无论何时以及何地。当然无论我们在哪里使用应用，我们都需要数据。 另外，本地存储可作为安装点映射到容器。在这种情况下，docker run命令可指定本地目录
|
Docker容器为应用的编写、分发和部署带来真正翻天覆地的变化。容器的目的是灵活性，让应用可按需启用，无论何时以及何地。当然无论我们在哪里使用应用，我们都需要数据。 另外，本地存储可作为安装点映射到容器。在这种情况下，“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。 （编辑：东莞站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
站长推荐