2020云原生安全技术报告.pdf

云原生安全技术报告 2020 版权声明 为避免合作伙伴及客户数据泄露，所有数据在进行分析前都已经 过匿名化处理，不会在中间环节出现泄露，任何与客户有关的具体信息， 均不会出现在本报告中。 关于绿盟科技 绿盟科技集团股份有限公司 ( 以下简称绿盟科技 ), 成立于 2000 年 4 月 , 总部位于北京。公司于 2014 年 1 月 29 日起在深圳证券交易所创业板 上市 , 证券代码 : 300369。绿盟科技在国内设有 40 多个分支机构 , 为政 府、运营商、金融、能源、互联网以及教育、医疗等行业用户 , 提供全线网 络安全产品、全方位安全解决方案和体系化安全运营服务。公司在美国 硅谷、日本东京、英国伦敦、新加坡设立海外子公司 , 深入开展全球业务 , 打造全球网络安全行业的中国品牌。 中国移动云能力中心 中国移动云能力中心是中国移动通信有限公司的全资子公司，公司 定位为中国移动云设施构建者、云服务提供者、云生态汇聚者。公司以移 动云运营为中心，产品和服务在政务、金融、制造、交通、医疗等行业得 到广泛应用。 I 目录 CONTENTS 目录 CONTENTS 1.历史漏洞回顾4 1.1漏洞数量逐年显著增长4 1.2漏洞数量逐年显著增长5 1.2.1漏洞数量逐年显著增长8 1.2.2漏洞数量逐年显著增长9 2.漏洞利用情况4 2.1典型漏洞攻击事件监测举例4 2.2实际攻击中常用到Nday漏洞5 3.漏洞发展趋势4 3.1浏览器漏洞种类复杂多样4 3.2文档类型漏洞是鱼叉攻击的重要载体5 摘要2 前言 . 1 1.云原生安全概述 . 2 1.1.云原生简介 . 3 1.2.云原生安全简介 . 3 1.2.1.面向云原生环境的安全 . 4 1.2.2.具有云原生特性的安全 . 4 1.2.3.云原生安全：融合的安全 . 4 1.3.小结 . 5 2.安全问题成为影响云原生落地的重要因素 . 6 2.1.服务暴露 . 7 2.2.数据泄露 . 8 2.3.恶意挖矿攻击 . 8 2.4.小结 . 10 3.云原生面临的安全威胁和风险 . 11 3.1.容器化基础设施的威胁和风险不会更少 . 12 3.1.1.针对容器镜像的软件供应链攻击 . 12 3.1.2.容器逃逸 . 13 3.1.3.资源耗尽型攻击 . 16 3.2.微服务架构为云原生应用安全带来新的安全风险 . 16 3.2.1.微服务数据泄露 . 17 3.2.2.微服务间请求伪造 . 17 3.2.3.微服务 Web 应用的风险 . 17 3.2.4.微服务业务的风险 . 18 3.3.管理编排系统面临的安全风险不容小觑 . 18 3.3.1.Kubernetes 控制权限陷落 . 18 3.3.2.针对 Kubernetes 的拒绝服务攻击 . 19 云原生安全技术报告（2020） II 目录 CONTENTS 3.3.3.云原生网络安全风险 . 19 3.4.服务网格安全风险 . 20 3.4.1.服务间易受中间人攻击 . 21 3.4.2.服务间易受越权攻击 . 21 3.5Serverless 面临的威胁 . 21 3.5.1.针对应用程序代码的注入攻击 . 22 3.5.2.针对应用程序依赖库漏洞的攻击 . 23 3.5.3.针对应用程序访问控制权限的攻击. . 23 3.5.4.针对应用程序数据泄漏的攻击 . 24 3.5.5.针对 Serverless 平台账户的拒绝服务攻击 . 24 4.云原生安全防护思路 . 26 4.1.云原生安全设计原则 . 27 4.1.1.安全左移 . 27 4.1.2.聚焦不变 . 27 4.1.3.关注业务 . 27 4.2.面向云原生全生命周期的安全防护 . 28 5.云原生安全加固 . 30 5.1.镜像安全检测与加固 . 31 5.1.1.源代码安全审计 . 31 5.1.2.镜像扫描 . 31 5.2.主机安全加固 . 31 5.2.1.主机基本安全加固 . 31 5.2.2.云原生相关安全加固 . 32 6.云原生环境的可观察性 . 33 6.1.云原生环境为什么需要实现可观察性 . 34 6.1.1.云原生主机系统行为更复杂 . 35 6.1.2.可见才可防 . 35 6.1.3.助力等保 2.0 可信计算需求 . 35 III 目录 CONTENTS 6.2.云原生可观察性需要观察什么 . 36 6.3.云原生可观察性实现手段 . 36 6.3.1.日志（Logging） . 37 6.3.2.指标（Metrics） . 37 6.3.3.追踪（Tracing） . 37 6.4.云原生环境下的服务追踪 . 37 6.4.1.服务追踪概述 . 37 6.4.2.服务追踪的实现 . 38 6.4.3.服务追踪的应用 . 39 7微隔离实现零信任的云原生网络 . 41 7.1.概述 . 42 7.1.1.什么是微隔离？ . 42 7.1.2.云原生为什么需要微隔离？ . 43 7.2.云原生网络组网架构 . 43 7.2.1.端口映射 . 43 7.2.2.容器网络接口（CNI） . 44 7.2.3.服务网格 . 44 7.3.云原生网络的微隔离实现技术 . 45 7.3.1.基于 Network.Policy 实现 . 45 7.3.2.基于 Sidecar 实现 . 47 7.4.案例介绍 . 49 8.云原生异常检测 . 51 8.1.异常分类 . 52 8.2.云原生网络侧异常检测方法 . 52 8.3.云原生主机侧异常检测方法 . 53 8.3.1.基于进程模型的异常行为检测 . 53 8.3.2.基于系统调用的攻击行为检测 . 55 8.4.小结 . 56 云原生安全技术报告（2020） IV 目录 CONTENTS 9.云原生应用安全 . 57 9.1.应用 API 安全 . 58 9.1.1.云原生应用的 API 安全现状分析 . 58 9.1.2.云原生应用的 API 安全检测 . 58 9.2.应用业务安全 . 60 9.2.1.业务安全问题分析 . 60 9.2.2.业务异常检测 . 61 10.服务网格安全防护 . 64 10.1.Istio 和 API 网关协同的全面防护 . 65 10.2.Istio 与 WAF 结合的深度防护 . 66 10.3.小结 . 67 11.Serverless 安全防护 . 69 11.1.应用程序代码漏洞防护 . 70 11.2.应用程序依赖库漏洞防护 . 70 11.3.应用程序访问控制 . 71 11.4.应用程序数据安全防护 . 72 11.5.Serverless 平台账户安全防护 . 73 11.6.小结 . 73 12.面向新基建的云原生安全 . 74 12.1.云原生助力信息基础设施落地 . 75 12.2.5G 核心网安全 . 76 12.3.边缘计算安全 . 78 13.总结 . 81 14.参考文献 . 83 1 前言 前言 网络安全发展的方向有两种趋势，一是与新场景、新应用结合，典型的如云计算、人工智能、物联 网等；二是安全技术自身的演化，例如欺骗技术、威胁狩猎、智能决策等，而这两类趋势往往可能会融 合，如人工智能与安全技术之间，既利用 AI技术赋能安全运营形成 AISecOps，又加速了智能化安全运 营和智能化攻击技术的对抗。 当云计算发展将近二十年后，已然进入了新的阶段：云原生时代。以容器、编排和微服务为代表的 云原生技术，正在影响各行各业的 IT基础设施、平台和应用系统，也在渗透到如 IT/OT融合的工业互联网、 IT/CT融合的 5G、边缘计算等新型基础设施中。理解云原生体系存在的新架构、新风险和新威胁，有 助于我们构建面向新型 IT基础设施的安全防护机制；利用云原生的先进技术，融合到当前的攻防体系中， 也有助于我们提升整体安全防护的弹性、适应性、敏捷性。 我们在 2018年发布了容器安全技术报告，详细分析了容器技术所面临的风险和安全挑战，介 绍了安全左移思路下的安全基线、镜像安全等内容，给初建容器安全的机构一些有益的建议。近年随着 编排技术、无服务和服务网格等技术的快速发展，我们将重点放在了整个云原生生态体系的安全研究上。 鉴于此，我们发布了云原生安全技术报告，本报告较为全面地分析了云原生落地所面临的安全 风险和威胁，进而提出了云原生的防护思路和安全体系。首先，详细介绍了多种实现云原生环境的可观察、 可追踪的技术手段；然后介绍了在事前应实现零信任网络访问控制的微隔离技术，以及在事中面向容器 环境的异常检测技术和面向云原生应用和服务的应用业务安全技术。此外，报告也介绍了云原生新形态 的服务网格和无服务安全防护技术。最后，报告就 5G核心网和边缘计算等场景探讨了云原生安全的应用。 本报告在编写过程中参考了大量资料，吸取了多方的宝贵意见和建议，在此深表感谢。报告的编写 和发布得到了相关单位的大力支持，我们在此表示衷心的感谢！欢迎广大读者批评、指正。 云原生安全技术报告（2020） 2 云原生安全概述 1.云原生安全概述 1 云原生安全概述 3 云原生安全概述 1 云原生安全概述 随着云计算技术的成熟和云计算系统的广泛部署，上云成为了企业部署新业务的首选。同时， 各大云计算服务商的厮杀日益激烈，新的概念也层出不穷。近年来，云原生计算（ Cloud Native Computing）越来越多地出现在人们的视野中，那么云原生计算与传统云计算相比有什么不同，能利用 云原生计算解决什么问题，本章我们将介绍云原生计算的概念和应用场景。 1.1.云原生简介 近年来，云计算的模式逐渐被业界认可和接受。在国内，大多数利用开源或商业的 IaaS系统构建 云计算平台，这种方式所带来的好处是整体资源利用更加合理，集约式的运营降低成本，提升整体水平。 但总体而言，这样的上云实践只是“形”上的改变，还远没有到“神”上的变化。 在上云实践中，传统应用有升级缓慢、架构臃肿、无法快速迭代等问题，于是云原生的概念应运而生。 云原生充分利用云计算弹性、敏捷、资源池和服务化等特性，解决业务在开发、集成、分发和运行等整 个生命周期中遇到的问题。真实业务中出现的问题，才是真正的“问题”。所以，我们认为云计算下半 场的开场哨已经吹响，谁赢得云原生的赛道，谁才真正赢得了云计算。 更为正式地，云原生计算基金会（Cloud Native Computing Foundation ， CNCF）对云原生的见解 1 是“云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的 应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。这些技术能够 构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够 轻松地对系统作出频繁和可预测的重大变更。” 在云原生应用和服务平台构建过程中，容器技术凭借其轻隔离、易分发等特性和活跃强大的社区支 持，成为了云原生等应用场景下的重要支撑技术。无服务、服务网格等服务新型部署形态也在改变云端 应用的设计、开发、部署和运行，从而重构云上业务模式。 1.2.云原生安全简介 与云计算安全相似，云原生安全也包含两层含义：“面向云原生环境的安全”和“具有云原生特征 的安全”。 1 cf.io/about/faq 云原生安全技术报告（2020） 4 云原生安全概述 1.2.1.面向云原生环境的安全 面向云原生环境的安全，其目标是防护云原生环境中的基础设施、编排系统和微服务的安全。 这类安全机制，不一定具备云原生的特性（比如容器化、可编排），它们可以是传统模式部署的， 甚至是硬件设备，但其作用是保护日益普及的云原生环境。 一个例子是容器云（ CaaS）的抗拒绝服务，可用分布式拒绝服务缓解机制（ DDoS Mitigation）， 而考虑到性能限制，一般此类缓解机制都是硬件形态，但这种传统安全机制正是保障了是面向云原生系 统的可用性。 此外，主机安全配置、仓库和镜像安全、行为检测和边界安全等都是面向云原生环境的安全机制。 1.2.2.具有云原生特性的安全 具有云原生特征的安全，是指具有云原生的弹性敏捷、轻量级、可编排等特性的各类安全机制。 云原生是一种理念上的创新，通过容器化、资源编排和微服务重构了传统的开发运营体系，加速业 务上线和变更的速度，因而，云原生系统的种种优良特性同样会给安全厂商带来很大的启发，重构他们 的安全产品、平台，改变其交付、更新模式。 仍以 DDoS为例，在数据中心的安全体系中，抗拒绝服务是一个典型的安全应用，以硬件清洗设备 为主。但其缺点是当 DDoS的攻击流量超过了清洗设备的清洗能力时，无法快速部署额外的硬件清洗设 备（传统硬件安全设备的下单、生产、运输、交付和上线往往以周计），因而这种安全机制无法应对突 发的大规模拒绝服务攻击。而如果采用云原生的机制，安全厂商就可以通过容器镜像的方式交付容器化 的虚拟清洗设备，而当出现突发恶意流量时，可通过编排系统在空闲的服务器中动态横向扩展启动足够 多的清洗设备，从而可应对处理能力不够的场景。这时， DDoS清洗机制是云原生的，但其防护的业务 系统有可能是传统的。 1.2.3.云原生安全 ：融合的安全 虽然我们形式上将云原生安全分为了两类安全技术路线，但事实上，如果要做好云原生安全，则必 然需要使用“具有云原生特性的安全”技术去实现“面向云原生环境的安全”，因而两者是互相融合的。 让我们继续以 DDoS威胁为例，一方面可用性是整个云原生系统中重要的安全属性，无论是宿主机、 容器，还是微服务、无服务业务系统，都需要保证其可用性；另一方面，在云原生系统中要实现可用性， 5 云原生安全概述 在物理边界侧要构建按需、弹性的 DDoS缓解能力，在容器、微服务边界侧部署虚拟、弹性的 DDoS机 制，这就需要云原生的安全能力。两者相辅相成，缺一不可。 1.3.小结 要实现云原生安全，就需要首先评估云原生系统中的安全风险和相关威胁，设计具有针对性的安全 机制；在此过程中，云原生系统的固有业务特点，就要求安全厂商现有的安全能力云原生化。目前可预 见的是，安全能力的云原生化，绝不是简单的将原有安全设备虚拟化或容器化，而是要按照部署要求进 行容器化，按照性能要求进行轻量化，按照功能进行拆分、微服务化，最后实现弹性、敏捷、轻量级等 特性。 云原生安全技术报告（2020） 6 安全问题成为影响云原生落地的重要因素 2.安全问题成为影响云原生落地的 重要因素 安全问题成为影响云原生落地的重要因素 2 7 安全问题成为影响云原生落地的重要因素 从各种各样的安全风险中可以一窥云原生技术的安全态势，云原生环境仍然存在许多安全问题亟待 解决。在云原生技术的落地过程中，安全是必须要考虑的重要因素。 2.1.服务暴露 服务暴露的问题，我们在 2018年的报告 2 中就已经详细进行了分析，这里再简单做一下回顾。我 们利用网络空间搜索引擎 Shodan对 2020年 10月份某天暴露 2375端口的 Docker Daemon服务进行 了分析，发现仍然有约 4800个 Docker Daemon对外暴露 2375端口，其中部分是没有设置访问认证的， 可以直接与之交互。 图 2.1部分暴露 2375 端口且无访问认证的主机 另外，我们也对同时期 Kubernetes Dashboard在互联网上的暴露情况进行了统计，发现仍有约 1200个 Kubernetes Dashboard服务暴露在互联网上。其中也仍存在不需要认证即可登录的情况。这种 端口暴露是非常危险的。 2 云原生安全技术报告（2020） 8 安全问题成为影响云原生落地的重要因素 图 2.2一个对外暴露端口且无访问认证的 Kubernetes Dashboard 服务 2.2.数据泄露 数据泄露在云原生中仍然是重要的安全威胁。以亚马逊的对象存储服务 Amazon S3为例，其在云 原生中也得到了应用 3 ，然而，S3 数据泄露事件被屡屡曝光，不胜枚举 45 。 在上述众多数据泄露事件中，绝大多数是 S3存储桶的公开访问，有的事件涉及 S3被设置为允许任 何 AWS登录用户访问，甚至一个医疗数据泄露事件的相关存储桶竟然被设置为了任何人均可读写，这 是不可想象的。 2.3.恶意挖矿攻击 特斯拉Kubernetes挖矿事件 2018年 2月 20日，云安全公司 RedLock发文披露 6 ，特斯拉的 Kubernetes集群曾在数月前被入侵， 黑客在其中部署了挖矿程序。据报道，入侵的直接原因是，其 Kubernetes集群的 Dashboard处于未授 3 4 5 6web.archive/web/20180222103919/blog.redlock.io/cryptojacking-tesla 9 安全问题成为影响云原生落地的重要因素 权即可访问状态，且暴露在互联网上。 对于一个 Kubernetes集群来说，控制 Kubernetes Dashboard意味着能够直接向集群下达指令，严 重情况下攻击者甚至能够逃逸出容器，进而轻易控制集群所有宿主机节点，其风险等同于甚至超过域沦 陷，却往往得不到相应的重视。 微软监测到大规模Kubernetes挖矿事件 2020年 4月 8日，微软 Azure安全中心发布博文称，检测到大规模 Kubernetes挖矿事件 7 。2020 年 6月 10日，微软 Azure安全中心再次发布文章，警告滥用 Kubeflow的大规模挖矿事件 8 。两起事 件的曝光日期如此接近，说明以 Kubernetes为代表的云原生系统很可能正在成为不法分子赖以牟利的 新渠道。 针对 Kubeflow的攻击事件，影响了数十个 Kubernetes集群，通常用于机器学习的 Kubernetes集 群各节点的算力会比普通服务器要强大许多，这些算力同样能够被攻击者所用，为挖矿带来显著增益。 事实上，容器环境下的恶意挖矿并不新鲜，挖矿活动一般发生在脆弱容器中。例如，黑客利用容器 内部运行有漏洞 Web的应用程序，获得容器控制权，进而部署挖矿程序。 Graboid蠕虫挖矿传播事件 2019年 10月 15日，Unit 42 安全团队发现了一款新型挖矿蠕虫 9 ，命名为 Graboid（大地虫）， 该蠕虫的挖矿产出是门罗币（ Monero），被发现时，它已经传播到了超过 2000台不安全的 Docker宿 主机上。这是安全研究者第一次发现借助 Docker容器进行挖矿和传播的蠕虫。 本次事件中，攻击者首先通过不安全的 Docker守护进程暴露出来的远程端口获得对目标主机的控 制权，然后下达指令从 Docker Hub上拉取（pull）并运行实现上传的恶意镜像。由于传统终端防护机制（AV 、 EDR）并不能很好地审计容器内部的行为和数据，故很难检测出这类恶意行为。 我们必须认真对待云原生环境下的蠕虫传播事件。相比传统内网环境，云原生集群环境下各节点之 间具有更强的关联性。例如，在 Kubernetes集群内，一旦蠕虫获得了 API Server的控制权限，就能够 7 8 9 云原生安全技术报告（2020） 10 安全问题成为影响云原生落地的重要因素 在非常短的时间内感染整个集群，并能利用编排技术持久化恶意代码，后果不堪设想。 2.4.小结 谈及云原生安全时，不少人还停留在传统安全意识和观念，对 Web攻防、系统攻防加强防范，密 码暴力破解和反弹 Shell不会掉以轻心。然而，安全总是具有“短板效应”。有时，一个简单的端口暴露、 未授权访问漏洞没有及时处理，就可能为攻击者提供不费吹灰之力长驱直入的机会，固若金汤的城池也 会因此沦陷。 此外，云原生自身脆弱性带来的风险，在未来数年内，很可能被攻击者所利用，进而发动针对云原 生系统的攻击，因而云原生面临的威胁和安全风险不可不察。 11 云原生面临的安全威胁和风险 3.云原生面临的安全威胁和风险 云原生面临的安全威胁和风险 3 云原生安全技术报告（2020） 12 云原生面临的安全威胁和风险 3.1.容器化基础设施的威胁和风险不会更少 以容器和容器编排系统为代表的云原生基础设施，成为支撑云原生应用的重要载体，其安全性将直 接影响整个云原生系统的安全性。 3.1.1.针对容器镜像的软件供应链攻击 随着容器技术的普及，容器镜像也成为了软件供应链中非常重要的一部分。然而，业务依赖的基础 镜像无论是存在安全漏洞还是包含恶意代码，这种潜在危害比黑客从外部发起攻击严重得多。下面，我 们将介绍两种容器镜像软件供应链的攻击类型。 镜像漏洞利用 “镜像漏洞利用”指的是镜像本身存在漏洞时，依据镜像创建并运行的容器也通常会存在相同漏洞， 攻击者利用镜像中存在的漏洞去攻击容器，往往具有事半功倍的效果。 备受开发者青睐的 Alpine镜像曾曝出过一个漏洞，编号为 CVE-2019-5021。3.3 到 3.9版本的 Alpine镜像中， root用户密码被设置为空，攻击者可能在攻入容器后借此提升到容器内部 root权限。 这个漏洞看起来很简单，但是 CVSS 3.0评分高达 9.8分 10 。 镜像投毒 镜像投毒是一个宽泛的话题。它指的是攻击者通过某些方式如上传镜像到公开仓库、入侵系统 后上传镜像到受害者本地仓库以及修改镜像名称假冒正常镜像等，欺骗、诱导受害者使用攻击者指定的 恶意镜像创建并运行容器，从而实现入侵或利用受害者的主机进行恶意活动的行为。 根据目的不同，常见的镜像投毒有三种类型：投放恶意挖矿镜像、投放恶意后门镜像和投放恶意 exploit镜像。 投递恶意挖矿镜像 这种投毒行为主要是为了欺骗受害者在机器上部署容器，从而获得经济收益。 2018年 6月，一份 10nvd.nist.gov/vuln/detail/CVE-2019-5021 13 云原生面临的安全威胁和风险 研究报告指出 11 ，一个名为 docker123321的账号向 Docker Hub上陆续上传了 17个包含挖矿代码的 恶意镜像。截至 Docker Hub官方移除这些镜像时，它们已经累计被下载超过 500万次。据统计，黑客 借助这一行为获得了时值约 9万美元的门罗币。 投放恶意后门镜像 这种投毒行为主要是为了实现对容器的控制。通常，受害者在机器上部署容器后，攻击者会收到容 器反弹过来的 Shell。 相比之下，这种类型的投毒可能会少一些因为在隔离有效的情况下，即使攻击者拿到一个 容器内部的 Shell，攻击面仍然有限。在 2017年 9月，有用户在 Docker Hub的反馈页面中反馈前述 docker123321账号上传的 Tomcat镜像包含了后门程序 12 。结合该账号上传的其他恶意镜像的挖矿行 为来看，有理由推测攻击者在连接上述后门后可能会部署挖矿程序，获得经济收益。 投放恶意exploit镜像 这种投毒行为是为了在受害者部署容器后尝试寻找宿主机上的各种漏洞来实现容器逃逸等目的，以 实现对受害者机器更强的控制。 从攻防对抗的角度来看，恶意 exploit镜像只不过是一种攻击载荷投递方式，其特点在于隐蔽性和 可能的巨大影响范围。试想，如果 Docker Hub上某一热门镜像包含了某个 1day甚至 0day漏洞的利用 程序，理论上，攻击者将可能一下子获取上百万台计算机的控制权限。 3.1.2.容器逃逸 与其他虚拟化技术类似，逃逸是最为严重的安全风险，直接危害了底层宿主机和整个云计算系统的 安全。 根据层次的不同，容器逃逸的类型可以分为以下三类： 11 12 云原生安全技术报告（2020） 14 云原生面临的安全威胁和风险 图 3.1不同层次的容器逃逸问题 上图可以进一步展开为：危险配置导致的容器逃逸；危险挂载导致的容器逃逸；相关程序漏洞导致 的容器逃逸；内核漏洞导致的容器逃逸。 危险配置导致的容器逃逸 在这些年的迭代中，容器社区一直在努力将纵深防御、最小权限等理念和原则落地。然而，无论是 细粒度权限控制还是其他安全机制，用户都可以通过修改容器环境配置或在运行容器时指定参数来缩小 或扩大约束。如果用户为不完全受控的容器提供了某些危险的配置参数，就为攻击者提供了一定程度的 逃逸可能性。 最初，容器特权模式的出现是为了帮助开发者实现 Docker-in-Docker特性 13 。然而，在特权模式下 运行不完全受控容器将给宿主机带来极大安全威胁。例如，攻击者可以直接在容器内部挂载宿主机磁盘， 然后将根目录切换过去，从而实现容器逃逸。 危险挂载导致的容器逃逸 在某些特定场景下，为了实现特定功能或方便操作（例如为了在容器内对容器进行管理将 Docker Socket挂载到容器内），用户会将外部敏感卷挂载入容器。随着容器技术应用的逐渐深化，挂载操作 变得愈加广泛，由此而来的安全问题也呈现上升趋势。 13 15 云原生面临的安全威胁和风险 Docker Socket是 Docker守护进程监听的 Unix域套接字，用来与守护进程通信，查询信息或下发 命令。 如果在攻击者可控的容器内挂载了该套接字文件（/var/run/docker.sock），容器逃逸就相当容易了， 除非有进一步的权限限制。一种逃逸方法是：（ 1）在容器内安装 Docker命令行客户端；（ 2）使用该 客户端通过 Docker Socket与 Docker守护进程通信，发送命令创建并运行一个新的容器，将宿主机的 根目录挂载到新创建的容器内部；（3）在新容器内执行 chroot将根目录切换到挂载的宿主机根目录。 相关程序漏洞导致的容器逃逸 所谓相关程序漏洞，指的是那些参与到容器生态中的服务端、客户端程序自身存在的漏洞。 CVE-2019-5736正是这样一个存在于 runC的容器逃逸漏洞，它由波兰 CTF战队 Dragon Sector在 35C3 CTF赛后基于赛中一道沙盒逃逸题目获得的启发，对 runC进行漏洞挖掘，成功发现的一个能够 覆盖宿主机 runC程序的容器逃逸漏洞。该漏洞于 2019年 2月 11日通过邮件列表披露，具体分析可参 见“容器逃逸成真：从 CTF解题到 CVE-2019-5736漏洞挖掘分析” 14 。 内核漏洞导致的容器逃逸 Linux内核漏洞的危害之大、影响范围之广，使得它在各种攻防话题下都占据非常重要的一席。 近年来， Linux系统曝出过无数内核漏洞，其中能够用来提权的也不少，脏牛（ CVE-2016-5195） 大概是其中最有名气的漏洞之一。事实上，脏牛漏洞也能用来进行容器逃逸，一种利用方法的核心思路 是向 vDSO内写入 shellcode并劫持正常函数的调用过程。在成功触发漏洞后，攻击者可以获得宿主机 上反弹过来的 Shell，实现容器逃逸。 其他 作为一种轻量级虚拟化技术，传统容器与宿主机共享内核，这意味着系统内核权限提升漏洞往往也 可用来实施容器逃逸。为了彻底解决这一问题，在轻量与安全性之间达到较好的平衡，安全容器应运而 生。 Kata Containers是一种安全容器的具体实现，其他主流的安全容器还有 Google推出的 gVisor等。 无论是在理论上，还是在实践中，安全容器都具有非常高的安全性。然而，在 2020年 Black Hat 14 云原生安全技术报告（2020） 16 云原生面临的安全威胁和风险 北美会议上， Yuval Avrahami分享了利用多个漏洞成功从 Kata containers逃逸的议题 15 ，安全容器首 次被发现存在逃逸可能性。他使用发现的三个漏洞（ CVE-2020-2023、CVE-2020-2025 和 CVE-2020- 2026）组成漏洞利用链先后进行容器逃逸和虚拟机逃逸，成功从容器内部逃逸到宿主机上。 3.1.3.资源耗尽型攻击 同为虚拟化技术，容器与虚拟机既存在相似之处，也有显著不同。在资源限制方面，我们需要为即 将创建的虚拟机设定明确的 CPU、内存及硬盘资源阈值，在虚拟机内部的进程看来，它真的处于一台 被设定好的独立计算机之中。 然而，容器运行时默认情况下并未对容器内进程在资源使用上做任何限制，以 Pod为基本单位的容 器编排管理系统也是类似的， Kubernetes在默认情况下同样未对用户创建的 Pod做任何 CPU、内存使 用限制 16 。 限制的缺失使得云原生环境面临资源耗尽型攻击风险。攻击者可能通过在一个容器内运行恶意程序， 或针对一个容器服务发起拒绝服务攻击来占用大量宿主机资源，从而影响到宿主机或宿主机上其他容器 的正常运行。 3.2.微服务架构为云原生应用安全带来新的安全风险 在如今应用的开发、测试、运维均追求敏捷开发的时代，微服务应运而生。但随着应用的微服务化 升级，新的安全风险也不容忽视。 首先，随着微服务的增多，暴露的端口数量也急剧增长，进而扩大了攻击面，且微服务间的网络流 量多为东西向流量，网络安全防护维度发生了改变。 其次，不同于单体应用只需解决用户或外部服务与应用的认证授权，微服务间的相互认证授权机制 更为复杂，人为因素导致认证授权配置错误成为了一大未知风险。 最后，微服务通信依赖于 API，随着业务规模的增大，微服务 API数量激增，恶意的 API操作可能 会引发数据泄漏、越权访问、中间人攻击、注入攻击、拒绝服务等风险。 15 16kubernetes.io/docs/concepts/policy/limit-range/ 17 云原生面临的安全威胁和风险 3.2.1.微服务数据泄露 应用存储的数据基于 API进行访问，若应用中某个 API含有漏洞或通信未采用加密协议，攻击者便 可利用漏洞进行越权或中间人攻击，从而达到数据窃取的目的。 容器镜像为承载云原生应用的实体，开发者将敏感信息写入 Dockerfile、源码或以环境变量的方式 进行传递，这种行为增加了数据泄露的风险，随着微服务数量的不断增多，其造成的损失也呈指数增长。 Kuberenetes作为主流的微服务管理平台内置了许多安全机制，但默认值通常并不安全，例如我们 创建了 Secrets资源用于存储数据库登录信息，虽然这是一种正确存储敏感信息的方式，但默认情况下， Kubernetes在 Etcd组件中存储的信息是明文的，如果未对 Etcd组件开启 TLS访问，攻击者一旦进入 Kubernetes集群内部便可对 Etcd组件进行访问从而造成大量微服务密钥信息泄露。 服务网格场景中，当微服务数量达到一定规模， API数量将不断递增，从而增大了数据泄露的风险。 另外，微服务间有着复杂的网络拓扑，如果服务间的通信流量未加密，攻击者一旦进入服务内部网络， 便可通过截获请求中的敏感传输数据（例如用户名、密码、密钥信息等）进行中间人攻击。 3.2.2.微服务间请求伪造 应用架构的改变使微服务授权面临新的风险。在单体应用架构下，应用作为一个整体对用户进行授 权。在微服务场景下，所有的服务均需对各自的访问进行授权，明确当前用户的访问控制权限。传统的 单体应用访问来源相对单一，基本为浏览器，而微服务的访问来源还包括内部的其它微服务，因此，微 服务授权除了服务对用户的授权，还增加了服务对服务的授权。 Kubernetes中，内部容器间访问控制和隔离可使用网络策略（ NetworkPolicy）实现，但其默认情 况下 Pod之间是互通的，这也就意味着网络策略是以白名单的模式出现，因此如果不对 Pod之间的访 问进行显示授权，一旦集群内部的某一 Pod失陷，便会极速扩展至整个集群的 Pod失陷。 3.2.3.微服务 Web 应用的风险 OWASP发布了 Web应用安全 10大风险，其中对常见的 Web攻击风险进行了详细的总结 17 。Web 攻击作为应用层的主要攻击类型，在微服务架构中也依然存在，其风险同时不容小觑。 17owasp/-project-top-ten 云原生安全技术报告（2020） 18 云原生面临的安全威胁和风险 3.2.4.微服务业务的风险 与网络层的安全不同，业务层面的安全往往没有明显的网络攻击特征。攻击者可以利用业务系统的 漏洞或者规则对业务系统进行攻击来获利，给业务系统造成损失。 在微服务架构下，各服务如果安全措施不完善，例如用户鉴权、请求来源校验不到位，将会导致针 对微服务业务层面的攻击变得更加容易。例如针对一个电商应用，攻击者可以对特定的服务进行攻击， 例如通过 API传入非法数据，或者直接修改微服务的数据库系统等。攻击者可以绕过验证码服务，直接 调用订单管理服务来进行薅羊毛操作。攻击者甚至可以通过直接修改订单管理和支付所对应的微服务系 统，绕过支付的步骤，直接成功购买商品等。 3.3.管理编排系统面临的安全风险不容小觑 在云原生环境中，编排系统无疑处于重中之重的地位，而 Kubernetes早已成为容器编排系统的“事 实标准”。本节，我们来从控制权限陷落、拒绝服务攻击和网络安全风险三个方面去介绍管理编排系统 的潜在风险。 3.3.1. Kubernetes 控制权限陷落 Kubernetes组件的不安全配置。由于 Kubernetes组件众多、各组件配置复杂，不安全配置引起 的风险不容小觑。比如 Kubernetes API Server的未授权访问， Kubernetes Dashboard的未授权访问， Kubelet的未授权访问等。 以 API Server的未授权访问为例，默认情况下， API Server能够在两个端口上对外提供服务： 8080 和 6443，前者以 HTTP协议提供服务，无认证和授权机制；后者以 HTTPS协议提供服务，支持认证和 授权服务。 在较新版本的 Kubernetes中，8080 端口的 HTTP服务默认不启动。然而，如果用户在启用了 8080端口并重启 API Server，那么只要网络可达，攻击者即可通过此端口操控集群。 Kubernetes权限提升。以 CVE-2018-1002105漏洞为例，这是一个 Kubernetes的权限提升漏洞， 允许攻击者在拥有集群内低权限的情况下提升权限至 Kubernetes API Server权限，CVSS 3.x 评分为 19 云原生面临的安全威胁和风险 9.8 18 。通过构造一个对 Kubernetes API Server的特殊请求，攻击者能够借助 Kubernetes API Server作 为代理，建立一个到后端服务器的连接。利用该连接，攻击者能够以 Kubernetes API Server的身份向 后端服务器发送任意请求，实现权限提升。 突破隔离，访问宿主机文件系统。以 CVE-2017-1002101漏洞为例，这是一个 Kubernetes的文件 系统逃逸漏洞，允许攻击者使用 subPath卷挂载来访问卷空间外的文件或目录， CVSS 3.x评分为 9.8 19 。 所有 v1.3.x、v1.4.x、v1.5.x、v1.6.x 及低于 v1.7.14、v1.8.9 和 v1.9.4版本的 Kubernetes均受到影响。 这个漏洞本质上是 Linux符号链接特性与 Kubernetes自身代码逻辑两部分结合的产物。符号链接 引起的问题并不新鲜，这里它与虚拟化隔离技术碰撞出了逃逸问题，以前还曾有过在传统主机安全领域 与 SUID概念碰撞出的权限提升问题等 20 。 3.3.2.针对 Kubernetes 的拒绝服务攻击 拒绝服务攻击有多种类型。常见的是基于流量的拒绝服务攻击和基于漏洞的拒绝服务攻击。 传统环境和云原生环境的流量攻击的差异性较小，攻击效果通常取决于流量大小。基于漏洞的拒绝 服务攻击则不然，存在于云原生组件的拒绝服务漏洞很可能并不存在于传统主机环境，典型的漏洞包括 CVE-2019-11253、CVE-2019-9512 、CVE-2019-9514 等。 3.3.3.云