云原生安全专家观察：容器云安全现状和发展趋势

容器云技术在弹性和效率上的巨大优势，使其日益成为主流的IT基础设施。根据Gartner的预测，到2025年，云原生平台将成为95%以上的新数字化计划的基础，而云原生平台中的很大比例指的是容器云平台。伴随着容器云的建设，其安全的重要性也水涨船高，安全厂商与各企业的安全运营部门都开始在这个方向投入。

容器云安全不止是容器本身的安全，还包括镜像安全、编排（如K8s）安全、微服务安全、宿主操作系统风险等。其防御手段也不仅仅是针对运行时容器进行检测响应，也包括对开发生成的制品进行检查，防患于未然。虽然安全左移并非新概念，但容器云的安全建设相对传统云平台的安全建设，会更注重全生命周期。

 

容器云安全现状

安全风险不容乐观

据《Sysdig 2022 云原生安全和使用报告》显示，超过75%的运行容器存在高危或严重漏洞、62%的容器被检测出包含shell命令、76%的容器使用root权限运行。在我们之前接触的用户案例中，也存在不少企业的容器云允许kubelet被匿名访问，或者整个容器云平台没有任何防护措施，处于“裸奔”状态。诸多信息都表明企业的容器云存在较大安全风险，需要谨慎对待。

早在2018年，某著名车企部署在AWS上的容器集群曾遭黑客植入挖矿木马。2021年初，又有一家企业的Kubernetes集群遭攻击团伙TeamTNT入侵并植入挖矿木马。2021年4月1日，程序审计平台Codecov遭攻击，黑客利用Codecov的Docker镜像创建过程中出现的错误，非法获取脚本权限并对其进行修改，最后将信息发送到 Codecov 基础架构之外的第三方服务器，影响数万名客户。

从重保的角度来看，相对往年2022年8月份举行的攻防演练（HVV）明确了容器失陷的扣分标准，每失陷一个容器扣10分。基于集群与容器的数量关系，如果整个集群被攻陷，丢分会非常严重。

由此我们可以得出结论，不管是真实的网络攻击，还是攻防演练，亦或是合规检查，容器云安全均处于重要位置，企业安全建设部门应当给予足够重视。

标准规范不断成熟

早期的容器云安全是缺少国内规范和标准的，厂商与用户只能参考CIS的两个Benchmark，包括K8S和Docker。但随着需求旺盛，相关机构开始组织行业专家编写相关规范，以指导相应的安全建设和产品研发。

2020年，信通院发布容器安全标准，并据此推出可信容器云认证；

2021年，信通院发布云原生架构安全白皮书；

2022年，CSA大中华区发布了云原生安全技术规范（CNST），同时联合公安部第三研究所发布了针对云原生和云应用的安全可信认证。

2022 年，公安三所编写等保2.0的容器云安全增补部分（征求意见稿）。

除此之外，各个行业或企业也在根据自身特点进行标准制定。

标准规范的推出和成熟，侧面反映了其必要性和重要性，也为产品研发和用户采购指明了方向，有较强的借鉴意义，降低了行业摸索走弯路的成本。容器云安全产品应该包括哪些功能，为用户创造哪些价值变得相对比较明确。

各家产品竞争激烈

今年RSAC创新沙盒大赛10强里面，有4家参赛企业选择了容器云安全相关领域，足以让我们感受到这个细分领域的热度。而在国内，我们看到有大约二十几家企业进入到这个赛道。其中既有奇安信、启明、绿盟这样的传统安全厂商，也有青藤这样的后起之秀，还有以小佑为典型的创业公司。笔者估计，未来会有更多的厂商参与进来。容器云安全的未来市场被看好，因此在需求还未完全释放的阶段，竞争已经提前进入了白热化。同时，竞争促使产品功能的同质化也日趋严重。

 

容器云安全产品探讨

作为容器云安全细分领域的老兵，笔者曾见过多家厂商的容器云安全产品，也曾亲自主导设计过某厂商的容器安全产品，后来又转到某甲方客户运营容器云安全。基于这几年的个人经验，用几个话题抛砖引玉，供大家参考。

三大核心功能

从用户需求出发，容器云安全产品应具备的功能应至少包含 “合规检查” 、 “镜像扫描”和 “入侵检测与响应”。这是最核心的需求，也是目前所有厂商的容器云安全产品都具备的功能。

