容器安全-核心概述

文章摘要

本文探讨了容器安全的四个核心类别，包括环境基础设施安全、镜像安全、运行时安全和生态安全。尽管 EDR 能提供主机安全层面的部分防护，但无法覆盖容器的镜像安全和生态安全。容器的镜像安全和生态安全问题，如镜像漏洞、恶意镜像、容器能力限制、强制访问控制等，都需要专门的解决方案。文章建议结合 EDR 的优势，针对容器环境的特殊性，扩展和增强安全能力，以实现全面的容器安全防护。

文章正文

Docker 是目前最具代表性的容器技术之一，对云计算及虚拟化技术产生了颠覆性的影响。

以 Docker 为代表的容器技术，直接运行于宿主机操作系统内核，因此对于容器安全，很多人会有着这样的疑问：EDR（Endpoint Detection and Response）等主机安全方案，能否直接解决容器安全的问题？

概括来说，容器 / 容器云安全，可以包括以下四个类别：
第一，就是容器环境基础设施的安全性，比如主机上的安全配置是否会影响到其上面运行的容器，主机上的安全漏洞是否会影响到容器，主机上的恶意进程是否会影响到容器，容器内的进程是否可以利用到主机上的安全漏洞等。
第二，是容器的镜像安全，这里包括镜像中的软件是否存在安全漏洞，镜像在构建过程中是否存在安全风险，镜像在传输过程中是否被恶意篡改等。
第三，是容器的运行时安全，比如运行的容器间隔离是否充分，容器间的通信是否是安全的，容器内的恶意程序是否会影响到主机或者其它容器，容器的资源使用情况是否是安全的等。
第四，是整个容器生态的安全性，比如 Docker/Kubernetes 自身的安全性如何，ServiceMesh/Serverless 对容器安全有什么影响，容器中安全密钥的管理和传统环境有什么不同，容器化后的数据隐私保护跟传统的数据隐私保护是否一致等。

从上述容器安全的核心问题来看，镜像的概念相对来说是容器所特有的，因此对于容器的镜像安全，EDR 是一定不会覆盖的。另外就是容器的生态安全，这块更多的是容器相关的技术栈带来的安全机遇和挑战，因此典型的 EDR 产品肯定也是无能为力的。

行文至此，开篇所提出的问题 “EDR 等主机安全方案，能否直接解决容器安全的问题？” 就已经有了初步的答案：肯定是不可以的。

EDR 既然现有的 EDR 产品不能直接用来解决容器安全的所有问题，那么对于容器环境面临的前述安全问题，EDR 能否解决其中的一部分呢？

先看一下 EDR 的定义是什么？典型的 EDR 产品又能做些什么？

Gartner 对于 EDR 给出了如下的定义：
EDR tools provide an ability to analyze and search detailed, current and historic endpoint data for traces of malicious activity and bring the high - risk data to an analyst's attention with additional capabilities to actively respond to those activities if necessary.

EDR 工具集提供一种分析 / 检索更详细 / 实时 / 历史的终端数据能力，进而发现恶意活动的痕迹，让安全分析师关注高风险的数据，并且在必要时积极的进行响应。

Gartner 的这个定义，看上去似乎有些抽象，简单一点的解释就是：通过收集终端上的各种数据，在这些数据中分析并发现恶意的活动，进而采取相应的防御手段。那么都会收集什么样的数据？收集到了这些数据又能发现什么样的恶意行为？

下面从 EDR 典型的设计架构开始，进行具体的解释。

1 典型架构
下图展示了 Gartner 给出的典型 EDR 架构，其主要包括两个部分：一部分是部署在待防护终端上的代理（Agent），这里的终端既可以是虚拟化的云主机，也可以是物理的服务器主机，还可以是办公的 PC 机，当然甚至也可以是更轻量的 IoT 终端设备（跟容器的可运行环境基本是一致的）；另一部分则是控制平台，这里的控制平台既可以通过本地的集中化方式部署实现，也可以部署在云端，或者是采用云端和本地化混合的部署方式，不同的安全能力部署在不同的位置。

2 代理都收集什么样的数据？
（1）终端设备的基本元数据。包括 CPU、内存、网卡（IP、MAC）、操作系统、安装软件、硬件数据、Device 数据等。
（2）网络数据。包括终端设备上的 DNS 和 ARP 表以及其它实时网络数据、开放的端口以及相关的进程数据、终端的网络连接数据、可访问终端的 URL 数据等。
（3）运行时数据。包括终端上运行的进程 / 线程以及其对应的元数据、用户登录注销数据、进程间通信（IPC）数据、进程行为数据（例如数据读写）等。
（4）存储数据。文件（通常只包含特定的文件或者可执行文件）以及文件元数据（比如文件名 / 大小 / 类型、校验和等）、文件变更信息、syslog、主引导记录（MBR）信息等。
（5）其它数据。比如加载的 DLL、激活的设备驱动程序、已加载的内核模块、CMD 或者 PowerShell 历史命令等数据。

