前言

安全的系统都是相似的，不安全的系统各有各的风险。云原生技术架构在带来颠覆性技术架构变革的同时，也带来了新的安全要求和挑战。在过去几年以及未来数年内，云原生架构会成为黑客攻击和利用的重点。

作为网络安全工作者，你不能保护你看不到的资产，同样你也防御不了你不知道的漏洞和攻击。因此，我们对云原生技术架构面临的安全挑战进行了简单的梳理，作为一个系列的序章。

什么是云原生

云原生（CloudNative）是一个组合词，Cloud+Native。Cloud表示应用程序位于云中，而不是传统的数据中心；Native表示应用程序从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳姿势运行，充分利用和发挥云平台的弹性+分布式优势。在具体的技术实践中，容器（包括编排工具Kubernetes）、DevOps、微服务形成了云原生时代的“三驾马车”。其中，容器是基础设施，DevOps侧重流程，微服务是软件架构。三者作为铁三角互相补充，但又以容器技术为底层基础。这也是为什么我们后面讨论云原生的优势或风险时容器都占了大部分，我们的产品设计时也是以容器安全为起点。

按照Gartner在2021年发布的调查报告，在91个参与调查的企业或组织中，60%目前正在使用容器技术，27%正在试点/测试，12%计划采用。受访者来自世界各地，其中大部分来自欧洲（49%）和北美（33%）。而在国内，根据信通院的统计数据，2020年43.9%的国内用户已在生产环境中采纳容器技术，超过七成的国内用户已经或计划使用微服务架构进行业务开发部署等。

云原生相关技术受到如此重视和普及，是因为它所能带来的实实在在的收益。

云原生的优势

拥抱变化应对风险

唯一不变的就是变化。软件生命周期中面临的变化可能来自于三个方面，功能需求变化、架构调整/代码重构、业务访问量的增减。DevOps采用小步快跑的方式，从MVP（最小化可行产品）逐渐丰富功能特性，每一次迭代后都可以重新审视来自用户的需求变化并迅速做出应对。容器平台支持极速的弹性扩缩容，可以快速响应用户访问量增减带来的性能需求变化。而微服务则可以灵活地应对架构的调整、扩展、复用。

提升研发和交付效率

提升效率的一个重要方法论是标准化，从而自动化，进而智能化。由于容器镜像采用了“不可变基础设施”的理念，提供了完整的运行时环境，确保了执行环境的一致性，也就是“标准化”。K8S和CI/CD的接合则促进了“自动化”，使得应用迁移更加容易，支持一键快速部署，提升交付效率。

降低成本

微服务架构，可以支持组件复用，避免重复造轮子。而容器技术的采用，可以有效地提升企业数据中心硬件服务器的资源利用率（10%~30%）。此外，由于同一个镜像在开发环境、测试环境或生产环境的表现具备一致性，使其更不容易出现故障，从而提高MTBF（平均故障间隔时间）。即使偶尔故障，也会由于容器天然支持故障自愈的高可用特性，运维成本得到大大降低。

在这个VUCA(volatility-易变性，uncertainty-不确定性，complexity-复杂性，ambiguity-模糊性)的时代，云原生技术可以帮助企业IT更好地应对风险、降低成本、提升效率。但我们也应清醒地认识到，云原生不是解决一切问题的银弹。伴随着云原生技术带来的弹性、敏捷等优势，用户会面临新的安全要求和挑战。

云原生的安全挑战

在Gartner的调查报告中也指出了，用户在采用容器技术时面临的关键挑战，与缺乏技能、环境复杂性和安全担忧有关。这个章节我们重点梳理一下用户在采用了云原生技术（或容器技术）时所面临的安全挑战。

图：用户采用容器面临的挑战（来源：Gartner）

根据被攻击对象的不同或者说以资产维度的划分，我们将其归纳为五类安全风险。

集群风险

集群风险是指编排工具如Kubernetes、Openshift，容器runtime如Docker等容器赖以运行的基础环境。容器技术基于进程隔离不同容器，相对于需要额外部署Guest OS的传统虚拟机技术，会更节省资源的同时，导致其隔离性较弱。Kubernetes本身也可能存在漏洞或者错误配置。上述因素都使得容器云平台存在非法提权和逃逸攻击的可能性。当容器集群存在此类风险时，影响面是整个集群，而不只是某一个镜像某一个容器存在漏洞。Gartner的分析师认为，“There is more risk from cloud infrastructure misconfiguration than from workload compromise. ”

