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起来后不会有太多人为因素到容器内部进行操作,这种方式代替传统的杀毒、签名,性能也能控制的很好。
最后,分析别人的产品是为了做出更好的产品,脚踏实地也要仰望星空,这几年国内的安全产品也越来越注重实战效果,不仅仅是一个花架子,虽然路还有点长,但是也在往好的方面发展,希望有更多的产品走出国内,做国际安全产品的潮流与标准