| 编辑推荐: |
本文主要介绍了Docker容器生命周期安全问题及Docker容器安全现状改善方法。
本文来自于微信公账号安全牛，由火龙果软件Linda编辑、推荐。 |
|
一、前言
毫无疑问，容器是当前云计算的热门主流技术之一。
Docker 通过把应用的运行时环境和应用打包在一起，解决了部署环境依赖等问题；它消除了编译、打包与部署、运维之间的鸿沟，有助于提高应用开发、运维效率：总之，它与
DevOps 理念不谋而合，受到了很多企业的推崇。
当然 Docker 容器的生命周期中也存在着不少安全隐患，比如容器自身的问题、容器镜像的问题，还有容器在运行时暴露的问题等等。因此，本文将对
Docker 容器生命周期的安全问题及相应的改善方法进行若干探讨，挂一漏万，抛砖引玉，希望各位读者予以批评指正！
二、Docker容器生命周期安全问题
在 Docker 容器生命周期内的多个阶段均可能引入安全问题，本章将分模块对这些安全问题进行浅析，纲举目张，我们先了解一下
Docker 容器全生命周期安全管控的架构，如图1所示。
图1. Docker 容器全生命周期安全管控架构
这张图片可以反映 Docker 对其核心——“镜像” 的 “Build, Ship and Run”（构建镜像、传输镜像与运行容器）操作；Docker的应用环境可被分为“非生产环境”和
“生产环境” 这两类。
非生产环境与 Dev（开发）强相关，而生产环境则与Ops（运维）强相关。非生产环境内的主要管控点是镜像深度扫描，在生产环境做容器编排时需要从非生产环境拉取并运行Docker镜像，因此镜像运行控制也是一个主要管控点。
生产环境内的主要管控点是容器系统入侵检测与防护以及容器网络入侵检测与防护。同时，应在Docker容器全生命周期中的各个阶段将合规基线问题作为重要的管控点。
下面从Docker容器安全的各个主要管控点出发，列举部分它们所应对的安全问题。
1、镜像深度扫描
在做镜像深度扫描时，应重视的安全问题包括但不限于：
镜像中的操作系统软件包与应用程序依赖项包含已知CVE漏洞
镜像的应用目录被植入Webshell
镜像敏感信息泄露
镜像完整性校验问题
Dockerfile中存在不安全的写法（Dockerfile是Docker镜像的构建脚本）
2、镜像运行控制
在做镜像运行控制时，应重视的安全问题包括但不限于：
镜像完整性校验问题
特权模式共享root权限
内存配额未被限制
CPU优先级未被限制
存储空间配额未被限制
在启用容器时使用Host网络模式
3、容器系统入侵检测与防护
在做容器系统入侵检测与防护时，应重视的安全问题包括但不限于：
未隔离文件系统
调用有漏洞的系统内核函数
拒绝服务攻击
4、容器网络入侵检测与防护
在做容器网络入侵检测与防护时，应重视的安全问题包括但不限于：
容器间的局域网攻击
Remote API接口安全
Docker缺陷架构与安全机制纰漏
微服务架构Web应用安全问题
5、安全合规基线
为了应对Docker安全问题，应重视的安全问题包括但不限于：
内核级别
网络级别
镜像级别
容器级别
文件限制
能力限制
6、Docker及其配套软件漏洞
在使用Docker及其配套软件时，应重视的安全问题包括但不限于：
Docker自身漏洞
K8S(Kubernetes)等编排应用自身漏洞
镜像仓库自身漏洞
注：Docker及其配套软件漏洞对Docker容器安全问题有着较深的影响，因而将之独立成一个管控点点。可将“所使用的Docker及其配套软件的版本不受已知漏洞影响”作为一条“安全合规基线”。
三、浅谈Docker容器安全现状改善方法
面对 Docker 容器安全的挑战，可以 “分而治之”，对各个阶段的安全管控点进行管控。在实施管控时，也可划分优先级，优先考虑较为重要的管控点，推迟考虑较为次要的管控点（例如，“镜像运行控制”
管控点与用户对 Docker 的使用方式有较大关联。可以在安全产品中对用户的危险操作进行告警，但不一定要进行阻断。Docker
容器安全产品应注重对由用户的不安全使用方式催生的安全问题进行防御）。
下面，结合行业实践经验梳理针对 “镜像深度扫描”、“容器系统入侵检测与防护”、“容器网络入侵检测与防护”
与 “安全合规基线” 的管控方法。
01“镜像深度扫描” 管控方法
在使用 Docker 镜像之前使用 Docker 镜像扫描器有助于发现 Docker 镜像的安全性问题。基于此，知名的开源镜像仓库
Harbor 就集成了镜像扫描器，如图 2 所示。
图2. 知名开源镜像仓库Harbor集成了镜像扫描器
现有镜像扫描工具基本都具备了 “对软件漏洞进行扫描” 的基础功能。部分开源项目或商业平台具备如下特殊功能：
对木马、病毒、恶意软件或其他恶意威胁进行静态分析
对主流编程语言的代码安全问题进行静态发现（与开发工作流紧密结合）
对Dockerfile进行检查
对凭据泄露进行检查
因为 Docker 镜像是 Docker 容器的模板，所涉及的攻击面较大，并且有的安全风险不易被扫描器所发现，所以现阶段的
“Docker镜像扫描”的做法仍不能保障 Docker 镜像的安全性，建议人工介入检查（可结合“docker
inspect” 与 “docker history” 等命令查看镜像的部分信息）。
02“容器系统入侵检测与防护” 管控方法
加强 Docker 容器与内核层面的隔离性有助于强化 “容器系统入侵检测与防护”。比如 Docker
社区开发的安全特性、Linux 运行时方案、异常行为检测应用以及 “容器+全虚拟化” 方案，如图 3
所示。
图3. “容器系统入侵检测与防护” 管控方法
Docker 社区开发了针对 Linux 的 Cgroup 和 Namespce 的安全特性（Cgroup可用于限制CPU、内存、块设备I/O（具体可参考“docker
run”命令的参数）；Namespace 可用于对 PID、mount、network、UTS、IPC、user
等内核资源进行隔离；Cgroup 对系统资源的隔离已经比较完善了，而 Namespace 的隔离还不够完善（甚至不可能完善，因为这是共享内核导致的固有缺陷）。
部分可借鉴的Linux运行时方案如下：
(1) Capability：令某程序拥有哪些能力；
(2) Selinux：定义了系统中每一个用户、进程、应用、文件访问及转变的权限，然后使用一个安全策略来控制这些实体（即用户、进程、应用和文件）之间的交互，安全策略指定了如何严格或者宽松地进行检查；
(3) Apparmor：设置执行程序的访问控制权限（可限制程序读/写某个目录文件，打开/读/写网络端口等）;
(4) Secomp：应用程序的沙盒机制，以白名单、黑名单方式限定进程对系统进行调用；
(5) Grsecurity：linux 内核补丁，增强内核安全性。
部分可借鉴的容器环境异常行为检测开源应用如下：
(1) Sysdig Falco：一款为云原生平台设计的进程异常行为检测工具，支持接入系统调用事件和
Kubernetes 审计日志；
(2) cAdvisor：可以对节点机器上的资源及容器进行实时监控和性能数据采集，包括 CPU 使用情况、内存使用情况、网络吞吐量及文件系统使用情况。
“容器+全虚拟化” 方案也是 “容器系统入侵防护” 的有效方案，如果将容器运行在全虚拟化环境中（例如在虚拟机中运行容器），这样就算容器被攻破，也还有虚拟机的保护作用（目前一些安全需求很高的应用场景采用的就是这种方式）。
03“容器网络入侵检测与防护” 管控方法
Docker 容器网络的安全问题可被划分为 “网络安全防护” 与 “微服务Web应用安全” 两类，“隔离”
和 “访问控制” 等主要思路均有助于管控二者的安全问题。此外，仍可将部分现阶段较为成熟的安全技术应用到
Docker 场景中。在具体实施时，可依据 Docker 应用规模与实际的网络部署情况进行管控。
Docker 网络本身具备 “隔离” 和 “访问控制” 功能的网络安全机制，但存在 “粒度较大”
与 “对安全威胁的感知能力不足” 等缺陷，如图4所示。
图4. Docker 网络自身安全机制
为了弥补 Docker 网络的安全缺陷，一些商业化的端对端的 Docker 安全产品对网络集群进行了纵深防御，它们具备的功能特点包括了：
容器防火墙
运行时保护
网络深度数据包检测
攻击行为、异常行为告警
日志监控
多编排平台支持
网络流量可视化
部分厂商在实现上述功能点时，在产品中引入了机器学习方法，用于生成行为模式与容器感知网络规则。
Docker 网络具有组网方案多样化、容器生命周期长短不一、应用场景多样化等特点。因而，应参照组网方案特点制定管控方法。笔者梳理的针对
“类传统单体应用”和 “微服务架构应用” 的入侵检测与防御思路如图5所示。
图5. Docker 网络入侵检测与防护思路
首先来看 “类传统单体应用” 的 Docker 网络集群的入侵检测和防护思路。以图 6 所示的微服务集群为例进行介绍。该集群里只有
Nginx、Tomcat 以及 MySQL 的 3 个容器。
图6. “类传统单体应用”的Docker网络集群的入侵检测和防护思路
注：图中的绿色虚线表示文件挂载或者Docker的cp命令等方式，通过这两种方式可以更便捷地在宿主机实时修改Nginx容器里的配置文件，调整Tomcat容器里的应用程序文件，或者对MySQL容器里的数据进行持久化。
为了对这套 Docker Web 应用进行入侵检测与防御，可考虑以下 9 点方法：
(1) Iptables隔离
通过在宿主机侧对Docker网络集群外部做基于Iptables的隔离策略，可以限制攻击者对“容器在宿主机所映射端口”的访问，缩小受攻击面。
(2) 部署软WAF
通过在Docker网络集群的流量入口处做软WAF的部署（形态可以是宿主机软件或者Docker容器），可以在此处阻断、发现部分恶意流量。
(3) 部署RASP
通过在Java、PHP服务器Docker容器内部部署RASP产品，可以用之作为保护的最后一环，作为网络治理的一个补充小点。
(4) Webshell扫描
通过在宿主机侧通过Webshell扫描引擎扫描来自Docker容器的“Web应用程序文件”（这些文件可通过“docker
cp”命令或者“动态挂载”机制获得），有助于发现攻击者植入的Webshell。
(5) 日志分析
通过在宿主机侧通过ELK等日志分析分析来自Docker容器的日志文件（这些日志文件同样可通过“docker
cp”或“动态挂载”等方式获得）。此外，单独运行Sidekick日志容器等做法有助于发现安全威胁。
(6) 识别中间人攻击
通过在Docker网络集群内部通过网络隔离是防止此类基于网络的攻击的有效方法，此方法可使得攻击者无法操纵或窃听主机及其他容器的网络流量；在这种情况下，OpenVPN(开放虚拟专用网络)提供了一种通过TLS(传输层安全协议)加密实现虚拟专用网络(VPN)的方法。
(7) 识别、阻断流向异常的流量
通过在Docker网络集群内部依据实际的网络拓扑图对网络进行 “微分段” 隔离（在“微服务架构”下，IP地址可能变换频繁，但是预先划分的网段不会变换频繁），或者对指定的网桥、网卡进行流量的DPI分析，有助于识别、阻断流向异常的流量。
(8）识别拒绝服务攻击
通过在宿主机侧读取和Docker容器对应的cgroup文件系统相关文件的实时内容（网络、CPU、内存、磁盘），可以识别出拒绝服务攻击。
(9) 网络流量可视化
“网络流量可视化” 是现有的 “容器安全产品”的常见附加功能。该功能的功能可能依托于 “对指定的网桥、网卡进行流量的DPI分析”。
接着来看 “微服务架构应用” 的 Docker 网络集群的入侵检测和防护思路。“微服务架构应用”
与 “类传统单体应用” 的显著区别包括了 Docker 容器数量较多、网络拓扑较复杂等方面。在这种生产场景下，K8S
等平台可帮助用户进行大规模容器编排。可考虑使用的入侵检测和防护思路如下：
(1) 运用 K8S 原生或其第三方网络插件的网络策略
K8S原生的网络策略 “NetworkPolicy” 可为 K8S 的最基本操作单位 “Pod”
提供 “IP地址/端口号” 级别的网络隔离。
注：K8S支持以“第三方网络插件”的形式选择网络方案，进而会影响网络策略的选择。例如，
NetworkPolicy须由实现了CNI接口的网络插件提供（如Calico、Cilium、Kube-route、Weave
Net等等）。
(2) 关注微服务架构Web应用的接口“认证鉴权”问题
开发方应对微服务架构Web应用的认证鉴权等问题予以重视，降低接口被网络可互通的容器恶意访问的风险。常见的“认证鉴权”方案可包括：网关鉴权模式、服务自主鉴权模式、API
Token模式。
(3) 以“组件化”的形式在微服务集群中部署Web安全应用
为了增加 Docker 网络集群的安全能力，可在 Docker 集群中部署 Web 安全应用（针对
“类单体Web应用” 的做法仍可继续使用。比如，我司的网站安全狗可用于保护部署在 Docker 容器里的
Web 应用，如图 7 所示），此外也可考虑在容器集群中部署API网关容器（基于Nginx+Lua）、蜜罐容器或者资产发现与漏洞扫描器。
图7. 网站安全狗可以用于保护 Docker 容器
(4) 运用 “Service Mesh” 技术
Service Mesh（服务网格）技术弥补了 K8S 在微服务通信的短板，有助于对应用层做访问限制。服务网格是一个基础设施层，功能在于处理服务间通信，其主要职责在于负责实现请求的可靠传输。在实践中，服务网格通常实现为轻量级网络代理，通常与应用程序部署在一起，但是对应用程序透明。以开源应用
Istio 为例，它通过为整个服务网格提供行为洞察和操作控制满足微服务应用程序的多样化需求。它在服务网络中统一提供了流量管理、策略执行、服务身份和安全等关键功能。同时，Istio还可集成已有的
ACL、日志、监控、配额、审计等功能。未来 Service Mesh 的融合架构模型如图8所示。
图8. 未来 Service Mesh 融合架构
04“安全合规基线” 管控方法
为了应对 Docker 容器生命周期里的全问题，需要可操作、可执行的 Docker 安全基线检查清单，这个清单要清晰、可查、可维护，以供在生产环境中执行基础架构的安全检查和审计。
以下安全合规检查工具有较好的参考性：
(1) docker-bench-security（与Docker官方及CIS推出的安全标准相配套，如图9所示）。
(2) Kube-bench（运行 CIS Kubernetes 基准测试，来检查 Kubernetes
部署的安全程度）。
(3) OpenPolicyAgent（将安全策略和最佳实践从特定的运行时平台解耦）。
图9. Docker-Bench-Security 与官方白皮书配套
四、总结
经过多年发展，Docker 容器技术逐渐被接受并应用于 DevOps 和微服务等领域，在未来还有很大的潜力。本文探讨了若干容器生命周期内的安全问题，不难发现，要做好
Docker 容器安全管控工作，不应忽视镜像深度扫描、容器系统与容器网络的入侵检测与防护以及安全合规问题等环节。在面对上述环节时，可考虑借鉴、改造现有的网络安全技术。
由于不同组织机构有着不同的 Docker 应用级别和技术选型，因而具体的实施方法会有不同。不同组织机构应结合自身情况，分阶段、分层（容器引擎层、编排调度层）选择适合的解决方案，以更好地保护
Docker 容器环境。
|