镜像扫描：由于“不可变基础设施”的特性，对容器的漏扫可以通过镜像扫描来实现，对容器的加固也需要通过镜像加固来实现。镜像扫描有一些不错的开源工具，例如Clair、Trivy，但这些开源工具的能力是不够的。一方面，扫描的深度应当细化到组件层面，与SCA功能结合起来。另一方面，扫描出来的漏洞如何管理，漏洞影响了哪些资产，哪些漏洞应该被优先修复，都是容器云安全建设中需要考虑的问题。商业产品的功能完整度上普遍较好一些，但也参差不齐。

入侵检测：入侵检测是网络安全攻防演练中最有价值的能力，但也是有难度的功能。容器云面临的攻击手段，与主机有很大相似性，例如反弹shell、账号提权都是常见方式。两者也有一定区别，因此MITRE针对容器场景单独推出了一版ATT&CK框架，用于指导容器云安全建设。但在实际做入侵检测时，大多数容器安全产品只能基于单条指令去匹配规则，而不能基于上下文联系进行综合分析，自然也无法将检测到的攻击方式映射到攻击链的具体阶段。此外，大多数容器云安全产品的入侵检测准确率也有待提升。

合规检查：合规检查是一个容易实现的功能，比产品实现更需要关注的是如何根据企业自身情况建立一套合适的容器云安全基线。在这一套安全基线中，除了包含k8s与容器，也可以考虑运行在容器云环境中的数据库安全基线和其他各类中间件安全基线。

微隔离

作为2019-2021年的热点，市面上涌现了大量的零信任产品或零信任方案。而作为三大核心技术之一的微隔离，自然也不会缺席容器安全领域。基本上国内的主流容器安全产品，均提供了“微隔离”的一级菜单，其实现方式往往是通过Kubernetes自带的NetworkPolicy或者Linux自带的IPtables。作为一种技术，NetworkPolicy能提供细粒度的网络层隔离，理论上能够满足大多数场景下的配置需求。但是在实际运营中，大量的繁琐的配置工作使得该功能特性的落地非常困难。同一个业务软件的内部之间的各种通信，不同业务软件之间各种通信，都需要预先配置在白名单中。稍有不慎，便有可能因为缺少配置导致业务受影响。为了保密性而影响可用性自然是得不偿失，因此现有微隔离产品将重点放在阻断是不合适的，更适合在安全运营中推广的应该是告警模式。

第一步：以业务应用为单位，对容器的网络行为进行学习，构建网络行为模型；

第二步：在构建完成模型后，对于偏离的流量进行告警；

第三步：运维人员对告警进行排查，确认是准确告警还是误报。如果属于误报则对模型进行修正；如果是攻击事件，则进行阻断处置；

上述方案有两个优点，一是没有繁杂的配置，减少了运维人员的工作量；二是只产生告警不影响业务可用性。这个方案也存在挑战和技术难度，构建的网络行为模型如果不准确，有可能产生大量误报，使得安全运营人员疲于应对，结果仍然会弃用此特性。

部署形态

容器云安全产品的部署形态，可以有四种选择，主机Agent、平行容器、sidecar容器、无Agent。

国外的容器安全产品，例如Aqua、Twistlock、Stackrox、Neuvector，多采用平行容器的部署形态。国内的安全厂商，如果原来有主机安全产品，则倾向于在主机Agent上进行扩展，一个Agent同时负责主机安全与容器安全；如果是新创业的容器安全厂商，则倾向于采用平行容器的方式聚焦容器安全。

从用户的角度，少安装一个Agent意味着少占用资源，同一个平台意味着管理成本的降低。所以大多数场景下，主机Agent的部署方式会更受欢迎。但是平行容器也有明确的支持者：

主机安全职责与容器安全职责归属不同部门；

已采购的主机安全产品不具备容器安全能力，迫使其必须单独采购。

采用sidecar容器部署形态的产品会少很多，一方面是由于其资源占用较多，另一方面是由于对业务Pod存在一定的侵入性，使得该形态的安全产品在推广时面临较大阻力。如果是借助Istio这类Service Mesh技术，则必须承认当前Istio的普及程度也非常有限。

另一种比较有意思的是无Agent部署方式，Orca是其中的代表厂商，Orca的方案里，云主机上不会安装Agent，但会对云环境中的块存储进行快照，然后通过快照重建完整的“上下文”，对其进行安全扫描和分析。这个技术方案叫SideScanning，其特点如下所示。优点与缺点都非常明显，但笔者不太推荐这个方案。

无代理，对块存储也只需要 “只读权限”，所以不会对业务造成影响；

部署速度快，通常半个小时内完成部署；

对资产覆盖完整，具有完整的上下文；

