·2022-07-31 12:52

信息安全·某银行

容器云平台的安全隔离

字数 6740阅读 4776评论 2赞 13

# 一、云原生的技术背景

当前，数字化变革已逐渐渗透到每一个具体产业，弹性算力已成为各行各业的“水电煤”，云计算则成为数字化世界的基石，从底层驱动产业变革。随着云计算发展进入成熟阶段，以“生在云上、长在云上”为核心理念的云原生技术被视为云计算未来十年的重要发展方向。在数字化大潮中，上云并非是一种时尚，而是一种刚需，从“上云”到“全面上云”，从“云化”到“云原生化”，是企业数字化转型的必由之路。

相较传统IT 架构，云原生具有无法比拟的优势，将为企业带来降低成本、提升效率、快速试错、促进创新等业务增益价值。

云原生的技术理念始于Netflix 等厂商从 2009 年起在公有云上的开发和部署实践。2015年云原生计算基金会（CNCF）成立，标志着云原生从技术理念转化为开源实现。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。
![](/home/attachment/202207/31/908841_165924283243757.png)

云原生的运用使本身复杂多变的企业业务可敏捷灵活、及时响应、快速迭代，从而让数字化转型和运营过程中的持续创新成为可能。目前业界较为认可的构成云原生的四大核心技术要素是微服务、DevOps、持续交付和容器化。

#  二、云原生环境的网络隔离诉求

原生技术能够有效解决传统云实践中应用升级缓慢、架构臃肿、无法快速迭代等“痛点”问题，并为业务创新提供动力。然而，云原生技术在创造效益的同时，也面临着切实存在日益严峻的安全风险。
![](/home/attachment/202207/31/908841_165924254980664.png)
例如，2018年特斯拉AWS上部署的K8S Dashboard暴露在公网，没有做认证和授权控制，也没有对网络访问做控制，黑客直接从dashboard中获取S3凭证，从而获取遥测数据，恶意拉取POD，进行挖矿行为。

而 “隔离”技术是最早、最基础、也始终是最为核心的安全技术手段之一。Gartner 提出的容器安全控制分层理论，将容器安全能力按照优先级由高至低分为基础控制（Foundational Controls）、基本控制（Basic Controls）和基于风险的控制（Risk-Based Controls），其中网络隔离（L3 Network Segmentation）被划分为必备的基础控制能力。
![](/home/attachment/202207/31/908841_165924335397322.png)

CNCF 于 2021 年发布的《云原生安全白皮书》指出，作为微服务部署的容器化应用程序的边界就是微服务本身。因此，有必要设定策略，只允许在得到许可的微服务间进行通信。

在微服务架构中引入零信任，可以在一个微服务被攻陷时阻止其横向移动，从而缩小影响范围。运维人员应确保他们正在使用网络策略等功能，确保一个容器部署内的东西向网络通信只限于授权网络。

#  三、传统防火墙在云原生中的捉襟见肘

基于所承载业务的属性和安全级别，传统数据中心往往将其内部划分为多个安全域并进行定制化的安全管理，在安全域间通常会部署防火墙系统实现访问控制。在云平台建设初期，此类架构被相当一部分用户继续采用，并利用防火墙实施域间的访问控制策略，一些管理水平较高的用户则基于访问源和目的IP 进行了细粒度的策略规则设定。

然而，随着云平台向云原生架构演进迁移，基于防火墙进行域间控制已显得与云原生环境格格不入，无法真正满足容器平台的隔离需求。

防火墙的部署位置和控制对象决定了其仅能针对跨域流量进行控制，而无法实现更细粒度的业务级、工作负载级控制。此外，鉴于策略规模对防火墙性能的影响，其安全策略的控制对象往往仅能做到网段级。因此，确切来说，此类方案至多能够提供用于维护数据中心基础架构完整性的“宏分段（Macro-Segmentation）”，而无法实现云原生环境中真正所需的“微隔离（Micro-Segmentation）”。
![](/home/attachment/202207/31/908841_165924293621337.png)

