目录

前言

一、云原生的技术背景

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

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

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

1、基于Network Policy的容器隔离

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

五、容器云平台的安全隔离解决方案

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

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

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

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

商用解决方案

---

前言

容器云平台的安全隔离方案旨在确保不同租户或工作负载之间的资源、网络和数据隔离，以防止未经授权的访问和潜在的数据泄露。以下是一些关键的安全隔离措施和方案：

网络策略（Network Policies）：在Kubernetes等容器编排系统中，可以定义网络策略来控制不同Pod间的网络通信。通过标签选择器来决定哪些Pod可以互相通信。

命名空间（Namespaces）：Kubernetes中的命名空间提供了逻辑上的隔离，不同的服务可以在各自的命名空间中运行，从而实现一定程度的网络和资源隔离。

服务网格（Service Mesh）：例如Istio等服务网格组件提供细粒度的流量管理和安全策略实施。

安全组与防火墙规则：类似于传统数据中心，在容器云平台内部也可以设置基于IP和端口的安全组规则以及更高级的防火墙策略。

加密通信：采用TLS和其他加密协议保障容器间及容器与外部服务的通信安全。

容器运行时安全：如使用Seccomp、AppArmor或者SELinux等Linux内核安全模块来限制容器内进程的能力和权限。

最小权限原则：为容器分配仅满足其运行所需的最小权限，避免过度授权带来的风险。

使用多租户存储解决方案，确保每个租户的数据独立且受保护，避免数据混杂或被其他租户访问。

实现细粒度的权限控制，根据角色控制对API资源、配置文件以及其他敏感信息的访问。

镜像扫描工具用于检测容器镜像中的漏洞，并确保只部署经过验证和安全的镜像。

1. 网络隔离：

2. 网络安全：

3. 容器级隔离：

4. 存储隔离：

5. 身份与访问管理（IAM）：

6. 镜像安全：

理想的容器云平台安全隔离解决方案需要综合运用上述技术手段，构建多层次、全方位的安全防护体系，同时也要结合持续监控和自动化响应机制，确保在发生安全事件时能够及时发现并处置。

常见得手段:

1. 网络隔离：通过虚拟化技术，将不同的容器实例部署在不同的虚拟网络上，实现网络层面的隔离。这样可以防止一个容器的故障影响到其他容器，同时也能防止外部攻击者通过网络直接访问到内部容器。

2. 命名空间隔离：每个容器都有自己的命名空间，包括进程ID、网络、用户和文件系统等。这样即使两个容器运行在同一个宿主机上，它们之间也是完全隔离的。

3. Cgroups资源限制：Cgroups是Linux内核的一个功能，用于限制、记录和隔离进程组的资源使用（包括CPU、内存、磁盘I/O等）。在容器云平台上，可以通过Cgroups来限制每个容器的资源使用，防止某个容器因为资源耗尽而影响其他容器。

4. SELinux安全策略：SELinux是一个强大的安全模块，可以对进程进行细粒度的权限控制。在容器云平台上，可以通过配置SELinux策略，限制容器只能访问必要的资源和服务。

5. AppArmor安全策略：AppArmor是另一个Linux的安全模块，与SELinux类似，也可以对进程进行权限控制。但是AppArmor的策略更加灵活，可以根据需要定制。

6. Docker安全策略：Docker提供了一些内置的安全策略，例如只允许特定的用户和组运行容器，禁止root用户直接运行容器等。这些策略可以在创建和运行容器时进行配置。

7. 镜像安全：容器云平台通常会提供镜像仓库服务，用户可以从仓库中拉取和推送镜像。为了保证镜像的安全，平台通常会对镜像进行签名和验证，防止用户下载到被篡改的镜像。

8. 监控和日志：通过实时监控和日志分析，可以及时发现和处理安全问题。例如，如果发现某个容器的CPU使用率异常高，可能是被攻击了；如果发现某个容器的日志中有大量的错误信息，可能是程序出现了问题。

一、云原生的技术背景

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

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

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

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

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

原生技术能够有效解决传统云实践中应用升级缓慢、架构臃肿、无法快速迭代等”痛点”问题，并为
业务创新提供动力。然而，云原生技术在创造效益的同时，也面临着切实存在日益严峻的安全风，
险。

例如，2018年特斯拉AWS上部署的K8 S Dashboard暴露在公网，没有做认证和授权控制，也没有
对网络访问做控制，黑客直接从dashboard中获取S3凭证，从而获取遥测数据，恶意拉取POD,
进行挖矿行为。

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

CNCF 组织指出，作为微服务部署的容器化应用程序的边界就是微服务本身。因此，有必要设定策略，只允许在得到许可的微服务间进行通信。

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

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

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

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

防火墙的部署位置和控制对象决定了其仅能针对跨域流量进行控制，而无法实现更细粒度的业务
级、工作负载级控制。此外，鉴于策略规模对防火墙性的影响，其安全策略的控制对象往往仅能
做到网段级。

