《容器云平台安全隔离方案详解.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自身平台的安全组件，
16、可与云管理平台紧密结合，但对第三方云平行的适应性具有明显局限，防火墙厂商通过与虚拟化平台的适配，将东西向流域牵引至其防火培系统实现访问控制，可利用较成熟的安全能力时流hi进行检测和控制，但性能上存在较大难点，且实际效果往往受制于虚拟化平台的就容适配水平.独立的微隔宙厂商则采用主机代理(Agent)的方式，通过控制工作负载操作系统的主机防火墙程序(Iptables实现面向工作负我的隔岗控制，能修充分适应混合云、多云及各类云平台,最大程度实现基础架构无关.HypervisorHostServer多数K8S网络插件是利用节.点（Wde）主机内核的固有能力实现容器平台内部的网洛转发，这给法于主机代理（
17、Agent）的澈隔离系统适应容器环境提供了天然的技术条件，可籽Agem部署于容器Node的操作系统,并通过捽制其内核的网络转发i而实现容器间通信的访问控制，因此，基于已较为完善的微隔离功能，井凭借时容器环境的天然兼容性，基于主机代理形态的微隔离系统在相当长一段时期内，几乎是面向容器平台及虚拟机、容器并存的混合环境下，唯一可行的微隔离方案.然而,此类方案在数据中心由“应用容器化”演进至“全面云原生化”后，依然显现出了诸多与云原生思想相悻的弊端而核心在于其必须通过在Node安装Agent的方式实现部署,在K8S集群中，Pod是最小的计数单元，而Node则是Pod的承载体，在Node按需部署的过程中
18、，Agent无法用其建立而自动化部署，反而必须执行额外的安装，协必拖慢了DeYoPS流程、拉低持续交付的效率此外,越是规模化部署的用户,管理规范越严格，获得NtXIe安装Agent的管理权限本身也存在较大不便.归根结底，基于主机代理的微限黑方案可以支持容器环境，但其也并非完全的“为云而生”，距离云原生环境微隔离的理想实现仍有差距，五、容器云平台的安全隔离解决方案综合来看，理想的容器云平台安全战忠解决方案应满足以卜几个条件：1、充分适应云聚生环境特性云原生的初麦是充分择放z、计兑敏捷、灵活的技术红利，安全措施的运用不应以牺牲云原生的固有特性为代价，应以原生的思维构建安全，使安全能力能够内嵌融合,
19、云平台中。具体而言，云原生安全方.案应采用内嵌的方式而非“穿衣贼的”式的外挂部署安全能力能够与云原生环境中的应用一样实现快速部署、按雨伸缩,应可以充分利用云平台原生的资源和数据，实现安全策略的自适应。因此隔离方案应具釜容器化部署运行、自适应策略il舞等特性，将安全能力以原生化方式向云平台融合嵌入，充分适应云原生环境敏捷、灵活冲性扩展、动态伸缩的特点。让安全与容器的生命周期保持第密的“步调一致”，自动加我精细化访问控制能力,不但消除了用户容器平令的防护区”，还对业务应用实现了安全防护左移”2、Iwer拿的策略彼计助/：欣生环境对传统IT架构和管理模式形成巨大颇覆，在更为紧凑的应用生命冏期内，从开
20、发、到测试、再到运维，安全控制的设计和实施往往并不在业务团队关注的范围。而对于安全人员来说,难以将安全措施融入应用交付流程的核心原因，是安全人员并不r解业务构成和运行，在未得到必要输入的情况下，他们同样无法回答策略该如何设计的问题。结合云原生环境实施做隔离的场景，在无法纵览全局连接状态、无法准确梳理业务互访的情况下，用户雄以像次施传统域间边界访问控制那样预设安全策略，而必须经历一定周期的学习、分析和建模，才能定义出符合业务实质、遵循最小特权的策略规则.在此过程中系统应通过可视化、智能化的功能,为安全策略的设计提供轴助和便利.被厂商“神化了多年的“可视化”技术.在过去很多年更像是个“花旗”。而如
21、今，可视化成了微隔离一项关键能力，要想“可控”首先必须“可视”,这也是“策略辅助设计”的具体体睨，因此容器云隔离方案应提供带业务视角的连接关系可视化分析功能，在微隔离策略实施的准备阶段，让用户以纵览全局、洞察岗豪的上帝视角深入分析云原生环境下的东西向流量，并提供资产税理、策珞设计等的辅助支撑，进一步降低微隔离的实施难度.3、具备完善的策略管理能力八生环境下更为有效的安全管控，实际上是要实现面向现模更庞大、复杂度更高的管控时象、执行颗粒度更细、精细化程度更高的安全策略,这无疑是对微隔离策略体系的巨大挑陵,事实上，住容平台强大的编排能力下，用于加载执行安全策略的作用点并不缺少，而更为重要的是需具备
22、完善、系统的策略定义框架和管理运维能力，确保策略设计能被准确定义管捽意图得以完整贯彻.云原生环境的微隔离场景I.安全策略首先应完成与IP和主机名的解糊，并支持以新的、更加丰富的方式来圈定策略对象。安全策珞应能适应面向东西向流域的场景，例如跨业务的或业务内的、出站的或入站的、应允许的或需阻断的等.安全策珞的执行必须考虑到徼阳值运用的实际，提供必要的效果仿其手段，来验证策略设计的正确性和合理性.安全策略的发布应能够被连慎审查，并提供快速的回滚选项等。提供灵活的策略定义编排和完得的运维管理功能，具体可体现为简化的策略逻辑、灵活的策略定义方式、丰富的策略生效模式及完善的策略审计和回滚等设计，满足云原生环境下纪朵的策略管控需求.专业而体系化的微隔岗策略管理和运维能力，可让用户获得更为使捷、易用的策略管理体验,从而加速零信任安全能力在数据中心的落地.4、防平台、集群歧一管理最好能实现物理机、虚拟机、容等多类工作负载的同台纳管，实现规模化云原生环境中湾KSS集群的统一管理，这样才能适险国内多数用户混合云、多云等复杂数据中心场景l向微隔离统一管理需求，使用户获得企业的全业务可视化分析俄力和全业务访问控制能力.