3 EDR 能发现什么恶意行为？
基于上述收集到的数据，EDR 通常可以应用于以下安全场景：
（1）主机风险检测。结合多种安全基线与规范要求，通过账户、网络、进程、系统配置等多维度风险检测，系统全面的发现不符合安全管理规范的主机。
（2）可疑行为检测。通过实时监控主机关键的风险入口，结合威胁情报以及相关安全规则，对端口扫描攻击、暴力破解攻击、恶意脚本攻击、系统漏洞攻击、Webshell 攻击等可疑行为进行高效快速的检测发现。
（3）威胁狩猎。平台收集的各种层面的数据，可以提供关于主机健康状况的大量信息。通过正确的筛选、挖掘，利用这些数据可以发现、追踪到更多潜在的威胁行为，主动的进行威胁捕获。
（4）阻止恶意行为。例如主机的微隔离，通过控制主机的进出站流量，实现对异常主机的隔离。

4 对比容器安全，有哪些是无法满足的？
根据前文对于容器安全核心问题的描述，以及 EDR 的功能概述，除了容器的镜像安全和容器生态安全之外，在主机安全以及容器运行时安全方面，EDR 确实能够不同程度的提供相关的安全检测和防护能力。

相同点：
（1）从功能层面，容器安全和 EDR 都要求实现其对应主机的安全，包括资源层面、权限层面、网络层面等多个方面，因此，对于容器安全来说，EDR 产品可以 100% 的进行功能的复用，保障容器环境的主机安全。
（2）从技术层面，在二者的主流技术实现路径上，均采用了 “平台 + 探针” 的技术架构，可以以最小的成本开销，实现安全能力的复用和整合。

不同点：
二者之间的不同点，主要来源于容器环境利用 namespace 和 cgroup 做了一层资源的隔离，因此：
（1）当前 EDR 所监测的数据，仅限于主机层面，对于容器内部的行为和活动，是没有有效的进行关联的，比如容器内进程行为的监控、容器内用户权限的监控等。
（2）在网络安全上，当前 EDR 更关注于主机的进出站网络流量，也就是主机物理网卡上的流量，而在容器环境中，还有相当大比例的网络通信存在于主机内部的容器之间，因此，这种容器间的东西向网络安全防护，当前 EDR 也是无法实现的。
（3）权限管理。容器环境之上，通常运行的基于微服务架构的业务应用，因此有着复杂的权限管理以及访问控制策略，虽然这些通常是由容器业务平台进行设计和实现，但是作为安全服务，是需要有能力对其进行监控和异常检测的。而 EDR 在这方面几乎还只停留在主机资源的权限管理上，这一点也是无法满足需求的。
（4）对于容器内应用的密钥管理、密钥隐藏等容器业务强相关的安全需求，EDR 也是无法满足的。

考虑到容器环境在技术实现上的特点，通过 EDR 实现容器安全确实有着一定的优势。但是考虑到容器环境又有着很多特殊性，在安全上还有很多特定的需求，因此，直接利用 EDR 去应对容器安全的问题，还是远远不够的。

比较好的解决办法就是，结合各家之所长，一方面有效的利用 EDR 在主机安全上可以做到的全面、深入的安全检测能力；另一方面，结合容器环境特定的需求，实现安全能力的有效扩展和延伸。这样，就可以尽可能高效的实现容器环境的安全防护了。

如何对容器安全能力扩展与延伸？

对于 Docker 容器在应用中可能面临的安全问题和风险进行了研究，并将 Docker 容器应用环境中的安全机制与相关解决方案分为容器虚拟化安全、容器安全管理、容器网络安全三部分进行分析。

一、从虚拟化安全到容器安全
1、传统虚拟化技术
虚拟化技术是实现硬件基础设施资源的充分利用、合理分配和有效调度的重要技术手段。例如，在基于 OpenStack 的典型 IaaS 服务中，云服务提供商可通过搭建设备集群建立资源池，并将服务器、存储和网络等底层资源进行弹性虚拟化提供给租户。
传统虚拟化技术以虚拟机为管理单元，各虚拟机拥有独立的操作系统内核，不共用宿主机的软件系统资源，因此具有良好的隔离性，适用于云计算环境中的多租户场景。

