容器基础设施所面临的风险

容器基础设施面临的风险

我们从容器镜像、活动容器、容器网络、容器管理程序接口、宿主机操作和软件漏洞六个方面来分析容器基础设施可能面临的风险

在这里插入图片描述

容器镜像存在的风险

所有容器都来自容器镜像。与虚拟机镜像不同的是，容器镜像是一个不包含系统内核的联合文件系统（Unionfs），几位进程的正常运行提供基本、一致的文件环境。另外，容器是动态的，镜像是静态的，考虑到这一点，我们从镜像的内容和镜像的流通、使用等几方面开展分析。

不安全的第三方组件

随着容器技术的成熟和流行，大部分流行的开源软件都提供了 Dockerfile 和容器镜像。在实际的容器化应用开发过程中，人们很少从零开始构建自己的业务镜像,而是将Docker Hub 上的镜像作为基础镜像，在此基础上增加自己的程序或者代码，然后打包成最终的业务镜像并上线运行。例如，为了提供Web服务，开发人员可能会在Django的镜像的基础上，加上自己编写的python代码，然后打包成Web后端镜像。

毫无疑问，这种积累和复用减少了造轮子的次数，大大提高了开发效率和软件质量，推动了现代软件工程的发展。如今，一个较为普遍的情况是，用户自己的代码依赖若干开源组件，这些开源组件本身又有着许多而复杂的依赖树，甚至最终打包好的镜像业务还包含很多用不到的开源组件。这导致许多开发者可能根本不知道自己的镜像中包含多少及哪些组件。包含的组件越多，可能存在的漏洞就越多，大量引入第三方组件的同时也大量映入了风险。2020年，在使用最为广泛的镜像仓库Docker Hub中，约有51%的镜像包含了一个危险的（critical）级别的安全漏洞。这意味着，使用这些或基于这些镜像制作的容器镜像都将面临着安全风险。

大肆传播的恶意镜像

除了有漏洞的可信开源镜像外，以 Docker Hub 为代表的公共镜像仓库中可能还存在着一些恶意镜像，如果使用了这些镜像作为基础镜像，那么这种行为无异于引狼入室，所有基于这些基础恶意镜像开发的镜像都将面临着重大的安全风险和传播风险。

极易泄露的敏感信息

容器的先进性之一在于它提供了“一次开发，随处部署”的可能性，大大的降低了开发者和运维人员的负担。但为了开发和调试方便，开发者可能会将敏感信息，如数据库的密码、证书和私钥等内容直接写到代码中，或者以配置文件的形式存放。构建镜像时，将这些敏感内容一并打包进镜像，甚至上传到公开的镜像仓库，从而造成敏感数据泄露。

活动容器存在的风险

那么，当容器镜像运行起来以后，又将面临哪些风险呢？

不安全的容器应用

与传统的IT环境类似，容器环境下的业务代码本身也可能存在Bug甚至安全漏洞。容器技术并不能解决这些安全问题。无论是SQL注入代码、XSS和文件上传漏洞，还是反序列化或缓冲区溢出漏洞，它们都有可能出现在容器化的应用中。容器在默认情况下连接到桥接网桥提供的子网中。如果在启动时配置了端口映射，容器就能提供对外服务，在这种情况下，容器所提供的服务就有可能被外部的攻击者访问和利用，从而导致容器被入侵。

不受限制的资源共享

与其他虚拟化技术一样，容器并非空中楼阁。既然运行在宿主机上，容器必然要使用宿主机提供的各种资源–计算资源、存储资源等。如果容器使用了过多的资源，就会对宿主机及宿主机上的其他容器造成影响，甚至形成资源耗尽型攻击。然而，在默认情况下，Docker 并不会对容器的资源使用进行限制，也就是说，默认配置启动的容器理论上能够无限使用宿主机的CPU、内存、硬盘等资源。

不安全的配置与挂载

"配置与挂载"指的是容器在启动时带有配置选项和挂载选项，我们知道，作为一种虚拟化技术，容器的核心是两大隔离机制：