此外，稳定不变的IP 地址是防火墙访问控制持续生效的“锚点”，而在云原生环境中，容器 IP 的频繁无规律变化则彻底动摇了传统架构中这一确定因素，一旦容器开始新的生命周期，新的 IP 将直接逃逸原有静态策略的有效管控。与此同时，由于容器的消亡与新建在云原生环境中是高频发生的，即便能够实时感知其变化，依靠人工删除原有策略并建立新的策略也毫无可能，而已失效的策略长时间堆积，又势必带来防火墙系统策略冗余、性能下降的副作用。

云原生环境中，微服务的架构势必指数级的增加服务间的互访调用情况和横向连接关系，给原本就复杂度较高的东西向流量控制又带来了新的难度。在DevOps 的加持下，应用敏捷、快速、持续交付部署，而安全控制措施则必须找到合适的切入点，并跟上瞬息万变的节奏。

容器成为新的最小控制单元，其生命周期规律则更加难寻，每次新业务上线、应用更新、扩缩容等，均会带来容器的消亡和新建，而在此过程中传统用于标识基础设施的IP、主机名等均将发生变化，传统的安全策略框架则将被轻易绕过逃逸。

由此看来，即便放弃用防火墙实现集群内流量微隔离的预期，其在云原生环境中也难以起到集群间流量的有效隔离控制作用，在云原生架构下甚至已经失去了原先的部署位置。事实上，开始规模化部署容器的用户，往往在第一时间即发现了防火墙系统几乎彻底失效的问题，从而释放出更为迫切的隔离控制需求。

#  四 、现有容器云平台隔离方案分析

## 1、基于 Network Policy 的容器隔离

防火墙因“水土不服”而在云原生环境下彻底失效，再次鲜活证明了“安全原生化”对于云原生环境的重要性。事实上，已成为容器编排平台事实标准的 Kubernetes（以下简称“K8S”），通过集成 Network Policy 功能提供了容器间的网络隔离能力。
![](/home/attachment/202207/31/908841_165924297381700.png)

在K8S 中，Network Policy 定义了一组 Pod 之间的访问控制规范，其通过 Label 指定Namespace 和 Pod，并利用节点（Node）主机操作系统的 IPTABLES 实现 Namespace 和Pod 级的网络访问控制。

与外挂式的防火墙相比，Network Policy 实现了原生化的安全能力内嵌，但大量实践表明，对于多数用户而言其运用落地依然受到较大制约，存在以下突出问题：

1) 环境适应性的局限

Network Policy 只定义了策略规则的规范，而访问控制能力的具体实现则需依赖 K8S 平台的网络插件。事实上，当前流行的 K8S 网络插件中，并非所有均支持 Network Policy 功能。例如相当一部分用户使用的 Flannel 插件即无法支持该项功能，而对于多数用户而言，为了实现 Network Policy 能力而替换迁移原网络插件的成本无疑是高昂的。

此外，一套Network Policy 策略仅能适用于一个独立的 K8S 集群，对于普遍具有多套K8S 集群的用户而言，期望利用 Network Policy 实现全局管理，则必须进行更为复杂的定制开发，其实现难度和管理成本令多数用户望尘莫及。

2) 规模化管理难度大

Network Policy 仅在商用版才提供了流量可视化能力，对于开源版用户而言，不得不在未了解流量关系的情况下“盲配”安全策略，准确性和效率将大大降低，且随着管理规模的增大，定制贴合业务、符合最小特权原则的安全策略则越来越不可能。

同时，在规模较大的容器环境中，东西向连接关系极其复杂，大量实操经验证明，管理者制定策略规则时“首发命中”的可能性微乎其微，安全策略从设计到执行通常需要仿真测试、细化调优等阶段，否则大概率发生的误阻断将直接造成服务间的调用失败。而在 Network Policy 即时生效的机制下，管理者的配置难度和试错成本极高，对策略下发执行造成阻滞。

3) 管理操作易用性差