集多种安全功能于一体，包括控制平面和数据平面的安全；

准实时，而非实时分析；

只具备分析能力，不具备拦截和阻断能力

总结一下，笔者认为相对主流的方案是主机Agent和平行容器两种方案。至于这两种方案之间如何选择，用户可以根据自身场景进行合理的选择。

	主机Agent	平行容器
功能覆盖	从主机安全向上做，覆盖容器安全；	主打容器安全，可以涉及主机安全但功能普遍较少。
是否具备容器天然优势	不具备容器的天然优势：1）不同底层环境需要逐一适配；2）扩缩容需要人工干预；	享受容器的天然优势：1）兼容性强，可快速移植至各种不同底层环境；2）可随集群规模进行动态扩缩容，无须人工干预；
资源占用	一个Agent	一个Agent+一个平行容器
部署要求	需要获取主机的root用户权限，存在影响主机操作系统本身稳定性的风险；	主机节点上需要已安装docker或其他容器组件，不需要获取主机root权限
适用场景	客户环境既有非容器主机（未部署docker，运行传统应用），又有容器云，且希望用一套软件进行统一管理	1）客户已采购其他厂商的主机安全软件，再部署主机agent会产生冲突；2）目标明确，定位清晰，只是采购容器安全平台；

开源社区
 

云原生社区非常活跃，孵化了大量合规与安全类的开源项目，例如大名鼎鼎的扫描工具Clair、Trivy，集群合规检查Kube-bench、通用策略引擎OPA。在去年，红帽收购 StackRox、SUSE收购NeuVector后分别将这两款优秀的容器安全产品开源。基于此状态，容器安全产品开发的技术门槛被大大降低，参与此赛道的厂商可能会增多。一些有安全开发能力的企业也可以基于开源工具进行二次开发，从而节省采购成本。

用户选择采购商业产品，还是基于开源自研，与多种因素有关，在此不做过多探讨。但笔者建议商业产品的开发商减少对开源安全工具的依赖。开源代码加上简单封装，可以快速得到新的功能扩展，但如果没有对源代码进行详细研究，便无法避开里面的坑，无法打造真正的优秀产品。

 

容器云安全发展趋势

随着需求的持续增长，竞争的加剧，容器安全厂商需要继续优化产品。用户也会根据实际安全运营中的反馈，在容器云安全建设中进行调整。按照笔者的认知，无论是容器云安全产品，还是容器云安全建设，都有很大的进步空间。

深度发展

容器云安全作为新兴交叉领域，需要的人才既要懂容器云，又要懂网络安全。因此，其学习曲线较陡峭。这也导致了人才的缺乏。无论是甲方客户还是乙方厂商，在招聘这方面的人才时都不容易。而由于容器安全人才的缺乏，使得无论用户还是供应商，在产品 PK 时很容易流于表面，比拼功能数量，而非深入测试产品的安全检测能力与性能。在产品采购后的安全运营中，追求“不出事”，而不是防御的有效性。

未来，随着越来越多人了解容器云安全，以及真实的增长的安全需求，会促使人们关注点回归问题本质——是否能检测和拦截大多数容器攻击，保护容器云上的数据安全。要实现这一目标，并不意味着功能模块的增加，而是比拼安全研发团队的沉淀。

如何能准确识别更多的漏洞

如何能准确识别更多的已知攻击

如何有效防御未知攻击

如何同时降低漏报率与误报率

对检测的问题是否能够自动拦截 / 加固 / 修复

要实现更大的进展，当前大多数容器安全产品采用的用户态进程检测是存在不足的，也许内核态的ebpf技术能够发挥作用，也许对“指令序列”的检测能够发现更细的问题，这都有待于进一步的调研和验证。

广度发展

2021年，Gartner提出了新的概念CNAPP- 云原生应用保护平台。不同于容器云安全重点关注运行时安全，CNAPP覆盖了云原生应用的全生命周期，包括代码安全，软件成分分析等等。

CNAPP的提出反映了整合的理念。对于用户而言，使用统一的平台，而非零散的烟囱式工具，可以有更完整的安全视角。但这个场景可能并非适用于所有用户，因为有些用户的研发测试环境与生产环境是网络隔离的。用户在建设容器安全时，可以结合自身实际情况，选择合适的建设方案。

 

结束语

综上所述，容器云安全领域面临着很大挑战，同时也充满了机会。但毫无疑问，它会越来越重要，也会越来越好。欢迎感兴趣的读者共同研讨，让容器云安全未来的发展之路更加清晰。

 

来源：技术思维创新