Linux命名空间机制：在文件系统、网络、进程、进程间通信和主机名等方面实现隔离
cgroups机制：在 CPU、内存和硬盘等资源方面实现隔离

除此以外，Capabilities、Seccomp和AppArmor等机制通过限制容器内进程的权限和系统调用的访问能力，进一步提高了容器的安全性

为什么配置和挂载也有可能导致风险呢？因为通过简单的配置和挂载，容器的隔离性将被轻易打破，例如：

通过配置 --privikeged 选项，容器将不受Seccomp 等安全机制的限制，容器内root权限将变得与宿主机上的root权限无异
通过配置 --net=host，容器将与宿主机处于同一网络命名空间（网络隔离被打破）
通过配置 --pid=host，容器将与宿主机处于同一进程命名空间（进程隔离被打破）
通过执行挂载 --volume /:/host,宿主机根目录将被挂载到容器内部（文件系统隔离被打破）

容器网络存在的风险

我们刚刚提到，默认情况下每个容器处于自己独立的网络命名空间内，与宿主机之间存在隔离。然而，每个容器都处于由 docker0 网桥构建的同一局域网内，彼此之间互相连通。从理论上来讲，容器之间可能会发生网络攻击，尤其是中间人攻击等局域网内常见的攻击方法

事实上而言也确实如此，容器内的root用户虽然被Docker 禁用了许多权限（Capabilities机制），但它目前依然具有CAP_NET_RAW 权限，具备构造并发送 ICMP、ARP等报文的能力。因此ARP欺骗、DNS劫持等中间人攻击是可能发生在容器网络内的。

容器管理程序接口存在的风险

Socket 是 Docker 守护进程接受请求及返回响应的应用接口，Docker 守护进程主要监听两种形式的Socket：UNIX socket 和 TCP socket。安装完成启动后，Docker 守护进程默认只监听 UNIX socket。

UNIX socket

为什么 UNIX socket 会存在安全风险呢？他的问题主要与Docker 守护进程的高权限有关：Docker 守护进程默认以宿主机的root权限运行。只要能够与该UNIX socket 进行交互，就可以借助Docker 守护进程以root 权限在宿主机上执行任意的命令，目前来讲，相关的风险主要有两个：

许多用户为了方便，不想每次输入密码时使用sudo或su，就将普通用户也加入了docker 用户组，这使得普通用户有权限直接访问UNIX socket。那么一旦攻击者获得了这个普通用户的权限，他就能够借助 Docker UNIX socket 在宿主机上提升为root权限
为了实现在容器内管理容器，用户可能会将Docker UNIX socket 挂载到容器内部，如果该容器被入侵，攻击者就能借助这个socket 实现容器逃逸，获得宿主机的root 权限

TCP socket

在较新版本的Docker 中，Docker 守护进程默认不会监听TCP socket。用户可以通过配置文件来设置Docker 守护进程开启对TCP socket的监听，默认监听端口一般是 2375.然而默认情况下，Docket 守护进程 TCP socket 的访问是无加密的且无认证的。因此，任何网络可达的访问者都可以通过该TCP socket 来对 Docker 守护进程下发命令。列如，以下命令能够列出IP为192.168.41.10的主机上的所有活动容器：

docker -H tcp://192.168.41.10:2375 ps

显而易见，攻击者也能够通过这样的TCP socket 对目标主机上的Docker 守护进程下发命令，从而实现对目标主机的控制。控制方式与通过UNIX socket 的控制类似。

宿主机操作系统存在的风险

与虚拟机不同，作为一种轻量级虚拟化的技术，容器通常与宿主机共享内核。这意味着，如果宿主机内核本身存在的安全漏洞，理论上，这些漏洞是能够在容器内进行利用的。通过这些漏洞，攻击者可能实现权限提升，甚至从容器中逃逸，获得宿主机的控制权。列如，在存在CVE-2016-5195 脏牛漏洞的容器环境中，攻击者可以借助该漏洞向进程 vDSO 区域写入恶意代码，从而实现容器逃逸。