【发布时间】:2018-04-13 09:12:08
【问题描述】:
我知道,多个 Docker 容器可以在同一主机上使用,但它们可以像隔离实例一样安全地使用吗?我想运行多个安全和沙盒容器,这样任何容器都不会影响或访问其他容器。
例如,我可以为监听不同端口的 nginx 和 apache 容器提供服务,并且完全相信每个容器只能访问自己的文件、资源等吗?
【问题讨论】:
标签: security docker docker-container
我知道,多个 Docker 容器可以在同一主机上使用,但它们可以像隔离实例一样安全地使用吗?我想运行多个安全和沙盒容器,这样任何容器都不会影响或访问其他容器。
例如,我可以为监听不同端口的 nginx 和 apache 容器提供服务,并且完全相信每个容器只能访问自己的文件、资源等吗?
【问题讨论】:
标签: security docker docker-container
从某种意义上说,您是在问价值百万美元的容器问题,而且要明确的是,恕我直言,对于“平台/技术是否足够安全”这个问题,没有非黑即白的答案。这是一个足够大(而且很重要)的问题,初创公司名单——更不用说他们收到的资金数量——围绕容器安全是一个可观的数字!
正如另一个答案中所述,容器的隔离是通过各种 Linux 内核功能(命名空间和 cgroup)实现的,为这些功能增加更多安全性是另一组技术,例如 seccomp, apparmor(或 SELinux)、用户命名空间或容器运行时和安装它的节点的一般强化(例如通过CIS benchmark guidelines)。开箱即用的默认安装和默认运行时参数可能不够足以普遍信任 Linux 的内核隔离原语。但是,这在很大程度上取决于您在容器工作负载中运行的什么的信任级别。例如,这一切都在一个组织内部吗?是否可以从外部来源提交工作负载?显然,可能性的范围可能会极大地影响您的信任程度。
如果您的用例可能很窄(例如,您提到来自 nginx 或 apache 的 Web 服务内容),并且您愿意做一些工作来处理基础映像的创建、最小化和强化;再加上一个--readonly 根文件系统和一个限制apparmor 和seccomp 配置文件的能力,绑定挂载在服务内容+ 可写区域,没有可执行文件和非特权用户的所有权——所有这些东西加在一起可能足够了 用于特定用例。
然而,目前未知的安全逃逸并不能保证将来会成为 Linux 容器的“0day”,这导致了将容器隔离与实际硬件结合起来的轻量级虚拟化的推广通过来自hyper.sh 或Intel Clear Containers 的垫片的级虚拟化,作为两个示例。这是在使用另一个容器运行时运行完整的虚拟化操作系统和使用单个节点上的单个守护程序信任内核隔离之间的一种愉快的媒介。添加此隔离层仍然会产生性能成本和内存开销,但它远低于完全虚拟化的操作系统,并且工作继续使这对性能的影响更小。
有关可用于调整容器安全性的所有“旋钮”的更深入信息集,我去年多次在Skillsmatter 的slideshare 和via video 上提供了一个演示文稿。
Aaron Grattafiori 的令人难以置信的彻底“Understanding and Hardening Linux Containers”也是一个很好的资源,其中包含许多相同主题的详尽细节。
【讨论】:
文件系统隔离(以及内存和进程隔离)是 docker 容器的核心功能,基于Linux Kernel abilities。
但是,如果您想完全确定,您可以将容器部署在不同的节点上(每个节点都由自己的 docker 守护程序管理),每个节点都是您主机上的一个 VM(虚拟机),以确保一个完整的沙箱。
然后docker swarm 或Kubernetes 将能够编排这些节点及其容器,并使它们进行通信。
当您只有几个链接的容器时,通常不需要这样做:它们应该能够由单个 docker 守护进程单独管理。您可以使用user namespace 进行额外隔离。
另外,使用节点来分隔容器意味着同一台机器中有不同的机器或不同的虚拟机。
虚拟机和容器的一大区别是虚拟机将抢占资源(分配固定的最小数量的磁盘/内存/CPU),这意味着你不能启动一百个虚拟机,每个容器一个。与单个 docker 实例相反,如果容器不执行任何操作,则根本不会消耗太多磁盘空间/内存/CPU。
【讨论】: