引言
随着云计算的发展，以容器和微服务为代表的云原生技术，受到了人们的广泛关注，其中Docker和Kubernetes（以下简称“K8S”）是企业容器运行时和容器编排的首要选择。然而，在应用容器和K8S过程中，大多数企业都遇到过不同程度的安全问题，如何保障容器安全，已成为企业最关心的问题。
云原生到底是什么？
现在的IT圈子，无论是客户端、渠道端还是友商之间的技术探讨，都离不开AI人工智能、大数据、隐私计算、数据要素、云原生、容器等概念，仿佛不谈这些话题，就跟不上了社会发展的脚步，今天，我想谈谈我对“云原生”这个概念的理解，也是自己对知识的一个总结。
云原生顾名思义“就像是从云里面自动生长出来的东西”，所我认为以云原生就是一种思想或者理念。这种理念产生的背景是什么那？我们可以回顾一下云计算的发展历程。互联网从1960年开始兴起，1990年开始进入普通家庭，2000年开始逐步引入中国，门户网站/腾讯/阿里巴巴/网易/百度/德迅云安全等相继成立，随着互联网的高速发展，互联网用户规模不断扩大，企业为了维持用户的高速增长，需要购买大量的服务器资源，传统的IOE架构，投资巨大且资源浪费严重，没有什么企业能够承受如此巨大的开支，因此在这样的背景之下，在2006年搜索引擎大会上首次提出了“云计算”的概念，相继的各大互联网公司将“云计算”纳入到重点研究建设的方向，云计算技术开始进入了快车道发展，而且技术已经变的非常成熟。
我们发现，过去部署应用软件是部署在IOE架构上，现在部署在云计算架构上，而且部署效率、运维效率以及安全性、可靠性也更加高了，企业客户减少了硬件成本、人工成本、维护成本等的投入。但是，大家有么有发现一个问题，我们只是改变了承载应用的基础设施，且没有改变应用本身，所以我们不仅会问一个问题：跑在传统架构的应用和运行在云里面的应用是不是完全适配的？云的一些技术优势特性能否对应用有一些利好？过去我们应用开发都是基于IOE架构开发的，我们能不能基于云的架构去开发应用？如果按照云架构去开发应用，那么和基于传统架构的软件开发又有什么区别那？
正是这些疑问的提出，“云原生“的理念就出现了，就是”你开发的应用软件能不能天然的适配云、更好的利用云能力，就像从云里面自主生长出来的一样。“所以云原生他面相的对象是”应用软件“，过去十几年我们呢推动了底层基础架构的变化，未来的几十年我们将推动软件应用的变化，真正做到云-应用-业务的一体化。
一、云原生的架构是什么？
既然云原生面相的对象是“软件应用”，那么我们就需要对软件进行分析，他由什么成分构成，软件大致上可以分为3个部分：功能性部分（代码）、非功能性部分（代码）和第三方的部分（代码）。功能性部分是软件应用的核心，是客户真实需要的业务功能和逻辑，而非功能性部分，例如运维代码、可靠性代理、安全性代码等，以及第三方部分，例如第三方软件的调用、API数据调用等，都是非核心的功能性代码，他们只是更好的辅助核心功能代码能够正常稳定的运行。
未来的软件开发只需要聚焦在最核心的功能性代码上，而不用去关注哪些非功能性代码部分，将非功能性的代码全部交给云平台去实现，例如可靠性、安全性、视图化、第三方调用等等，这样既提升了软件开发的效率，也会大幅度提升软件质量（只聚焦业务本身）。理想往往是美好的，但真正落地的时候总是困难重重，下文探讨为实现云原生架构，无数工程师们做的努力。
二、实现云原生的技术路线是什么？
要让软件应用只聚焦业务功能部分，其他的你不用考虑，这就大大简化了应用开发的复杂度和难度，有两条路径：其一还是按照原来的开发思想，将无数功能紧耦合最终形成一个大的软件应用，然后部署在云计算环境中；还有一条路径就是目前主流的思想，就是软件设计要尽可能的解耦合，要以模块化的方式交付，从而提高可重复利用性。很显然第二条路径才是最优的解，让软件功能模块化，后面基于客户的需求任意组装，既可以减少开发成本，又可以提高部署效率，还能提升软件质量等。但是路径二面临一个比较大的问题，如果采用功能模块化的形式开发软件，面临如下困难的问题：软件功能模块如何部署？是单独部署还是组装好部署？如果是组装好一个大的软件后部署，就和传统软件部署没有太多差异（只是剔除了一些非功能性的代码），依然面临一个模块出问题影响整个软件运行、一个小升级涉及到整个软件的下线、可能面临重新配置环境、二次上线安全检查等一系列的后置动作，在运营上并没有提升多大的效率。如果是单功能模块部署那么功能模式间如何通信达到完整应用的效果？单模块功能部署在哪里？如果部署在虚拟机上，应用功能模块一般很小，给他配置的单个虚拟机资源会不会造成浪费？剥离出来的非功能性代码如何植入到云平台上，例如运维能力，原来是登陆系统直接对应用作运维，现在是放到云计算平台上，如何运维？怎么运维？等等一系列的问题。
还好有无数优秀的工程师，Docker技术应运而生（当然前期有很多的铺垫技术的诞生）。Docker在2004-2007年就在google大规模的部署和应用，于2013年gitHub上正式立项，google、redhat、aws、alibaba等开始大规模的应用Docker技术。Docker是比传统云计算虚拟机更加轻量化、小型的虚拟机。这就存在了让模块化功能存在的技术底座，也就是大家经常说的微服务。只需要再解决如何让这些微服务组成一个完整的服务（软件应用）、如何运维这些微服务组件（装了功能模块的容器，可能涉及到几千/几万/几十万个微服务才能构建一个完整的应用系统服务，管理难度可想非常复杂）、如何确保这些微服务的可靠性、安全性、可视化等，那么就可以成功实现云原生架构了。因此2014年，Kubernetes(K8s)项目也正式发布，它的核心功能就是管理这些容器、微服务组件等，次年，CNCF（云原生基金会）成立，K8s成为第一个CNCF项目，定义各种标准和规范，打造围绕云原生架构一整套的生态体系，至此，各大云计算厂家开始进入了云原生时代！
当今云计算和容器技术的广泛应用，极大地促进了企业的数字化转型和业务发展。但与此同时，由于云计算和容器技术的安全性问题，如数据泄露、拒绝服务攻击、容器漏洞等，给企业带来了巨大的风险和挑战。因此，如何保障云安全和容器安全已经成为企业必须解决的核心问题之一。
云安全和容器安全的基本原理
云安全是指在云计算环境下保护数据、应用程序和基础设施免受各种威胁的一系列技术和措施。
云安全的基本原理包括数据隔离、访问控制、网络安全等。容器安全是指保护容器环境免受各种攻击和漏洞的一系列技术和措施。
容器安全的基本原理包括镜像安全、容器隔离、容器网络等。
一、云安全和容器安全的风险和挑战
容器应用之前，云中应用系统多数运行于虚拟机上，但虚拟机仍会有额外的资源浪费和维护成本，并且其启动速度较慢。容器技术因具有占用资源少、部署速度快和便于迁移等特点，开始受到企业青睐。在典型的云原生环境中，通常包括主机、镜像、容器、容器编排平台、网络和微服务等对象，但由于目前多数企业使用容器技术部署业务应用，故下面将重点分析与容器相关的安全挑战。
云安全和容器安全面临的主要风险和挑战包括：
（1）容器技术风险
作为一种操作系统虚拟化技术，容器共享操作系统内核，但并未实现完全隔离，若虚拟化软件存在漏洞，或宿主机被攻击，将会造成容器逃逸或资源隔离失效，影响某个容器或多个容器的安全。
-
容器逃逸：利用虚拟化软件存在的漏洞，攻击者通过容器获取主机权限，可攻击容器所在主机，甚至是该主机上的其他容器。过去几年内已经发现了多个相关漏洞，其中CVE-2019-5736是RunC的一个安全漏洞，它会导致18.09.2版本前的Docker允许恶意容器覆盖宿主机上的RunC二进制文件，使攻击者能够以Root身份在宿主机上执行任意命令。
-
资源隔离失效：攻击者只要攻破容器操作系统内核，就可访问到主机上的文件系统，或进入其它容器，导致容器隔离失效。如果把主机的文件系统挂载到多个容器的目录里，容器就可以访问同一个目录，将会引起信息泄露或内容篡改等安全问题。
（2）不安全的镜像
镜像是一个包含应用/服务运行所必需的操作系统和应用文件的集合，用于创建一个或多个容器，它们之间紧密联系，镜像的安全性将会影响容器安全。根据镜像创建和使用方式，通常有三个因素影响镜像安全。
-
现有镜像不安全：镜像通常是开发者基于某个现有镜像创建的，无论是攻击者上传的恶意镜像，还是现有镜像存在的安全缺陷，基于它创建的镜像都将会是不安全的。
-
使用包含漏洞的软件：开发者经常会使用软件库的代码或软件，如果它们存在漏洞或恶意代码，一旦被制作成镜像，也将会影响容器的安全。
-
镜像被篡改：容器镜像在存储和使用的过程中，可能被篡改，如被植入恶意程序和修改内容。一旦使用被恶意篡改的镜像创建容器后，将会影响容器和应用程序的安全。
（3）东西向攻击
网络实现了容器之间、容器与外部之间的通信，以及应用之间的交互，但在虚拟化的容器网络环境中，其网络安全风险较传统网络更复杂、严峻。以Docker环境为例，它支持Bridge、Overlay和Macvlan等网络，尽管实现方式不同，但有一个共同和普遍的问题：如果容器之间未进行有效隔离和控制，则一旦攻击者控制某台主机或某台容器，可以以此为跳板，攻击同主机或不同主机上的其他容器，也就是常提到的“东西向攻击”，甚至有可能形成拒绝服务攻击。
（4） 运行环境未加固
作为容器的载体和编排管理软件，主机和容器编排平台等运行环境也是容器安全的重要因素之一。如前所述，主机上的容器并未实现完全隔离，如果主机未进行安全加固，一旦攻击者发起提权攻击，将会控制主机上其他容器。对于不安全的容器编排平台同样如此，某汽车制造企业就曾深受其害，由于其公有云环境中的K8S Master节点未设置密码保护，攻击者在盗取访问权限后，使用K8S集群挖掘加密货币。
二、保障云安全和容器安全的措施
为保障云安全和容器安全，企业需要采取以下措施：
（1）加强访问控制： 通过采用身份验证、权限管理等措施，确保只有授权的用户可以访问企业的云计算和容器环境。
（2）加密数据： 采用加密技术保护企业的敏感数据，防止数据泄露。
（3）及时更新补丁： 及时更新容器镜像和软件补丁，防止容器漏洞的产生和利用。
（4）监测和防御攻击： 通过安全监测、入侵检测等措施，及时发现并防御各种攻击，保护企业的云计算和容器环境安全。
（5）加强容器隔离： 通过采用容器隔离技术，隔离不同容器之间的访问和资源使用，防止容器环境被攻击者利用。
（6）应用安全最佳实践： 制定和实施容器安全和云安全的最佳实践，如合理设置容器权限、限制容器资源使用等。
三、未来云安全和容器安全的发展趋势
随着云计算和容器技术的不断发展，云安全和容器安全也将面临新的挑战和机遇。未来云安全和容器安全的发展趋势主要包括以下几个方面：
（1）安全自动化： 通过采用自动化技术，如自动化部署、自动化修复漏洞等，提高云安全和容器安全的效率和质量。
（2）人工智能和机器学习： 通过采用人工智能和机器学习技术，发现和防御各种攻击，提高安全性和效率。
（3）云原生安全： 针对云原生应用和服务的安全需求，提供全面的安全解决方案和最佳实践。
（4）多云和混合云安全： 针对多云和混合云环境的安全需求，提供全面的安全解决方案和管理平台。
德迅蜂巢（容器安全）
德迅蜂巢·云原生安全平台由德迅自主研发，能够很好集成到云原生复杂多变的环境中，如PaaS云平台、OpenShift、Kubernetes、Jenkins、Harbor、JFrog等等。通过提供覆盖容器全生命周期的一站式容器安全解决方案，德迅蜂巢可实现容器安全预测、防御、检测和响应的安全闭环。
德迅蜂巢·云原生安全平台的核心架构理念：
在开发阶段（Dev），遵循“安全左移”原则，做到上线即安全
在运行阶段（Ops），遵循“持续监控&响应”原则，做到完全自适应
方案功能
德迅蜂巢主要从安全左移和运行时安全两个阶段，在云原生的全生命周期过程中，提供原生的、融合的安全能力。
一、资产清点：
德迅蜂巢可以清晰地盘点工作负载本身的相关信息，此外，还能够实现不同工作负载之间的关系可视化，帮助运维和安全人员梳理业务及其复杂的关系，弥补安全与业务的鸿沟。
-
细粒度梳理关键资产
-
业务应用自动识别
-
资产实时上报
-
与风险和入侵全面关联
容器资产种类全面盘点
支持容器、镜像、Registry、主机、POD等容器资产快速清点，为用户提供容器内资产的分类视图，实现容器资产的全面可视化。
容器资产内容深度识别
对每类资产进行深入分析，获取资产相关的高价值安全数据，帮助用户从安全角度细粒度观察资产运行状况。
自动化、持续性容器资产清点
系统资产数据持续更新，每日及时地、自动化上报资产数据。基于历史清点的数据，每次只清点新启动的进程信息，极大降低对服务器性能的耗损。
二、镜像扫描：
德迅蜂巢的镜像检查能力已经覆盖到开发、测试等多个环节中，可快速发现镜像中存在的漏洞、病毒木马、Webshell等镜像风险。
-
覆盖容器全生命周期
-
全方位检测
-
镜像合规检查
-
X86、ARM 架构镜像全栈适配
持续的镜像补丁检测能力
持续更新漏洞数据库，并与集群中的容器镜像进行匹配。一旦发现任何新镜像补丁信息，用户将收到通知，而不必定期重新扫描。
全面的补丁数据呈现
深入检测运行环境和远程镜像仓库中容器镜像的重要更新补丁，综合考虑系统的业务影响、资产及补丁的重要程度、修复影响情况，智能提供最贴合业务的补丁修复建议。
灵活快速的检索方式
可根据需求灵活显示列表数据，定义表格显示。系统提供基于安全场景的筛选方式，如支持按 CVE 编号进行检索等，帮助用户迅速定位镜像和其安全补丁信息。
三、微隔离：
德迅蜂巢微隔离原生自适应容器多变的环境。通过对访问关系的梳理和学习，提供自适应、自迁移、自维护的网络隔离策略，帮助用户快速、安全地落地容器微隔离能力。
-
业务视角展示网络拓扑关系
-
云原生场景的隔离策略
-
适配多种网络架构
-
告警模式业务0影响
提供业务视角的网络拓扑关系
基于实际业务的作负载可视化展示容器间的访问为，清晰展示网络拓扑关系，方便运维和安全人员理解。
覆盖各种云原生场景的隔离策略
集群内网络隔离 可设置基于Namespace、Label、Controller、IP/CIDR的隔离策略。
集群间网络隔离 可设置基于集群与非容器集群，集群与外部网络之间的隔离策略。
纯容器与胖容器 针对纯容器与胖容器提供不同的隔离策略。
提供“告警”模式，让用户放心设置策略
针对工作负载提供“仅告警”业务模式，不下发实际的隔离策略，而是模拟下发的情况，当发现偏离策略的行为则进行告警提示。通过此种模式，可避免因隔离错误而对业务造成影响。
全面适配云原生的网络环境
适配Underlay、Overlay、Vxlan、Macvlan、Ovs等诸多网络架构。
四、入侵检测
德迅蜂巢通过多锚点入侵监测分析，实时监测容器中的已知威胁、恶意⾏为、异常事件，监测到入侵事件后，对失陷容器快速安全响应，把损失降到最低。
-
威胁建模适配容器环境
-
持续地监控和分析
-
威胁告警快速响应处置
-
提供多种异常处理方式
基于已知威胁进行检测
德迅蜂巢通过监控容器内的进程创建、文件变化等行为，获取行为特征，将这些特征经过德迅五大检测引擎的检测，以发现容器中的病毒、挖矿、Webshell等攻击行为。
基于恶意行为进行检测
以ATT&CK框架中定义的入侵模型为参考，结合对于运行时基础事件监控来建立IOC模型进行分析，能有效发现初始入侵时的远程漏洞利用、无文件攻击行为、远程控制的反弹Shell、端口扫描、横向移动、K8S的异常调用等行为。
基于异常行为进行检测
通过容器进程行为、文件行为、网络行为的监控/学习，建立容器行为模型，分析异常偏离行为， 发现未知入侵威胁。
五、合规基线
德迅蜂巢构建基于CIS Benchmark的最佳安全操作实践检查，帮助企业实施和完善容器合规规范，可实现一键自动化检测，并提供可视化基线检查结果和代码级修复建议。
-
CIS标准
-
一键自动化检测
-
基线定制开发
-
代码级修复建议
一键任务化检测，基线检查结果可视化呈现
用户可快捷创建基线扫描任务，根据检测需要，自行选择需要扫描的容器和基线，基线检查结果可视化呈现。
基于Docker基线多维检查
根据CIS Benchmark最佳实践方案，从运行时容器、镜像、主机三个维度，对各类容器配置问题进行检查
基于Kubernetes基线多节点检查
根据CIS Benchmark的规范，定时对k8s的master节点、worker节点进行基线检查。扫描完成后，即可查看每个扫描详情以及扫描结果
结语
伴随着云原生应用发展，企业通过微服务来交付应用系统的比例在增加，容器安全也将不仅仅是容器自身和容器环境安全，将延伸到微服务安全和应用安全，企业在应用云原生技术时，应整体考虑容器安全，让安全与云原生相融合，更好的保护应用系统。