对于多数用户而言，Network Policy 的管理交互并不友好，例如其仅能基于 Namespace和 Pod 标签定义策略，对于容器平台管理不规范的用户，策略的灵活性将受到极大限制。又如，策略定义需通过手工编辑 YAML 文件实现，配置效率低、误配置风险高。这些问题均不利于在复杂的容器环境下配置生效微隔离策略。

混合架构无法统管云原生环境中容器是工作负载的主流类型，但即便是在彻底完成云原生化改造后，容器也并不会完全替代虚拟机实例。换言之，在多数用户的数据中心内，物理机实例、虚拟机实例、容器将长期并存，作为承载不同应用的工作负载，它们之间依然会产生密切的横向连接，需被统一纳入微隔离的管控范围，而Network Policy 显然仅适用于容器平台内部的隔离控制。

综合以上，K8S 内置的 Network Policy 能在容器平台中提供基于策略的内部流量控制能力，但其更倾向于一个单纯的“策略执行点”。事实上，在云原生环境下实施微隔离本身是非常复杂的，对于策略从设计、到定义、再到运维等全生命周期的管理，现阶段的 Network Policy 并不能完全胜任。

## 2、主机代理形态的工作负载微隔离

Network Policy 原生于云却“举步维艰”，同样印证了云原生环境对于专业安全功能深度、广度和易用度的诉求。事实上，云工作负载的微隔离防护并非是在云原生时代才有的产物，该技术早在 2015 年便被 Gartner 提出，并在近几年间快速进入主流技术航道，只是在微隔离诞生之初，其面向的隔离对象以云平台内的虚拟机实例为主，容器还并未得到大范围运用。

作为面向新型基础设施的创新技术，早期的微隔离存在多种技术路线，各有优劣及对应的适用场景。云厂商面向其用户推出了适用于自身平台的安全组件，可与云管理平台紧密结合，但对第三方云平台的适应性具有明显局限。防火墙厂商通过与虚拟化平台的适配，将东西向流量牵引至其防火墙系统实现访问控制，可利用较成熟的安全能力对流量进行检测和控制，但性能上存在较大难点，且实际效果往往受制于虚拟化平台的兼容适配水平。独立的微隔离厂商则采用主机代理（Agent）的方式，通过控制工作负载操作系统的主机防火墙程序（IPTABLES）实现面向工作负载的隔离控制，能够充分适应混合云、多云及各类云平台，最大程度实现基础架构无关。
![](/home/attachment/202207/31/908841_165924301552996.png)

多数K8S 网络插件是利用节点（Node）主机内核的固有能力实现容器平台内部的网络转发，这给基于主机代理（Agent）的微隔离系统适应容器环境提供了天然的技术条件，可将 Agent 部署于容器 Node 的操作系统，并通过控制其内核的网络转发进而实现容器间通信的访问控制。因此，基于已较为完善的微隔离功能，并凭借对容器环境的天然兼容性，基于主机代理形态的微隔离系统在相当长一段时期内，几乎是面向容器平台及虚拟机、容器并存的混合环境下，唯一可行的微隔离方案。

然而，此类方案在数据中心由“应用容器化”演进至“全面云原生化”后，依然显现出了诸多与云原生思想相悖的弊端，而核心在于其必须通过在 Node 安装 Agent 的方式实现部署。

在K8S 集群中，Pod 是最小的计算单元，而 Node 则是 Pod 的承载体，在 Node 按需部署的过程中，Agent 无法随其建立而自动化部署，反而必须执行额外的安装，势必拖慢了DevOps 流程、拉低持续交付的效率。此外，越是规模化部署的用户，管理规范越严格，获得Node 安装 Agent 的管理权限本身也存在较大不便。

归根结底，基于主机代理的微隔离方案可以支持容器环境，但其也并非完全的“为云而生”，距离云原生环境微隔离的理想实现仍有差距。

#  五 、理想中的容器云平台安全隔离方案

综合来看，理想的容器云平台安全隔离解决方案应满足以下几个条件：

##  1、 充分适应云原生环境特性

