容器云平台安全隔离方案详解.docx

《容器云平台安全隔离方案详解.docx》由会员分享，可在线阅读，更多相关《容器云平台安全隔离方案详解.docx（8页珍藏版）》请在优知文库上搜索。

1、一、云原生的技术背景当前，数字化变革己逐渐渗透到每一个具体产业，舛性算力己成为各行各业的“水电煤：云计舞则成为数字化世界的基石,从底层驶动产业变革，随着云计发展迎入成熟阶段，以“生在云上、长在云上”为核心理念的云原生技术被视为云计算未来十年的卡要发展方向。在数字化大潮中，上云并非是一种时尚，而是一种刚需，从“上云”到“全面上云”，从“云化”到“云原生化”，是企业数字化转型的必由之路.相较传统IT架构，云原生具有无法比拟的优势，将为企业带来肾低成本、提升效率、快速试错、促进创新等业务增益价值。云原生的技术理念始于NetfIiX等厂商从2009年起在公有云上的开发和部署实践.2015年云原生计算基

2、金会（CNCF）成立，标志若云原生从技术理念转化为开源实现。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式AP.这些技术能够构建容错性好、易于管理和便于观察的松耦合系统.结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更.云原生的运用使本身灾杂多变的企业业务可敬捷灵活、及时哨应、快速迭代，从而让数字化转型和运营过程中的持续创新成为可能.目前业界较为认可的构成云原生的四大核心技术要素是俄服务、DcvOps,持续交付和容器化。二、云原生环境的网络隔离诉求原生技术能物有效解决传统云实践中应用升级级援、架构睫肿、无法快速迭代等“痛点”问题，并为业务创

3、新提供动力。然而，云原生技术在:创造效益的同时.也面临着切实存在H益严圾的安全风险.*n安全2设J传陵数(中女生k)公M础电输WWl容器云平台软件供应的KfrHHAlnSMttMOsr内核安全Bzm11AAADcvSocOp1RASP光ii安全守收团件玄VBKHftttfittMft11三Iaspoast女金M件安金IHt安令M线收值安全线：,1;入他杷限校MMm*代收?!捋SAST边，女全代为开源忸，；云配置安全线APtI护代种竽计/代BMM例如,2018年特斯拉AWS上部署的K8SDashboard暴露在公网，没有做认证和授权控制,也没有对网络访问做控制，黑客百接从dashboard中获取

4、S3凭证，从而获取遥测数据，恶意拉取POD,进行挖矿行为.而“隔施”技术是最早、最基础、也始终是最为核心的安全技术手段之%Gartner提出的容器安全控制分层理论，将容器安全能力按照优先级由高至低分为基础控制(FoundationalControls)基本控制(BasicControls)和基于风险的控制(RiSk-BaSedCOntro1s)，其中网络隔离(1.3NetworkSegmentation)被划分为必备的基础控制能力。CMP.DMKkMtajflK(Fewcton-A4*MZONKSCASomwvcefo*mmM*2.K0kmnfcvQSCrtrtxlrmtSCxCyScco*p

5、Scw*CaTVuzMod213MH*8gzm0.Xy痴KreMo85TucMtfkoom4CNCF于2021年发布的E云原生安全白皮书2指出，作为微服分部署的容器化应用程序的边界就是微服务本功。因此，有必要设定策略,只允许在得到许可的微服务间进行通信。在微服务架构中)1入零信任，可以在一个微服务被攻陷时阻止其横向移动,从而缩小影晌范围.运维人员应确保他们正在使用网络策略等功能，确保,个容器部署内的东西向网络通信只限于授权网络.三、传统防火墙在云原生中的捉襟见肘基于所承我业务的属性和安全级别,传统数据中心往往将其内部划分为多个安全域并进行定制化的安全管理,在安全域间通常会部若防火墙系统实现访问

6、控制.在云平台建设初期，此类架构被相当一部分用户继续采用，井利用防火墙实施域间的访问控制策略,一屿管理水平较高的用户则基于访问源和目的IP进行了细粒度的策略规则设定.然而,随若云平行向云原生架构演进迁移，基于防火墙进行域间控制已显得与云原生环境格格不入，无法立正满足容器平台的隔离需求.防火堵的部署位置和控制对象决定了其仅能针对聘域流量进行控制，而无法实现更细粒质的业务级、工作负栽级控制.此外，鉴于策略规模对防火墙性熊的影响，其安全策略的控制时以往往仅能做到网段级，因此，确切来说，此类方案至多能筋提供用于维护数据中心基础架构完整性的“宏分段(MaCro-Segmentalion)”，而无法实现云

7、原生环境中真正所需的“微隔离Micro-SegnentHtion）”.TraditionalDeploymentContainerDeployment此外，稳定不变的IP地址是防火墙访问控制持续生效的“锚点”，而在云原生环境中，容器IP的频繁无规律变化则彻底动摇了传统架构中这一确定因素,一只容器开始新的生命周期，新的IP将直接逃逸原有价态策暗的有效管控。与此同时，由于容洪的消亡与新建在公原生环境中是高频发生的，即便能甥实时感知其变化，依靠人工删除原有策珞并建立新的策略也受无可施，而已失效的策略长时间推枳，乂势必带来防火墙系统策珞冗余、性能下降的副作用*云原生环境中，微服务的架构势必指数级的增加