意思即是说集群风险甚于CWPP，需要用户对其进行关注。

早在2018年时，黑客曾利用“允许匿名访问”的错误配置，成功入侵明星企业Tesla在AWS上的Kubernetes集群，并进一步获取敏感数据和利用其计算资源进行“挖矿”操作，造成大量有形与无形的经济损失。

图：集群风险汇总

我们梳理了不同编排工具或runtime组件可被攻击利用的漏洞，数量相当可观，统计情况如下所示。可以看到，即使号称安全容器的kata-container也存在逃逸风险，更不用说普及率最高的Docker。

图：编排工具和运行时组件漏洞统计

镜像风险

根据镜像来源不同，我们容器镜像简单划分为公共镜像和私有镜像。公共镜像来自于Dockerhub或阿里云等公共仓库，而私有镜像是指用户研发团队基于业务软件需求自己构建的容器镜像。

对于公共镜像，调查发现Dockerhub中超过50%的官方镜像存在高危漏洞，接近70%的镜像存在高危或中危漏洞。另外有部分镜像存在恶意后门。

                    图：公共镜像存在漏洞统计

而对于私有镜像，由于研发团队的安全意识参差不齐，大量客户的镜像内会遗留有漏洞、多余的软件组件和敏感信息（包含了账号/密码、秘钥文件信息）。这类镜像一旦上线运行，就成为潜在的安全风险。

镜像仓库风险

国内大部分企业用户由于合规需求，会更倾向于建设私有容器云平台，并包含私有镜像仓库而非Dockerhub这类公有仓库。按照“Build-Ship-Run”的生命周期，镜像仓库是企业用户管理容器镜像的核心工具，是镜像流转过程必经的一个环节。如果仓库的安全防护存在问题，被非法访问，则镜像可能会被篡改或替换。因此如果要保障镜像的完整性，必须对镜像仓库进行防护。以下是以Harbor仓库为例，统计的仓库自身存在的漏洞。

图：Harbor仓库漏洞列表

容器网络风险

容器网络与物理网络存在较大差异，物理网络的边界较为清晰，而容器网络则相对模糊。多个服务会共享同一个宿主机，一个服务的多个实例也可能运行在多个宿主机。容器网络中的东西向流量增多，服务之间的数据流动异常频繁。一旦某个容器失陷，则可能会影响同主机上其他容器，也可能会导致整个集群陷于风险之中。

图：容器网络风险

微服务风险

相对于传统的单体应用架构，微服务入口点增加导致攻击面增大。微服务场景下，业务逻辑不是在一个单一的进程里，而是分散在很多的进程里。每一个进程都有自己的入口点，这就会导致防范的攻击面，比原来大得多，风险也会高得多。严格来说，微服务的应用架构并没有引入新的安全漏洞。但是由于数量爆炸式增长，需要用户在资产梳理方面做出更多努力。

总结：一切问题皆有解决之道

技术的发展是一把双刃剑。云原生技术变革在创造价值的同时，也让IT面临新的安全挑战。我们看到，在东方大国某部门组织的年度大型攻防演练中，红队已经开始利用云原生相关的漏洞进行得分。而真实的生产环境中，网络黑产势力也会利用现阶段企业在云原生安全领域具备的知识相对薄弱这一点进行渗透攻击。

面对新的安全挑战，企业是否应放弃云原生的采用？当然不！我们不建议盲目跟潮流选择新技术，但亦反对因噎废食。是否选择云原生技术栈，更多还是要看企业是否在推进数智化转型，是否有敏捷、降成增效的需求。

对于选择了云原生的企业，如何应对本文中提到的各类风险呢？小佑科技希望能够利用我们先行一步积微成著的经验，帮到更多有需求的用户。产品的存在价值是为了解决问题，而我们的云原生容器安全防护平台—“镜界”的使命：用安全能力最大限度释放云原生的生产力！

镜界对云原生中涉及的所有资产对象均提供防护，对本文章中列出的各类风险均提供了应对之法，形成覆盖全生命周期的整体解决方案。在云原生领域，可以说镜界在手，安全我有。后续的文章中我们会逐一探讨产品具体功能和解决方案，欢迎大家继续关注。

图：镜界产品功能架构