高度概括
主要对云原生安全、容器安全、K8s安全有一个全方位的了解和一些些研究。
见闻
定义云原生
云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。
这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。（来源CNCF）
云原生安全?
云原生安全又两层含义：面向云原生环境的安全和具有云原生特征的安全。
面向云原生环境的安全目标是防护云原生环境中基础设施、编排系统和微服务等系统安全。
具有云原生特征的安全指的是云原生特性的各类安全机制，主要有具有弹性、敏捷、轻量级、可编排等。
云原生环境的安全体系主要围绕着基础设施、编排系统和微服务进行构建。
以上都是来自《云原生安全-攻防实践与体系构建》的总结，这本书在入门云原生安全作用是相当滴大。
接着来结合虎年的经历说说我的云原生安全见闻。不重点讲技术细节，之后如果有时间会单独写(挖🕳)。
日常
主要做两个事情，容器运行时安全和k8s安全。其它的比如镜像安全、基线合规方面没有参与，这两块的开源目前做的都已经不错了，直接进行复用也是可以的，需要花费的时间点在于如何适配。
这个研究怎么开展呢？从攻防角度来看，先整个ATT&Ck矩阵开局是安全人员比较舒适的方式。ATT&CK的官方容器安全矩阵也是借鉴了微软的，建议直接看微软的矩阵，更详细点。微软的矩阵是以k8s为主，容器方面除了宿主机原有的威胁，新增的也不多，主要集中在容器逃逸方面。
运行时安全
运行时安全，主要做检测容器内是否出现攻击行为。
参考开源的运行时安全检测软件Falco 从技术层面的角度来说就3层，采集->规则匹配->告警。
采集和规则匹配就是运行时安全检测能力的关键。采集作为基础，规则匹配作为上层。
实际上规则匹配作为上层，技术实现上并没有什么特别，可以直接复用端上的规则引擎到容器场景下。不过这里有个点要注意
- 端上的规则在容器中无法做到100%的直接复用，例如进程规则上，容器如果是基于alpine构建，那么就会出现busybox进行代理的情况，这样在对进程树匹配时，会不起作用。所以做采集测试验证规则时最后在容器场景下复现，并且多用几个类型的镜像。
Falco的规则有一套自己的语法，表达效果也很强，不过没有正则，可能对于国内大量使用正则进行匹配的方式不合适。
采集方面，围绕进程、网络、文件、系统调用这4个方面开展。说几个经常会碰到的情况
- 采集数据量过大，性能限制，无法全量上报，导致规则引擎没有数据输入源
- 有些进程启动时间过短，无法采集到数据，进程树没有信息
- 不同内核版本的采集需要做适配，例如ebpf在高内核版本适用，但低版本内核就需要使用其它实现方式
- 大量的临时文件生成也需要采集上进行过滤，否则要boom！
- 系统调用，如果单单检测调用的话，那误报漫天飞，可能在参数上进行一些限制，效果会更好
不同采集的实现方案，会有不同的优劣，也还是依照自身的情况进行选择。
在运行时安全检测时，规则的质量就一定程度上决定了效果的好坏。
上面提到容器和终端的情况不完全一样，所以容器在写规则时一定要重新验证下容器内是否会产生设想的采集数据。
容器面临的威胁除了宿主机面临的威胁外，由于自身特性，引入了新的威胁。
在初始执行阶段，引入Docker Daemon未授权、后门镜像，应用程序的漏洞依旧重点照顾对象。
持久化在结合Docker Demon未授权利用后，直接部署容器反弹shell或者特权容器进行后续逃逸。
权限提升这块，主要是错误配置和挂载、组件漏洞、内核漏洞，其中错误配置和挂载是提权常用的，错误配置包括特权容器、高权限CAP等，错误挂载主要是Docker.sock、主机路径等。实际上这些危险配置在业务是很常见的，容器的内的权限不同于宿主机上，为了节约时间成本直接就放开最高权限，这是一个原因。还有一种情况就是用到的开源组件，基本也都是需要高权限运行的，这也是常常会被忽略的一环，例如Docker.sock在对容器日志进行收集时经常使用。这块之后也会成为很大的风险点，不过现在还处于业务转型阶段，野蛮生长，那都是后话了。
不过到最后会发现，规则能解决的问题有限，很多行为都是疑似行为，需要有的放矢，重点聚焦在提高攻击检出精确度，而不是All in one，虽然一定程度上会有漏报，但是有其他技术可以兜底，否则规则中误报排除操作空间其实不大，并且效率很低。这个是个人经验，仅供参考。
像下图Falco的规则，如果直接用的话，那误报是能刷屏…
或许是机器学习。大体的思路就是通过机器学习去学习容器内的进程、文件、网路、系统调用的基线情况，从而识别出偏离基线的行为。
不过这里有一个很明显的问题，如果避免模型污染？在业务运行的情况下，没法让你按照理想的状况进行学习，大部分是业务的数据，但也可能混杂了攻击的黑数据，和未知的灰数据，这也没办法避免。解决这个问题灰为运行时安全检测能力上升一个台阶。
K8s安全
聊完运行时安全，主要聚焦在容器方面，接下来把说说K8s。
从微软的矩阵可以看出，K8s的自身特征就引入了很多新的攻击手法。
对于K8s面临的安全威胁，需要采取多种手段来进行防护。基线合规、日志审计、动态准入控制等
基线合规就比较简单，CIS已经有具体的手册了，不过有些威胁手册也并未覆盖到。
日志审计是K8s攻击检测的主要手段了。原理就是通过收集k8s的审计日志，分析攻击所产生的日志数据，提取特征从而使用规则进行防护。也是规则工程。
和运行时检测时规则面临一样的问题，规则如何去处理大量的上报数据，除了通过分析过滤无用的日志数据，还需要更好的办法。毕竟现在的集群规模越来越大。
日志审计也是只能解决部分问题，例如匿名用户绑定管理员、未授权请求API Server、K0otkit(部分)等，对于像入侵Pod后SA的获取这种行为只能让运行时检测。还有比如SiderCar注入、恶意注入控制器等这一类的问题，实际上特征很弱，并不能够精准检测。对于不经过k8s api server的事件也无能为力。
动态准入控制，可以通过验证和变更控制器来避免攻击者通过k8s来部署恶意pod。
当然这里也是可以机器学习，通过学习k8s API Server的事件，对整个集群的请求流转进行检测，从而发现异常。不过这个目前的效果还要打个大大的问号。
实战？
实战的话，dddd。虎年虽然在容器方面新增了规则，但是个人在实际情况中并没有发现真实有效的事件，这里就不多说。
Future
国外经常会有一些云原生相关的攻击手法，但大部分的话还是聚焦在Azure、GCP、AWS这三家头上，很多问题都是在功能实现上留下的坑，真正能够通用借鉴到国内的东西其实不多。国内的云平台建设上基本还是在学习阶段，并且需要适合国内的现状。
Kata?gVisor?这两个内核技术没有研究，业务目前也没有碰到，也侧面反映国外这块的技术栈时要领先国内的。但是国内是不是要使用这一类技术，也说不准，且看后续发展。
Kata和gVisor都是为了解决一个问题，那就是容器和宿主机共享内核，导致内核漏洞可以直接达到容器逃逸的目的。
Kata和gVisor解决的方法，思路相同，但实现不同。Kata通过构建轻量级虚拟机（VM），重新生成一个内核，脱离于原有的宿主机内核。