8、服务间的互访调用情况和横向连接关系,给屈本就红杂度较周的东西向流搔捽制又带来了新的难度.在DeVOPS的加持下，应用彼捷、快速、持续交付部署,而安全控制措施则必须找到合适的切入点，并跟上瞬息万变的节奏。容器成为新的批小控制单元，其生命周期规律则更加难存,每次新业务上线、应用更新、扩缩容等,均会带来容器的消亡和新建,而在此过程中传统用于标识暴础设施的IP、主机名等均将发生变化，传统的安全策略框架则将被轻易绕过逃逸。由此看来，即便放弃用防火墙实现集群内流量微隔离的预期,其在云原生M境中也维以起到集群间流量的有效隔窗控制作用，在云原生架构下甚至已经失去了原先的部署位置。事实上，开始规模化韶署容器的用

9、户，往往在第时间即发现了防火噜系统几乎彻底失效的何施,从而择放出更为迫切的隔离控制需求。四、现有容器云平台隔离方案分析1、基于NetwrkPolicy的容火堵因“水土不服”而在云原生环境下彻底失效，再次鲜活证明了“安全原生化”对于云原生环境的曳要性.事实上，已成为容岩编排平台事实标准的KUberneteS（以下简称“K8S”）,通过集成NetworkPolicy功能提供了容器间的网络隔离能力。apivraion:networking.kSs.io/vlkind:NetworkPolicynetdUC4:najn:xAnpl-ln9r-p0lleyn*MP4c:ink-nPc:podSlctor

10、:m*tc1.abl:pollcyTypes:-IngressIngres*:-fro*:-nascspaceSclector:Itdtch1.abeletnotvorknanespcc:sourco*-nspodSelector:IMtch1.Abels:apiVersion:networking.k8s.iovlkind:NetvorkPoHcymiEpollcyTypes:-Egressograss:-to:-nancspaccSclectorxtMtch1.bels:network/nascspace:sink-ns-podSelector:natch1.abcls:在K8S中，Net

11、workPolicy定义了一组Pod之间的访问控制规苑，其通过1.abel指定NameSPaCe和Pod.并利用节点（Node）主机操作系统的IPTAB1.ES实现Namcspace和Pod级的网络访问控制.与外挂式的防火墙相比,NetworkPolicy实现了原生化的安全能力内嵌，但大鼠实践发明，时于多数用户而言其运用落地依然受到较大制约，存在以下突出问题：1）环境适应性的局限KlworkPolicy只定义了策略规则的规范，而访问控制能力的具体实现则需依赖K8S平台的网络插件。事实上，当前流行的K8S网络插件中，并非所有均支持NetworkPolicy功能.例如相当一部分用户使用的Flann

12、el插件即无法支持该项功能,而对干多数用户而言，为了实现NetworkPoIiCy能力而替换迁移原网络插件的成本无疑是高昂的.此外，一套NetworkPolicy策略仅能适用于一个独立的K8S集群，对于普泌具有多食K8S集群的用户而言，期望利用NetworkPolicy实现全局管理,则必须进行更为更杂的定制开发,其实现难度和管理成本令多数用户驾尘莫及，2）规模化管理难度大NetworkPolicy仅在商用版才提供心应求可视化能力，对,开源版用户而言，不得不在未了解流电关系的情况下“白配”安全策略，准确性和效率将大大降低，且随若管理规模的增大，定制贴合业务、符合最小特权厚则的安全策略则越来越不可

13、能，同时，在规模较大的容器环境中，东西向连接关系极其攵杂，大量实操经验证明管理者制定策珞规则时“首发命中”的可能性微乎其微,安全策略从设计到执行通常篇要仿其测试、细化调优等阶段,否则大概率发生的误阻断将直接造成服务间的调用失败。而在NctworkPolicy即时生效的机制下，管理者的配置难次和试错成本极府对策略卜发执行造成阴滞.3）管理操作眇用性差时于多数用户而言,NelWorkPOIiCy的管理交互并不友好，例如其仅设基-FNameSpaCe和Pod标签定义策珞，对丁容器平台管理不规枪的用户，策略的灵活性将受到极大限制.又如，策略定义需通过手工编辛tYAH1.文件实现,配置效率低误配置风险商

14、，这些问题均不利于在笈杂的容器环境下配跟生效微隔离策略，混合架构无法统管云原生环境中容涔是工作负我的主流类型，但.即使是在彻底完成云原生化改造后，容器也并不会完全替代虚撅机实例。换吉之，在多数用户的数据中心内，物理机实例、虚拟机实例、容器将长期并存，作为承载不同应用的工作负我，它们之间依然会产生密切的横向连接，福被统一纳入微隔离的管控范用，而NetworkPUIiCy品然仅适用于容器平行内部的隔离控制。综合以上，K8S内置的NetworkPolicy能在容器平台中提供基于策略的内部流量控制能力，但其更倾向于一个单纯的“策珞执行点”.事实上，在云原生环境下实施费隔离本身是非常复杂的，对于策略从设

15、计.到定义、再到运堆等全生命周期的管理,现阶段的NetworkPolicy并不能完全胜任，2、主机代理形态的工作负,IMiWNelworkPoIiCy原生于云却“举步维艰”，同样印证了云原生环境对于专业安全功能深度、广度和易用度的诉求.事实上，云工作负载的微隔离防护并非是在云原生时代才有的产物,该技术早在2015年便被Gartner提出，并在近几年间快速迸入主流技术航道，只是在做隔离诞生之初其面向的隔离对象以云平台内的虚拟机实例为主,容器还并未得到大范围运用。作为面向新型基础设施的创新技术，早期的微隔您存在多种技术路线，各有优劣及对应的适用场景，公厂商面向其用户推出了适用T自身平台的安全组件，可与云管理平台紧密结合，但对第三方云平行的适应性具有明显局限，防火墙厂商通过与虚拟化平台的适配，将东西向流域牵引至其防火培系统实现访问控制，可利用较成熟的安全能力时流hi进行检测和