2、容器技术
容器技术可以看作一种轻量级的虚拟化方式，将应用与必要的执行环境打包成容器镜像，使得应用程序可以直接在宿主机（物理机或虚拟机）中相对独立地运行。容器技术在操作系统层进行虚拟化，可在宿主机内核上运行多个虚拟化环境。相比于传统的应用测试与部署，容器的部署无需预先考虑应用的运行环境兼容性问题；相比于传统虚拟机，容器无需独立的操作系统内核就可在宿主机中运行，实现了更高的运行效率与资源利用率。

Docker 是目前最具代表性的容器平台之一，它模糊了传统的 IaaS 和 PaaS 的边界，具有持续部署与测试、跨云平台支持等优点。在基于 Kubernetes 等容器编排工具实现的容器云环境中，通过对跨主机集群资源的调度，容器云可提供资源共享与隔离、容器编排与部署、应用支撑等功能。

Docker 容器技术以宿主机中的容器为管理单元，但各容器共用宿主机内核资源，分别通过 Linux 系统的 Namespaces 和 CGroups 机制实现资源的隔离与限制。

1）Namespaces
为了保证容器进程之间的资源隔离，避免相互影响和干扰，Linux 内核的 Namespaces（命名空间）机制提供了 UTS、User、Mount、Network、PID、IPC 等命名空间实现了主机名、用户权限、文件系统、网络、进程号、进程间通信等六项资源隔离功能。通过调用 clone () 函数并传入相应的系统调用参数创建容器进程，可实现对应资源内容的隔离，具体情况如表 1 所示。

表 1：Namespaces 隔离机制
命名空间 系统调用参数 隔离内容 Linux 内核版本
UTS CLONE_NEWUTS 主机名和域名 2.6.19
IPC CLONE_NEWIPC 信号量、信息队列和共享内存 2.6.19
PID CLONE_NEWPID 进程编号 2.6.24
Network CLONE_NEWNET 网络设备、网络栈、端口等 2.6.29
Mount CLONE_NEWNS 挂载点（文件系统） 2.4.19
User CLONE_NEWUSER 用户和用户组 3.8

对于某个进程而言，可通过查看 /proc/[PID]/ns 文件，获取该进程下的命名空间隔离情况。其中，每一项命名空间都拥有一个编号对其进行唯一标识，如果宿主机中两个进程指向的命名空间编号相同，则表示他们同在一个命名空间之下。

2）CGroups
CGroups（Control Groups，控制组）机制最早于 2006 年由 Google 提出，目前是 Linux 内核的一种机制，可以实现对任务组（进程组或线程组）使用的物理资源（CPU、内存、I/O 等）进行限制和记录，通过多种度量标准为各个容器相对公平地分配资源，以防止资源滥用的情况。

在实际应用中，CGroups 会为每个执行任务创建一个钩子，在任务执行的过程中涉及到资源分配使用时，就会触发钩子上的函数并对相应的资源进行检测，从而对资源进行限制和优先级分配。

CGroups 提供了资源限制（Resource Limitation）、优先级分配（Prioritization）、资源统计（Accounting）、任务控制（Control）四个功能，包含 blkio、cpu、cpuacct、cpuset、devices、freezer、memory、perf_event、net_cls、net_prio、ns、hugetlb 等子系统，每种子系统独立地控制一种资源，可分别实现块设备输入 / 输出限制、CPU 使用控制、生成 CPU 资源使用情况报告、内存使用量限制等功能。几个主要子系统的具体功能如表 2 所示。

表 2：CGroups 子系统
子系统 功能
blkio 为块设备（如磁盘、固态硬盘等物理驱动设备）设定输入 / 输出限制
cpu 通过调度程序控制任务对 CPU 的使用
cpuacct 生成任务对 CPU 资源使用情况的报告
cpuset 为任务分配独立的 CPU 和内存
devices 开启或关闭任务对设备的访问
freezer 挂起或恢复任务
memory 设定任务对内存的使用量限制，生成任务对内存资源使用情况的报告

3、安全性
传统虚拟化技术与 Docker 容器技术在运行时的安全性差异主要体现在隔离性方面，包括进程隔离、文件系统隔离、设备隔离、进程间通信隔离、网络隔离、资源限制等。

在 Docker 容器环境中，由于各容器共享操作系统内核，而容器仅为运行在宿主机上的若干进程，其安全性特别是隔离性与传统虚拟机相比在理论上与实际上都存在一定的差距。

