文/chengable
PS：全文4000+字，把Twistlock掰开揉碎给大家讲讲，能完整看完的人可能不多，能耐心看完应该会有所收获
一、容器安全市场
容器安全是近几年比较火热的一个细分领域，Gartner虽然把容器安全放到了CWPP领域，不过前两年很多CWPP厂商似乎还没回过神来，Gartner也推荐全球用户可以寻找专门的容器安全产品来补足老牌CWPP厂商不支持容器的这一问题，于是乎，出现了一批专门做容器安全的厂商，比如Apcera、Aqua、StackRox和Twistlock等。现在来看，一些比较大的CWPP的厂商，和做容器安全做的比较好的厂商，都在做云工作负载安全的统一管理，把主机安全、容器安全、Serverless安全都放到一个产品里去，用一个控制台管理所有的云工作负载。
Apcera、Aqua、StackRox和Twistlock，这几厂商都有着不错的容器安全方案，今天我们主要聊Twistlock，如果有对其他产品感兴趣的可以评论或者留言，我去分析分析再发文章出来
二、Twistlock产品分析
分析一个产品，我个人倾向于从产品理念、市场宣传策略开始，看做产品的人自己认为，自己产品最突出的能力是什么，击中的是哪些客户痛点，再到大体的功能架构设计，再到具体到每个功能（技术能力不错的同学可以再深入到每个功能的大致技术方案和效果），时间充足的话分析一下UI和易用性相关的设计，最后总结一下产品的亮点。
如果不是做竞争分析的话最好别做优劣势对比了，抱着学习的心态学习其他产品好在哪里就行了，当跟自己的产品对比的时候，我们往往带有个人倾向，不客观，人嘛，难以免俗的。
扯远了，今天我们主要从Twistlock的产品理念，功能架构，主要功能分析、亮点总结四个方面剖析一下Twistlock，额外提一下Twistlock产品里也不只有容器安全能力，也包括主机安全和Serverless安全，不过以容器安全方案最为著名，我们今天重点在它的容器安全产品力上。
1.产品理念
产品理念最直接的就是从官网和白皮书获取，Twistlock被Paloalto收购后，产品资料可以从PA的官网获取。
Twistlock整体的产品定位是：构建跨越整个应用生命周期的容器安全体系。谈到跨越应用生命周期，自然我们就会想到DevSecOps，涉及到容器相关阶段在Build、Deploy、Run阶段
我们能看到Twistlock宣传几个核心能力，1）漏洞管理；2）合规&基线检查；3）运行时防护；4）响应与取证；5）CI/CD安全，整体覆盖的容器安全点是，容器的镜像安全、仓库及签名管控、CI/CD集成、容器及编排平台基线安全、runtime流量安全及控制、runtime主机安全及控制，基本覆盖到了容器生命周期做面临的安全挑战。
漏洞管理的通过描述分析，从介绍中看漏洞库就是CVE，可能有点偏少，特点是结合了漏洞优先级分析，能够展示容器每层的漏洞。
合规管理，这个是老生常谈的问题，虽然技术上比较简单但是对用户来说是重要的，twistlock支持K8S与Docker的CIS基线，符合的PCI DSS, HIPAA, GDPR和NIST SP 800-190等标准。
运行时防护，覆盖进程、网络和文件的Sensor来感知行为，特点是自动化创建运行时策略，支持策略的深度自定义。这里的Sensor不是agent而是daemonset模式在每个node上起一个平行容器，不过需要申请特权（不是特权容器，仅用到某几个权限），用于监控行为，这个具体下文再详细讲。
网络可视化，这个比较好理解，主要是网络层面的流量可视化与以镜像为维度的网络控制。
事件响应与取证，这点基本也是安全运营类产品必备的能力，除了基础审计之外还有基于杀伤链的行为分类，另外，Twistlock的响应能力是比较完整的，包括命令控制、进程控制、网络控制、文件控制等。
CI/CD集成，这部分主要是对容器镜像扫描部分，左移到DevSecOps的Build阶段,对镜像安全进行扫描，且与各种CI/CD平台良好集成。
以上是Twistlock产品的整体理念和它想传达给客户最核心的能力，接下来对整体功能架构做个分析。
2.功能设计分析
我们看Twistlock产品，能看到他的核心功能设计如下：
雷达图（Dashboard）
防护
容器网络防火墙
运行时
漏洞
合规
权限
监控
安全事件
运行时
漏洞
合规
配置管理
系统日志
Defend安装
权限分配
插件下载等
主要是三个大模块，Radar、Defend与Monitor,当然核心的是Defend与Monitor
2.1 Radar
Radar图相当于一个Dashboard。首先，雷达图中有多种展示维度，默认的是按镜像展示；不同的图标展示不同类型的镜像，区分为在K8S平台管理的镜像或单独管理的镜像（鲸鱼与蜘蛛网）；不同的颜色代表容器镜像扫描结果的风险程度，高中低危或者安全，是否有红晕代表是否有runtime安全事件，右上角的数字代表镜像被run成了多少个容器，图标之间的连线代表镜像之间的访问关系。
我们从产品的角度去分析的时候，第一点关注的是默认的展示方式是按镜像展示，为啥要按镜像展示，为什么不是按容器或者IP去展示？在K8S容器网络中容器本身是弹性扩展的，并且K8S本身就抹去了容器自己的这个概念，容器的IP更加没有参考意义，所以跟传统网络的可视化不同，按容器展示或者按IP展示都不合适，变动太快，并且还要在图上展示访问关系，更加复杂，相对来说Dashboard的图最好比较稳定，不要经常变来变去杂乱无章，还要能反映真实的运行状态。
因此，按镜像展示算是比较理想的展示方案了，同一个镜像run起来的容器一般是同一种作用，所以网络互访关系也比较固定，能做到一个稳定的展示效果。在Radar图上我们能看到容器类型，容器数量，镜像安全风险，容器运行时安全状态，网络互访关系，是一种合理的呈现方式
2.2 Defend
Defend分成下包含四个子模块，容器防火墙、运行时、漏洞、合规、权限，我再加工一下，大家就清楚Defend整个大模块是干嘛的
容器网络防火墙策略
运行时防护策略
容器镜像漏洞检查策略
合规检查策略
权限控制策略
Defend主要是用于策略的设定。
Firewall模块，又分为CNNF和CNAF，这个不难理解，CNNF做四层防护，CNAF做七层防护
CNNF的策略默认是从镜像到镜像，新版中加了image to ip和image to DNS的维度，值得一提的是，CNNF有自主学习镜像间的网络访问关系的功能，也就生成一个是互访关系的白名单，白名单在用户设置的阻断策略之前生效。
CNAF则是容器WAF了，CNAF的策略可以以容器、镜像、主机、Labels的维度去做防护策略，选择要防护的对象，CNAF中除了常见的规则防护之外，第一强调了白名单形式的防护，只允许某些Header头的流量或者只允许上传某些类型的文件，当然也可以做黑名单；第二比较有特点是具备智能防护能力，比如自动抹去服务指纹、自动屏蔽敏感信息等，让人眼前一亮。
Runtime模块,主要用于运行时的行为基线策略制定，这部分最有特点的是Twistlock会自动学习容器内的正常行为，学习完成后，对于偏离行为基线的行为进行告警或阻断，也是一种白名单思想
下图展示的是学习到的某容器的进程、网络、文件、系统调用、用户等行为
当然，也允许用户自己去设定行为规则，规则对象同样为镜像、容器、主机和Labels,从进程、网络、文件、系统调用四个维度去设定行为基线规则，允许执行哪些，不允许执行哪些，对于违反策略的是阻断还是告警。也支持强大的脚本式的用户自定规则
Vulnerabilities，漏洞模块主要是用于设置镜像扫描的策略，可按容器、镜像、主机、Labels维度选择需要扫描的对象，可设置扫描结果的预期，以及不符合预期后执行的策略，是Block还是仅Alert，Block仅会阻断掉镜像run为容器的过程，已经run起来的容器并不会去强行停掉;也可设置不关注的CVE，功能比较齐全
同时Defend中的漏洞模块也支持对镜像仓库进行扫描，允许设置镜像仓库类型，地址，要扫描的镜像范围和要排除的镜像范围
Compilance模块，该模块主要用于设置合规策略，包含CIS基线，PCI DSS, HIPAA, GDPR和NIST SP 800-190等合规基线策略，同时用户可自定义单条合规检查规则的开关，方式比较灵活，检查对应也可按容器、镜像、主机、Labels维度选择需要扫描的对象。
针对从公开镜像仓库拉取镜像的行为，Compilance模块有Trust image的功能，默认的Trust image有两个条件，该镜像已经在本地生成容器了和该容器处于Defend保护之下，对于擅自从镜像仓库拉取镜像run的行为，可设置策略直接阻断或者仅告警，当然用户也可设置白名单
2.3 Monitor
Monitor包含事件，运行时，漏洞，合规四个模块，主要用于展示安全事件或者扫描结果
Events模块，用于展示安全事件，包括违反Defend中设置的Firewall/Runtime策略的异常行为，以标签化的形式展示，能够很清晰的看到各类安全事件的数量
Runtime模块，则是我们上面提到的，展示对容器内行为基线的自动化学习结果
Vulnerabilities模块，用于展示镜像扫描的结果，可以以镜像视角，CVE视角等进行漏洞查看，值得关注的是，在详细的漏洞信息中，允许以分层的方式查看漏洞是在镜像构建的哪一层被引入进去的，引入漏洞的这一层镜像增加了哪些内容，执行了哪些操作，做的很精细化
Compliance模块则是展示合规扫描的结果，同样具备多视角查看的能力
2.4 Manage
在Manage模块有主要包含Defend下载和部署、Jenkins插件、账户集成权限分配等重要配置
Twistlock与Jenkins的集成是通过Jenkins插件的形式，操作方法与常规的安全产品集成CI/CD类似，支持自由风格项目和Pipeline项目，允许用户在Jenkins流程中设置要自动扫描的镜像名称，一键生成Pipeline脚本方便用户配置Pipeline项目，允许用户设置安全阈值，设置违反阈值的操作，是Block或是继续，结果反馈到Pipeline的项目扫描结果中，这部分不过多描述
3.技术简析
这部分我们主要对Twistlock的产品能力底层的技术方案做个简要分析，包括Defender架构、流量控制方案。
3.1 Defender架构
Twistlock的整体架构其实比较简单，主要就是控制台和Defenders
Defeners是端上Sensor的统称，在容器安全中Defeners是作为容器运行，也是做容器安全的通用做法（当然也有些厂家用agent做），通过在每个Node上以Daemonset的模式运行一个平行容器，用于收集整个Node上的进程、网络、文件等数据，在K8S平台下通过Deployment去部署也非常容易，很云原生
有些厂商的平行容器是要以privilege模式也就是特权容器运行的，Twistlock仅用户模式进程运行，不过要申请四个权限
NET_ADMIN/SYS_ADMIN/SYS_PTRACE/AUDIT_CONTROL
在Defender对docker的操作上，也不是直接调用docker命令，而是通过自己生成shim，让runc直接调用
3.2 流量控制方案
查阅官网我们能看到Firewalls的大致实现方案，CNAF利用iptables做引流，Defender做流量威胁检测与策略控制，有HTTP proxy的话七层流量应该是类似Envoy的Sidecar模式去实现流量处理
CNNF中，对于每个pod或容器IP地址，Defender添加一个iptables规则，并将target设置为NFQUEUE，NFQUEUE是iptables的target，它将如何处理数据包的决定委托给用户空间程序(Defender)，当SYN消息到达时，Defender根据策略对它们进行评估，以确定是否允许连接
我们知道容器网络中用iptables是不合适的，IP变动速度太快，策略会非常多，在策略很多的情况下，iptables更新一条规则的耗时都非常大，所以Cilium用BPF的来管理流量，来获得更好的网络性能，我猜测Twistlock应该是考虑兼容性的问题，毕竟BPF所要求的内核版本还是有点高，针对广大的用户群体可能不太能做到兼容。
三、结语
各位看到这里不容易，文章篇幅比较长，感谢各位耐心看完，最后我们对Twistlock做个简单的总结，给我最大的感受是兼顾完整性与精细化，白名单思想贯彻整个产品
完整与精细：我们能看到Twistlock的整个容器安全方案非常完整，覆盖Build、Deploy、Run，容器生命周期的各个方面，在安全方案完整的情况下，产品功能也做的比较精细，比如各类规则均支持多类型对象设置，镜像漏洞的分层展示，智能化的WAF能力等，是一个比较成熟的产品。
白名单思想：在整个容器安全威胁检测中，仅有CNAF和少量的Runtime行为检测通过特征的方案检测安全威胁，大多数还是利用自动化学习行为基线，包括网络访问关系和主机行为基线，然后以白名单的方式做安全控制，这也很符合容器环境，毕竟容器run起来后不会有太多人为因素到容器内部进行操作，这种方式代替传统的杀毒、签名，性能也能控制的很好。
最后，分析别人的产品是为了做出更好的产品，脚踏实地也要仰望星空，这几年国内的安全产品也越来越注重实战效果，不仅仅是一个花架子，虽然路还有点长，但是也在往好的方面发展，希望有更多的产品走出国内，做国际安全产品的潮流与标准
声明：本文来自安全产品人的赛博空间，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
