认识达内从这里开始

云原生架构技术的应用我们在前几期的文章中已经给大家介绍过很多次了，而本文我们就再来学习一下，云原生架构技术安全面临哪些挑战。

一、挑战

1)镜像数量大。一方面，由于log4j2本身就是应用范围很广的组件，而且在微服务架构下，应用又会进行很多细粒度的微服务拆分，因此在仓库中会受影响的镜像会涉及到很多个Repositories;另一方面，由于DevOps等敏捷开发流程的使用，镜像仓库中的每一个镜像又会有很多个版本(每个Repository有很多个Tags)。因此，在漏洞处置的过程中会发现，扫描出来的受影响镜像数量巨大。

2)僵尸镜像。所谓的僵尸镜像，其实可以理解为存储在仓库中的旧版本镜像，或者过期镜像，已经几乎不会再被运行使用。如果对仓库中的镜像没有很好的管理机制，这种僵尸镜像的数量也会非常大。这种现象其实也很好理解，DevOps带来业务快速的迭代，自然就会产生大量的过期镜像。

在常规的安全运营中，这些僵尸镜像原则上是应该及时被清除的(不需要考虑备份回滚的问题，代码仓库会有)，这种清除操作不仅仅是需要覆盖镜像仓库，同样适用于主机上的僵尸镜像。

3)不可变基础设施。云原生架构的一个特征就是不可变的基础设施，所谓的不可变基础设施，是指一旦部署了服务之后决不允许被修改。如果需要以任何方式更新、修复或修改某些内容，则需要修改相对应的镜像，构建全新的服务镜像来替换旧的需要改变的服务镜像，经过验证后，使用新的镜像重新部署服务，而旧的则会被删除。

这种特性，给我们针对线上业务在进行漏洞缓解的时候带来了很大的不便。一方面体现在修改应用的运行参数和环境变量等信息上;另一方面体现在这种缓解措施的修改，会引发运行时安全的再次告警，因为这种操作违背了不可变基础设施的要求，不是正常的业务操作流程。

二、优势

•资产可视化，快速定位。资产问题一直是安全建设和安全运营中重要的问题，同时也是让人头疼的问题。云原生架构很好的解决了资产的问题，通过Kubernetes等编排平台以及镜像仓库等组件，可以让我们快速的进行资产梳理、问题定位。

•流程自动化，快速生效。Kubernetes等编排平台提供了一整套的业务自动化管理方案，包括配置管理、服务编排、任务管理等。因此，对于漏洞的修复可以实现快速分发和对应的灰度升级等。

•安全左移，快速控制。能够在CI/CD等多个环节进行安全左移检测，镜像入库前的检测，阻止包含漏洞镜像推送到仓库，降低增量风险;在运行时进行准入检测，对于包含漏洞风险的镜像，阻止其启动运行，减小线上环境新增暴露面。

•微服务架构。在微服务架构下，应用间相对独立，这给漏洞修复带来的好处，一方面，针对某个镜像的漏洞修复，影响范围小，提高漏洞修复效率;另一方面，微服务架构下，服务功能单一，很多重复的功能会形成独立服务，这样减小了修复数量。

这次漏洞的爆发，给我们在云原生安全建设和运营上敲响了警钟，以该事件作为切入点，企业在云原生架构的落地过程中，需要系统全面的考虑安全能力的建设和运营了。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。