二、Docker 容器安全风险分析
根据 Docker 容器的主要特点及其在安全应用中的实际问题，本文将 Docker 容器技术应用中可能存在的技术性安全风险分为镜像安全风险、容器虚拟化安全风险、网络安全风险等类型进行具体分析。

1、镜像安全风险
Docker 镜像是 Docker 容器的静态表示形式，镜像的安全决定了容器的运行时安全。

Docker 容器官方镜像仓库 Docker Hub 中的镜像可能由个人开发者上传，其数量丰富、版本多样，但质量参差不齐，甚至存在包含恶意漏洞的恶意镜像，因而可能存在较大的安全风险。具体而言，Docker 镜像的安全风险分布在创建过程、获取来源、获取途径等方方面面。

1）Dockerfile 安全问题
Docker 镜像的生成主要包括两种方式，一种是对运行中的动态容器通过 docker commit 命令进行打包，另一种是通过 docker build 命令执行 Dockerfile 文件进行创建。为了确保最小安装原则，同时考虑容器的易维护性，一般推荐采用 Dockerfile 文件构建容器镜像，即在基础镜像上进行逐层应用添加操作。

Dockerfile 是包含用于组合镜像命令的文本文件，一般由基础镜像信息（FROM）、维护者信息（MAINTAINER）、镜像操作指令（RUN、ADD、COPY 等）、容器启动时执行指令（CMD 等）四个部分组成，Docker 可通过读取 Dockerfile 中的命令创建容器镜像。

Dockerfile 文件内容在一定程度上决定了 Docker 镜像的安全性，其安全风险具体包括但不限于以下情况：
如果 Dockerfile 存在漏洞或被插入恶意脚本，那么生成的容器也可能产生漏洞或被恶意利用。例如，攻击者可构造特殊的 Dockerfile 压缩文件，在编译时触发漏洞获取执行任意代码的权限。
如果在 Dockerfile 中没有指定 USER，Docker 将默认以 root 用户的身份运行该 Dockerfile 创建的容器，如果该容器遭到攻击，那么宿主机的 root 访问权限也可能会被获取。
如果在 Dockerfile 文件中存储了固定密码等敏感信息并对外进行发布，则可能导致数据泄露的风险。
如果在 Dockerfile 的编写中添加了不必要的应用，如 SSH、Telnet 等，则会产生攻击面扩大的风险。

2）镜像漏洞
对于大多数一般的开发者而言，通常需要获取一系列基础镜像进行容器云的部署和进一步开发，因此，基础镜像的安全性在一定程度上决定了容器云环境的安全性。

镜像漏洞安全风险具体包括镜像中的软件含有 CVE 漏洞、攻击者上传含有恶意漏洞的镜像等情况。

① CVE 漏洞
由于镜像通常由基础操作系统与各类应用软件构成，因此，含有 CVE 漏洞的应用软件同样也会向 Docker 镜像中引入 CVE 漏洞。

镜像的获取通常是通过官方镜像仓库 Docker Hub 或网易、阿里云等提供的第三方镜像仓库。然而，根据对 Docker Hub 中镜像安全漏洞的相关研究，无论是社区镜像还是官方镜像，其平均漏洞数均接近 200 个，包括 nginx、mysql、redis 在内的常用镜像都含有高危漏洞。

② 恶意漏洞
恶意用户可能将含有后门、病毒等恶意漏洞的镜像上传至官方镜像库。2018 年 6 月，安全厂商 Fortinet 和 Kromtech 在 Docker Hub 上发现 17 个包含用于数字货币挖矿恶意程序的 Docker 镜像，而这些恶意镜像当时已有 500 万次的下载量。目前，由于 Docker 应用在世界范围内具有广泛性，全网针对 Docker 容器的攻击很多都被用于进行数字货币挖矿，为攻击者带来实际经济利益，损害 Docker 用户的正常使用。

3）镜像仓库安全
作为搭建私有镜像存储仓库的工具，Docker Registry 的应用安全性也必须得到保证。镜像仓库的安全风险主要包括仓库本身的安全风险和镜像拉取过程中的传输安全风险。
仓库自身安全：如果镜像仓库特别是私有镜像仓库被恶意攻击者所控制，那么其中所有镜像的安全性将无法得到保证。例如，如果私有镜像仓库由于配置不当而开启了 2357 端口，将会导致私有仓库暴露在公网中，攻击者可直接访问私有仓库并篡改镜像内容，造成仓库内镜像的安全隐患。