云原生技术以其高效、稳定、快速的响应，持续驱动企业业务发展，成为企业数字化业务创新的核心驱动力应用程序。但与此同时，云原生环境中的各种安全风险与日俱增，越来越多的企业开始探索云原生环境下的安全架构设计方案。在不久前由51CTO内容中心策划推出的【T·TALK】系列活动第八期中，我们特别邀请了小优科技技术总监白黎明，以《云原生安全架构设计最佳实践》为主题进行分享。聚焦云原生发展趋势、安全风险、安全架构设计等，【T·TALK】也整理了本期分享的精彩内容，希望能给大家带来一些启发。云原生发展趋势2013年，Pivotal首次提出云原生的概念。2015年，Pivotal在其书中首次正式定义了云原生的5个因素：符合云原生应用的12个因素、面向微服务的架构、自服务的敏捷架构、基于API的协同抗脆弱性能A满足以上五个特征的云原生应用，就被认为是云原生应用。2015年，云原生计算基金会（CNCF）成立。CNCF在成立之初就定义了云原生：应用容器化、面向微服务架构的应用、容器调度只要满足以上三个方向的特征，就属于云。本机应用程序。2018年，随着云原生技术的发展，CNCF基于最新的云原生基础设施重新定义了云原生：容器化服务网格微服务、不可变基础设施、声明式API只要以上五个方向的特征就属于云本机应用程序。随着云原生技术的不断变革，容器化进一步简化了操作系统的功能和特性。为了满足云原生定义中基础设施不可变的条件，云原生操作系统应运而生。其特点是内核高度精简，只保留容器相关的依赖库，使用容器客户端作为包管理器。云原生操作系统的共同概念是所有进程都必须在容器中运行。操作系统的宿主计算机上不能安装任何应用程序，以确保操作系统是完全不可变的。这就是所谓的immutableinfrastructure，也是操作系统未来的发展趋势。早期的基础设施运行在物理机上，随着基础设施的变化，应用开始运行在虚拟机上。容器时代，所有的应用都运行在容器中。在最新的流行趋势下，目前国内外一些云厂商都在提供相应的基础架构——Serverless无服务器技术。在物理机时代，基础设施通常以年计算。当一台物理机安装到机房后，它就会被下架，生命周期为一年或五年。后续虚拟机使用月作为计算单位。在容器时代，每次更新都需要重新构建一个新的容器，所以容器的生命周期以天为单位。Serverless时代，功能虚拟化是以分钟计的。容器化出现后，加快了容器技术标准化的进程。DevOps和容器相辅相成。应用容器平台，需要演化为DevOps开发模式，加速发布进程。容器化的便利促进了DevOps，容器依赖于DevOps来加速迭代。这是当前发展模式的演变趋势。当以容器为单位时，云原生和服务就是网络边界。在云原生领域，没有IP的概念。云原生所有的IP都是动态的，我们在传统的防火墙上无法配置对应的IP地址。在云原生中，容器服务每天都会更新，每次更新IP地址都会是一个新的IP地址，之前配置的网络策略会失效。物理机时代，物理机很难上架，所以通常在一台物理机上运行多个应用。在虚拟机时代，为了提高服务的可用性，通常会将单个服务拆分成单个虚拟机。到现在，随着服务接口越来越多，对微服务的依赖越来越多，需要将接口演进为微服务架构。以微博为例，当发生热点事件时，无论是物理机还是虚拟机，都需要以小时为单位进行长时间的搭建，才能实现业务恢复。在容器化场景下，容器秒级启动，启动速度远超物理机和虚拟机。所以，微博进化成容器架构后，因为热点事件而崩溃的情况已经很少见了。当然，K8S平台的自愈能力和动态伸缩能力也功不可没。早期的容器运行时使用的是Docker，所以容器在当时常常被等同于Docker。容器本身分为四个模块，Docker也分为四个接口。但是因为Docker是一个完整的开发包，而K8S在运行的时候只是用到了runtime端。因此，在运行效率的要求下，K8S在1.20版本逐渐不再支持DockerShim，而是直接使用DockerContainerd。无论是Containerd还是Docker，对安全能力的支持都不是很完善。Cri-o技术可以满足相对安全的要求，不需要守护进程，每个Cri-o进程可以有一个独立的进程，一个父进程和一个子进程，作为一个服务运行。容器领域未来的趋势是底层基础设施的安全，包括安全的技术容器化。云原生安全风险目前云原生领域需要考虑的安全问题主要有以下五点：镜像安全、镜像仓库安全、集群组件安全、容器网络风险、微服务风险、镜像安全风险比较广泛。相比基础设施安全，云原生领域更关注性能优化和基础设施容器化。这也导致目前DockerHub镜像有51%存在高危漏洞，80%存在中低危漏洞。90%的情况下，企业在构建镜像时，需要从DockerHub下载镜像。在镜像仓库方面，企业不可能将所有的研发镜像和业务镜像都上传到一个公共镜像仓库，源代码需要存放在企业仓库中。但是，企业仓库也存在安全漏洞。这些漏洞被黑客利用后，会直接导致仓库镜像被替换。从节点拉取镜像时，拉取同一个镜像可能拉取的是带有木马病毒的黑客镜像，也是非常危险的。关于集群组件的风险，目前Docker自身存在111个漏洞，K8S存在65个漏洞，OpenShift存在35个漏洞。Cri-o、Containerd和KataContainers等其他容器运行时共包含45个漏洞。集群组件漏洞相对较少，但仍然存在。黑客通过上述漏洞入侵集群后，会继续访问集群中的其他容器。物理防火墙只能保护集群外的流量，集群内的流量K8S有overlay和underlay两种网络架构。但是无论是overlay还是underlay，传统的防火墙都无法防范集群内的攻击，这就是集群内的网络风险。业务图像中的漏洞还可能导致另一个问题，即内置图像组件的漏洞。如果开发者引用的API或者使用的一些开发框架存在漏洞，那么开发者将开发组件打包到镜像中就会出现这样的问题。此前影响广泛的Spring框架0day漏洞，由于基础设施漏洞影响了国内近90%的企业。这种风险通常是研发引入的，也就是微服务的风险。云原生安全架构设计之前的基础设施主要靠防火墙和物理安全来维护。对于容器的计算环境，容器运行时安全和镜像安全需要专业的容器安全防护。容器应用安全需要相应的容器安全来进行微服务发现和无服务器保护。在云原生场景下，需要将研发安全体系纳入云原生安全领域。这与传统的安全性不同。研发人员必须参与安全建设体系，在研发过程中时刻关注云原生数据安全和一些安全管理权限。在小优目前的容器安全中，内置了很多策略和机器行为学习策略、处置策略和事件。这些功能之一是文件审计的编排。可以直接对接开发者的代码仓库，从代码仓库中读取代码仓库中所有已有的Dockerfile文件、Yaml文件、布局文件。并通过Dockerfile文件推断语法，找出命令中的问题。审核完成后，如有问题，将反馈给研发人员，并禁止构建镜像。如果没有安全问题，直接修改反馈，修改完成后生成图片。这个时候会把镜像倒转成Dockerfile，将镜像和Dockerfile进行比对。如果发现Dockerfile被篡改，也会发出警告。另外，基于镜像运行的容器业务也会进行逆向，检查容器依赖的镜像是否正确，镜像中运行的进程是否与Dockerfile中打包的进程重名等。如果有发现不一致，会发出警报，报告此业务存在风险。云原生是不可变的，不可变的基础设施包括底层操作系统和镜像，所以镜像也是不可变的。什么样的Dockerfile文件，镜像就得对应构建。镜像是什么样子的，运行的容器一定不能超过这个范围。另一个特色功能是直接从代码仓库中读取Yaml布局文件。以及编排文件的权限限制，如果编排文件中存在语法过时、语法错误、高危命令等危险参数，则会发出告警。这样做的目的是把安全、运维、研发联系起来。云原生的安全，必须要运维人员、开发人员、安全人员共同处理，不是安全部门的问题。目前市面上有很多开源的镜像组件扫描。镜像世界容器安全防护平台开源版与商业版最大的区别在于自定义规则和漏洞库。开源漏洞库基于开源CBE漏洞库实现，支持中国CNNVD漏洞库。中国的CNNVD需要合作获取，正常的开源厂商无法获取CNNVD漏洞库。这是开源和商业最大的本质区别。在商业版中，针对漏洞的自定义功能，如可信镜像、基础镜像识别、主机镜像扫描等功能，在开源产品中是不存在的。镜像仓库存在安全隐患。在企业内部构建安全能力时，必须对镜像仓库本身进行漏洞扫描。小友参与了整个Harbor安全漏洞的维护，所以我们在这方面有一定的优势。集群组件也有风险。为了发现集群组件的风险，首先需要结合集群本身，根据漏洞数据库和漏洞版本进行比较。同时，无法通过版本对比识别API接口漏洞和权限漏洞。需要一些POC检查方法来检查整个集群组件漏洞的风险。扫描整个集群自身组件的配置，扫描并配置自身的权限。最早的K8S默认是不开启认证权限的，现在默认是https。另外，对于审计日志是否开启等功能，需要配置合规性检查基线进行基于集群安全的扫描。在云原生微服务场景下，服务拆分将导致量级呈指数级增长。这时候就需要安全软件自动发现微服务，并识别服务类型，以便使用相应的方法进行服务。自动漏洞扫描检测。这是一种非常省力的方式。容器运行后容器内部的安全检测可以通过两种方式进行。一是机器行为学习。通过从图像中学习容器内部的一切，容器的行为被固化。同时学习容器的文件读写、进程启停、访问调用，捕获所有的运行行为，并记录到行为模型中，再汇总到容器的行为模型中。所有容器运行的流量都认为是正常流量，所有的排放都认为是异常流量。但学习需要时间，如果在学习过程中遇到攻击或执行命令，结果就会有偏差。对此，可以内置攻击模型的策略，当发现有行为命中内置的安全策略时，直接排除。这样就可以结合机器行为学习来防御0-day漏洞，同时防止学习过程中发生攻击。结合机器行为学习的黑名单内置策略组合，可以实现机器运行时安全检测的完美闭环。这是当前安全运行容器的最佳实践。在云原生领域，云原生微隔离必须实现以下功能：第一，访问关系的可视化。因为云原生隔离本质上满足了零信任的风险。K8S没有IP概念，基于Label。标签是研发人员和业务人员应用的标签，微隔离是根据标签动态进行的。因此需要根据学习关系自动生成容器策略，并对策略进行演练。策略学习完成并确认后，会进入预演模式，此时可以设置预演时间。在一定时间内，不会阻塞所有正常流量。当发现流量受到该策略的影响时，将发出警告。研发人员或业务人员会做出人为判断。如果业务流量是安全的，他们将编辑机器行为学习模型并将其从模型中排除。一定时间后，如果没有发现其他流量，学习到的策略将不会影响正常的流量模式，可以抵御所有的流量攻击。此时点击政策执行，生产业务不受影响。将自动学习的策略应用于生产环境。最后一点，在云原生领域，云原生安全软件平台必须符合三层架构：第一层是管理层，管理平台必须与任务中心解耦，所有集群可以收敛。当镜像仓库数据量过大时，可以直接将扫描集成到仓库镜像中，扫描的同时直接读取存储路径，而不是依赖网络带宽拉取镜像。这样可以大大减少网络占用和磁盘IO占用，直接读取。这是目前容器安全的最优架构设计。云原生安全最佳实践云原生环境下的DevSecOps设计主要分为三个部分。第一部分是构建阶段。这里小优科技提供了一个金镜库，里面收录了所有加固过的科技镜。研发人员可以直接从黄金镜像仓库拉取，构建业务镜像。小优与CNNVD有官方合作，其漏洞库更新后会直接同步。小优也会根据每天的漏洞更新，实时维护自己的黄金镜像仓库。此外，小游有自己的扫描器和专业的安全研究人员，他们将对最新的漏洞和0-day漏洞进行研究。建议企业拆分两个镜像仓库，在集群中的生产镜像仓库设置信任判断。这样可以有效防止黑客进入集群，直接拉下自己的一个业务容器。使用一个K8S接口拉取所有黑客自己的镜像，可以直接进行所有渗透。这种情况是完全可以避免的。镜像的扫描阶段是扫描配置，扫描业务研发应用层的配置。如果发现漏洞，同步将被阻止。在生产环境中可以设置信任判断，将所有条件都纳入信任判断中，比如是否使用企业自有环境镜像仓库，可以在平台上自由配置。集群自身组件的风险评估和微服务的漏洞也可以利用平台上的一些功能来实现。以镜像漏洞扫描分析为例，可以对镜像进行拆分和拆解，从而识别出每个镜像依赖于谁。技术影响组件、软件组件分析、源码扫描和开发安全扫描、应用漏洞扫描等。当容器安全平台检测到攻击事件时，会在事前、事中、事后进行全面的安全防范。提前对整个集群进行评估和加固，加固完成后开始所有的行为学习。事中进行威胁排查和0day防御，所有告警实时报警。当发现攻击时，首先阻止镜像运行。在研发阶段，可以防止上传图片。在仓库阶段，可以防止镜像下载。在生产环境中，可以防止镜像运行。容器运行后，镜像可以自动或手动执行隔离策略。并设置自动处理和手工处理的规则。对于云原生网络安全规划，由于不同集群之间的网络域不同，默认情况下，K8S网络插件是各个集群之间物理网络的overlay网络插件，所以网络域自然会根据关于集群之间的关系。划分网络安全域。云原生微隔离必须支持IPblocking。必须兼容ZeroTrust和Labelblocking方式，同时支持IP配置。这就是云原生安全平台的规划方式。同时，还需要用好传统安全防火墙，不仅需要专用的云原生安全防火墙，还要结合传统防火墙进行安全防护。0day攻击防御可以基于五个维度进行建模：通过学习容器中的行为来构建安全模型；在检测模型外进程、文件访问、异常网络连接、系统调用时，通过关联人响应处理分析产品风险事件列表，及时阻断异常行为或纠正错误。在测试环境生成模型，直接应用到生产环境，无需重新学习零漏洞流程。支持0day风险流程的启停。在一定的学习周期内，读写文件的过程需要学习。比如学习期过后，突然尝试暴力破解这样的数据库，短时间内出现大量的网络错误和验证错误攻击，直接认为不符合学习规格。包括系统调用和配置。前四个维度是学习已经运行的容器的行为，最后一个是学习运行前的行为，预测运行前的状态。这些是学习的五个维度。并且通过历史容器和之前所有容器记录学习，防止0-day攻击。嘉宾介绍白黎明，原联众游戏云原生平台负责人，7年DevSecOps研究与建设经验，现为小游科技技术合伙人。国内首款云原生安全产品核心设计者，公安部《等级保护 2.0》和信息通信技术研究所?的主要起草人。