云原生的初衷是充分释放云计算敏捷、灵活的技术红利，安全措施的运用不应以牺牲云原生的固有特性为代价，应以原生的思维构建安全，使安全能力能够内嵌融合于云平台中。

具体而言，云原生安全方案应采用内嵌的方式而非“穿衣戴帽”式的外挂部署，安全能力能够与云原生环境中的应用一样实现快速部署、按需伸缩。应可以充分利用云平台原生的资源和数据，实现安全策略的自适应。

因此隔离方案 应具备容器化部署运行、自适应策略计算等特性，将安全能力以原生化方式向云平台融合嵌入，充分适应云原生环境敏捷、灵活、弹性扩展、动态伸缩的特点。让安全与容器的生命周期保持紧密的“步调一致”，自动加载精细化访问控制能力，不但消除了用户容器平台的防护“盲区”，还对业务应用实现了安全防护左移。

##  2、 提供可靠的策略设计辅助

云原生环境对传统IT 架构和管理模式形成巨大颠覆，在更为紧凑的应用生命周期内，从开发、到测试、再到运维，安全控制的设计和实施往往并不在业务团队关注的范围。而对于安全人员来说，难以将安全措施融入应用交付流程的核心原因，是安全人员并不了解业务构成和运行，在未得到必要输入的情况下，他们同样无法回答策略该如何设计的问题。

结合云原生环境实施微隔离的场景，在无法纵览全局连接状态、无法准确梳理业务互访的情况下，用户难以像实施传统域间边界访问控制那样预设安全策略，而必须经历一定周期的学习、分析和建模，才能定义出符合业务实质、遵循最小特权的策略规则。在此过程中，系统应通过可视化、智能化的功能，为安全策略的设计提供辅助和便利。

被厂商“神化”了多年的“可视化”技术，在过去很多年更像是个“花瓶”。而如今，可视化成了微隔离一项关键能力，要想“可控”首先必须“可视”，这也是“策略辅助设计”的具体体现。

因此容器云隔离方案 应提供带业务视角的连接关系可视化分析功能，在微隔离策略实施的准备阶段，让用户以纵览全局、洞察微豪的上帝视角深入分析云原生环境下的东西向流量，并提供资产梳理、策略设计等的辅助支撑，进一步降低微隔离的实施难度。

##  3、 具备完善的策略管理能力

云原生环境下更为有效的安全管控，实际上是要实现面向规模更庞大、复杂度更高的管控对象，执行颗粒度更细、精细化程度更高的安全策略，这无疑是对微隔离策略体系的巨大挑战。事实上，在容器平台强大的编排能力下，用于加载执行安全策略的作用点并不缺少，而更为重要的是需具备完善、系统的策略定义框架和管理运维能力，确保策略设计能被准确定义，管控意图得以完整贯彻。

云原生环境的微隔离场景下，安全策略首先应完成与IP 和主机名的解耦，并支持以新的、更加丰富的方式来圈定策略对象。安全策略应能适应面向东西向流量的场景，例如跨业务的或业务内的、出站的或入站的、应允许的或需阻断的等。安全策略的执行必须考虑到微隔离运用的实际，提供必要的效果仿真手段，来验证策略设计的正确性和合理性。安全策略的发布应能够被谨慎审查，并提供快速的回滚选项等。

提供灵活的策略定义编排和完备的运维管理功能，具体可体现为简化的策略逻辑、灵活的策略定义方式、丰富的策略生效模式及完善的策略审计和回滚等设计，满足云原生环境下复杂的策略管控需求。专业而体系化的微隔离策略管理和运维能力，可让用户获得更为便捷、易用的策略管理体验，从而加速零信任安全能力在数据中心的落地。

##  4、 跨平台、跨集群统一管理

最好能实现物理机、虚拟机、容器等多类工作负载的同台纳管，实现规模化云原生环境中跨K8S 集群的统一管理，这样才能适应国内多数用户混合云、多云等复杂数据中心场景下的微隔离统一管理需求，使用户获得企业的全业务可视化分析能力和全业务访问控制能力。

容器云安全实现方式容器云安全设计容器云安全容器云

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！