因此比，确切来说，此类方案至多能够提供用于维护数据中心基础架构完整性的”宏分段
(Macro-Segmentation)”,而无法实现云原生环境中真正所需的"微隔离(Micro-
Segmentation)"。
 

 

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

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

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

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

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

1、基于Network Policy的容器隔离

防火墙因“水土不服“而在云原生环境下彻底失效，再次鲜活证明了“安全原生化”对于云原生环境的
重要性。事实上，已成为容器编排平台事实标准的Kubernetes(以下简称"K8S"),通过集成
Network Policy功B提供了容器间的网辂隔离能力。

在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)实现面向工作负载的隔离控
制，能够充分适应混合云、多云及各类云平台，最大程度实现基础架构无关。

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

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

在 K8S 集群中，Pod 是最小的计算单元，而Node 则是 Pod 的承载体，在 Node 按需部署的过程中，Agent 无法随其建立而自动化部署，反而必须执行额外的安装，势必拖慢了DevOps 流程、拉低持续交付的效率。此外，越是规模化部署的用户，管理规范越严格，获得Node 安装 Agent的管理权限本身也存在较大不便。
归根结底，基于主机代理的微隔离方案可以支持容器环境，但其也并非完全的“为云而生”，距离云原生环境微嗝离的理根实现仍有差距。 

五、容器云平台的安全隔离解决方案

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

商用解决方案

在容器云平台安全隔离解决方案方面，5个商用解决方案：

网络隔离：通过NetworkPolicy和项目（Project，相当于Kubernetes的Namespace）实现网络层隔离。OpenShift还支持服务网格Istio，可以精细控制微服务间的通信。

角色与权限管理：内置了Role-Based Access Control (RBAC)，允许管理员对用户、组及服务账户进行细粒度的权限分配。

容器运行时安全：集成SELinux强制访问控制机制，确保容器内进程只能访问其应有的资源。

镜像安全：通过内置的Image Security Policy（镜像安全策略）来扫描并验证镜像安全性，限制不合规镜像的部署。

红帽OpenShift基于Kubernetes，并强化了企业级的安全性和隔离性。

网络隔离：通过NSX-T Data Center集成实现网络层面的深度隔离，包括东西向和南北向流量控制。

身份与访问管理：结合vSphere的身份认证服务，提供统一的IAM框架以及严格的RBAC规则。

安全策略实施：利用内置的策略引擎实施容器安全最佳实践，如配置管理和运行时防护。

容器生命周期安全：从构建到运行全过程，通过合作伙伴生态提供的工具链保证容器应用的安全。

TKG提供了高度可定制的企业级Kubernetes发行版，针对多租户环境设计了增强的安全方案。

1. 红帽OpenShift Container Platform

2. VMware Tanzu Kubernetes Grid (TKG)

3. 金山云容器服务（KCE）:

   金山云容器服务（KCE）是金山云提供的容器云平台，它集成了Kubernetes，为用户提供了一个安全隔离的容器环境。KCE 提供了基于命名空间的隔离、网络策略、访问控制和资源限制等功能，保障不同应用和团队之间的安全隔离。此外，KCE 还提供了安全审计、容器镜像扫描以及日志监控等功能，帮助用户加强容器环境的安全性。

4. 腾讯云容器服务（TKE）:

     腾讯云容器服务（TKE）是腾讯云提供的容器云平台，也构建在Kubernetes基础上。TKE 提供了基于命名空间的隔离、网络策略、访问控制和资源配额等功能，确保不同容器和应用程序之间的安全隔离。此外，TKE 还提供了容器镜像安全扫描、容器漏洞扫描、安全审计和日志监控等功能，帮助用户监测和应对容器环境的安全威胁。5. 阿里云ACK（Alibaba Cloud Container Service for Kubernetes）

VPC网络隔离：每个Kubernetes集群都可以创建在独立的VPC中，实现不同集群间的网络隔离。

多租户管理与隔离：通过ACK的多租户管理功能，为不同的团队或项目提供逻辑隔离的命名空间，并支持自定义的网络策略。

安全组和防火墙：集成阿里云网络安全组件，设置进出容器集群的网络访问控制规则。

容器安全服务：例如，ACK搭配使用阿里云的容器镜像仓库（ACR）能够进行镜像漏洞扫描，同时结合云安全中心等服务实现容器运行时安全监控和防护。

阿里云ACK作为托管型Kubernetes服务，提供了丰富的安全隔离功能。

这些商用解决方案提供了一系列的安全隔离功能，帮助用户在容器云平台中建立安全的容器化环境。它们提供了基于命名空间的隔离、网络策略、访问控制、资源限制等功能，同时还提供了容器镜像安全扫描、漏洞扫描和安全审计等增强安全性的功能。