“安全问题的唯一正解在于允许那些（导致安全问题的）Bug 发生，但通过额外的隔离层来阻拦住它们。” —— “Linux 之父” Linus Torvalds
来源 | 火山引擎云原生团队
云原生的双刃剑
以容器为代表的云原生技术正在飞速发展和广泛应用，在云平台创造了与传统 IDC 截然不同的使用体验：即用即得的资源容量、无需手动运维的基础设施、跨平台无缝迁移的应用……不过这些特性在为企业带来巨大便利和极高效率的同时，也始终伴随着一些安全性上的质疑：
- 弹性是否意味着共享：弹性容器基于有限的硬件规模为客户提供极致的资源弹性，必然需要让物理资源在不同用户之间快速流转。高度弹性的容器实例，是否意味着底层计算、网络、存储等硬件设施的共享，这种共享是否会让用户之间存在相互攻击的安全隐患？
- 免运维是否意味着黑盒：轻量化的容器技术为用户屏蔽了宿主机物理资源与 OS 的差异性，并提供底层故障自动化运维的能力，用户无需再像传统服务器或虚拟机一样直接访问底层系统并管理所有硬件。这是否意味着容器底层环境变成了完全的黑盒，用户就此失去对云厂商一切操作的审计和控制能力？
Serverless VS "Security-Full"，这对看似不可调和的矛盾，本质上是源于新技术发展与传统安全理念之间的磨合：在传统的 IT 理念中，追求轻量化必然通过牺牲隔离性来实现，容器技术似乎就是其典型代表。
事实上，在云原生社区的持续努力下，容器的高效和轻便已不再以牺牲安全作为代价，强隔离、高安全的容器也已经成为当前的主流。本文将概述云原生社区在容器安全领域的发展演变，并结合火山引擎云原生团队的技术实践，介绍在更高的弹性和可扩展性需求下，如何更好地保障云上的效率与安全。
从容器安全到安全容器
根据火山引擎与 Forrester 联合发布的《中国云原生安全市场现状与趋势白皮书》：半数以上受访者的企业在过去一年中至少经历过一次云原生相关安全事件。58% 的受访者表明他们的企业在过去 12 个月中经历了针对容器运行时（Container Runtime）的安全事件。
来源：《中国云原生安全市场现状与趋势白皮书》
容器运行时是指管理容器的一类软件组件。它负责编排容器、管理其生命周期，并使应用程序可以在隔离的环境中独立运行，常见的有 runC、runV、runsc 等。
在容器技术诞生之初，Docker 中的 libcontainer 模块利用 Linux 内核的命名空间和控制组特性，将容器与主机隔离开来，提供容器的创建、启动、停止等生命周期管理功能。此后 Docker 公司将 libcontainer 捐献给 CNCF，并基于 OCI 标准（Open Container Initiative）将其重构为 runC，为容器运行时提供了标准化的接口。
runC 提供创建、启动、停止、暂停、恢复和删除容器等丰富的功能，并直接利用 Linux 内核的隔离机制，无需为每个容器提供独立的硬件虚拟化即可使应用在独立的环境中运行，具有较低的资源消耗和较快的启动速度，因此被包括 Kubernetes 在内的容器编排平台广泛采用。
然而这种设计本质上还是共用同一个内核，存在潜在的安全漏洞：单个容器有意或无意影响到内核都会影响到整台宿主机上的容器，攻击者通过逃逸容器可以未经授权即访问宿主机操作系统，继而危及整个系统的安全。根据 OpenCVE 网站的相关统计，截至 2024 年 2 月，被公网披露出和 runC 密切相关的漏洞已有 11 个，包括权限升级、容器逃逸等。
出于对传统容器安全性的担忧，同时也为了实现更好的虚拟化级别的隔离性，2015 年，Hyper.sh 开源了基于 OCI 的轻量级容器运行时 runV，它基于虚拟机管理程序的运行时，通过虚拟化 guest kernel 将容器和主机隔离。同年，Intel 启动了以虚拟机为基础的容器技术 Clear Container，它依赖 Intel VT 的硬件虚拟化技术以及高度定制的 QEMU-KVM（qemu-lite）来提供高性能的基于虚拟机的容器。
2017 年，runV 和 Clear Containers 合并成为 Kata Containers，后者基于硬件虚拟化，通过虚拟化技术优化、精简内核和 guest rootfs 等方式，既保证了安全性、隔离性，又减少虚拟化引入带来的资源开销，使得 Kata Containers 对比传统虚拟机，继承了容器轻量、快速等优点。
来源：https://katacontainers.io/learn/
伴随容器技术朝着更加安全可靠的方向发展，Kata Containers 也解决了许多普通容器场景无法解决的问题，如多租户安全保障和不同 SLO 容器混合部署等。同时通过 containerd-shim-v2 和 vsock 技术，精简了大量的组件，配合轻量级 hypervisor 和精简内核，Kata 可以大幅降低内存开销和容器启动时间。
除了 runV 的典型代表 Kata Containers，此后业界也相继出现了 Firecracker、gVisor（runsc 典型代表）等安全容器实现方式，它们的原理不尽相同，但都反映了一个趋势，即将虚拟化的隔离性、安全性与容器技术在应用生命周期管理方面的优势结合起来，是实现效率与安全双赢的必由之路。
VCI 容器安全体系
火山引擎弹性容器实例 VCI 以安全容器技术作为运行时核心技术架构，在虚拟化隔离与容器结合的基础上，进一步围绕计算、存储、网络构建了完整的安全体系，并在技术架构上持续优化，帮助客户防范任何潜在的安全威胁。
计算安全
弹性容器实例 VCI 基于自研 hypervisor 和安全容器技术构建容器运行时，这意味着用户的每一个 Pod，都部署在一个完全独占的轻量化虚拟机（VM）当中。每一个 VM 的生命周期与对应 Pod 的生命周期保持一致，在 Pod 创建时 VM 被同步创建并初始化，当 Pod 释放时 VM 也将被删除并抹除全部数据。
以独占的 VM 作为宿主机，为 Pod 提供了更高的安全级别，确保任何 Pod 无法直接对其他相同或者不同租户的 Pod 所在的宿主机发起攻击，具体的隔离手段包括：
- 硬件虚拟化：允许 Pod 在硬件级别上实现隔离，各个 Pod 使用的虚拟硬件设备可以完全独立；
- 内核级隔离：虚拟机独占内核，这意味着每个 Pod 都有独立的操作系统实例，将权限升级和容器逃逸等风险限制在 VM 内部；
- 资源限制和隔离：可以为每个 Pod 分配独立的 CPU、内存和网络资源，确保它们之间互不干扰。在计算资源分配策略上，VCI 为每个 Pod 的 VM 分配独立的 CPU 资源，与物理主机上的 CPU 核心 1:1 绑定，确保 Pod 使用的物理核心独占。
存储安全
在 VCI 容器运行过程中，必然会存在一部分数据需要从持久化存储介质中读取或者写入，VCI 同样会以 Pod 为单位将这些数据隔离与保护起来，防范数据泄露和篡改等安全风险。
在系统盘层面，每一个 VCI Pod 都以一块完全独占的火山引擎弹性块存储（EBS）作为系统盘，并由虚拟机监视器（Virtual Machine Monitor，VMM）直连远程的 EBS 存储，保障系统盘中的任何数据（包括系统文件、容器镜像、Configmap、Secret 等）都不会在 VCI 所在的物理服务器本地落盘存储。这块 EBS 云盘由 Pod 独占，其他任何租户都无权对其进行访问和修改。在 VM 跟随着 Pod 被共同释放时，对应的 EBS 系统盘立即被删除，所有的数据都将清空销毁。
此外，原生的 Kata Containers 提供方案是将容器镜像拉取到物理主机中，在物理主机与 VM 间共享，这种方式无法充分保障镜像不会被物理主机中的其他应用获取。在 VCI 自研的安全容器方案中，将 Pod 拉取镜像的过程迁移到 VM 中，镜像仓库的访问凭据和拉取到的容器镜像文件都将在 VM 内部保存，并随着 VM 的销毁而同时被清除。因此物理机上的其他 Pod 以及运行在物理机上的平台组件都不能通过任何手段访问客户的镜像，确保了客户镜像不会被窃取或者篡改。
在极少数场景下，云存储的带宽等指标可能无法完全满足客户业务对大文件访问的性能需求。VCI 同样支持客户选择使用物理主机的本地盘作为系统盘创建 Pod，此时 VCI 将通过硬件虚拟化技术对 Pod 所在的物理机本地磁盘进行切分和隔离，保障不同 Pod 之间无权访问对方本地盘的任何数据。当 Pod 被释放时，被切分的本地磁盘将执行多次随机数覆盖的数据擦除操作，在确保数据完全无法恢复后才会释放并归还到本地存储池当中。
在数据盘层面，VCI 支持通过 CSI 插件的方式为 Pod 挂载块存储、对象存储等各种远程的存储介质，Pod 所在的 VM 将通过用户的 VPC 网络连接远程存储，通过 VPC 提供的隔离性保障访问安全。这些远程介质可以用于存储临时或者持久化的数据，如果使用了火山引擎的存储服务（如 EBS、NAS、vePFS 等），CSI 插件同样会保障这些存储服务的租户安全，确保只有相同云账户下具备充分权限的用户才能管理和使用对应的存储服务，并且通过这些云存储服务的租户隔离机制保障用户数据的安全性和可靠性。
网络安全
运行在物理主机中的 VCI Pod，需要通过物理主机的网卡访问外部网络，包括拉取镜像、访问客户 VPC 内的资源、访问公网资源等。通过对同一物理主机上不同 Pod 的网络进行隔离，VCI 可以保护用户间的网络通信不存在安全、合规风险。
如前文所述，同一个物理机上每个 VCI Pod 都独占一台轻量级 VM，VM 通过独享的弹性网卡（ENI）直连到用户的 VPC 网络中，并获得 VPC 中的网络地址。因此每个 VCI Pod 的网络通信都直接被租户级别的 VPC 网络保护起来，任意 Pod 都与其他租户的 Pod 天然隔离，并且和同 VPC 内的其他网元天然互通。
由于 Pod 网络直接接入租户的 VPC 中，因此同样受到用户的安全组策略保护，可以对 Pod 的出入流量进行精确控制。Pod 可以通过 VPC 的 NAT 网关单向访问公网，在需要被公网访问时，也可以与任何一台云服务一样通过挂载 EIP 或者负载均衡器接收公网流量。
📌 ENI：弹性网卡，是一种可以绑定到专有网络 VPC 类型虚拟机实例上的虚拟网卡。通过弹性网卡，可以实现高可用集群搭建、低成本故障转移和精细化的网络管理。
租户与平台隔离
📌 VCI 通过安全容器技术实现了租户与租户之间的虚拟机级别强隔离。在物理机层面，VCI 又通过字节跳动自研的 DPU 硬件架构，进一步做到租户与平台之间的强隔离。
DPU 是在云计算领域最新发展起来的专用处理器的一个大类，是继 CPU、GPU 之后，数据中心场景中的第三颗重要的算力芯片，为高带宽、低延迟、数据密集的计算场景提供计算引擎。
虚拟化、网络、存储以及安全是 DPU 的主要功能，通过利用 FPGA 具有在硬件级别上重新配置的能力，DPU 可以适用于多种计算任务，从而卸载原本运行在 CPU、GPU 中的通用数据处理任务，释放 CPU、GPU 的算力，支撑它们发挥更大的效能。
火山引擎全栈自研的 DPU 作为一种 SOC（System On Chip），具备以下 3 个特性：
- 行业标准的、高性能及软件可编程的多核 CPU，通常基于已应用广泛的 Arm 架构，与其他 SOC 组件密切配合；
- 高性能网络接口，能以线速或网络中的可用速度解析、处理数据，并高效地将数据传输到 GPU 和 CPU；
- 各种灵活和可编程的加速引擎，可以卸载 AI、机器学习、安全、电信和存储等应用，并提升性能。
VCI 作为一个多租户的容器实例服务，需要在物理主机上运行一部分维持平台运转的系统组件（虚拟化、网络、存储等），这些系统组件均采用了火山引擎自研的 DPU 虚拟化方案，全部从传统的 CPU 中卸载到 DPU 运行（通过 FPGA 实现硬转发），从而实现了物理主机上的 CPU 与内存全量售卖。这不仅提高了物理机资源的利用率，更重要的是在租户 Pod 与平台组件之间实现了物理级别的强隔离。
具体来讲，用户 Pod 所使用的 CPU 和内存资源，与 VCI 平台组件所使用的 DPU 资源处于不同的物理设备，在不同物理硬件间实现安全隔离，即便是某个 Pod 发生 VM 逃逸攻击到物理机 OS，也无权访问到运行在 DPU 中的虚拟化、网络、存储等平台组件，攻击范围无法进一步扩散。同样，如果 VCI 的平台组件出现安全漏洞风险，其攻击范围也局限在 DPU 设备中，无法获取内存中的用户应用数据。
结语
对于火山引擎云原生团队，保障每一位客户的业务和数据安全是重要且长期的责任。
除了本文所述的一系列技术方案，团队也在通过更加安全合规的管理机制和策略来进一步加固 VCI 的安全堡垒。比如面对社区中随时可能出现的 CVE 安全漏洞，团队会持续监测容器组件可能出现的安全风险，并在漏洞曝出的第一时间对弹性容器 VCI 所使用的各个组件进行升级修复。这样用户只需在 VCI 完成安全升级之后，通过重启 Pod 即可修复对应的漏洞，从而获得相比传统方案更加友好的安全升级体验。
云原生技术生态仍在不断地演进和发展，由此所带来的云原生安全防护也处于不断完善和迭代过程中。未来，火山引擎云原生团队将进一步打磨产品，并将在服务不同行业过程中积累的经验融入解决方案和客户服务，为客户云战略的实施保驾护航。 如需开通服务/咨询更多问题，请扫描下方二维码联系我们！
- END -
相关链接
[1] 火山引擎: www.volcengine.com
[2] VCI：www.volcengine.com/docs/6460/76908
[3] VKE：www.volcengine.com/product/vke
[4] 弹性容器实例：从节点中心转型 Serverless 化架构的利器
[6] 弹性容器实例：基于 Argo Workflows 和 Serverless Kubernetes 搭建精细化用云工作流
[7] 弹性容器实例：如何基于 Serverless Kubernetes 构建业务高连续性
火山引擎云原生团队
火山引擎云原生团队主要负责火山引擎公有云及私有化场景中 PaaS 类产品体系的构建，结合字节跳动多年的云原生技术栈经验和最佳实践沉淀，帮助企业加速数字化转型和创新。产品包括容器服务、镜像仓库、分布式云原生平台、函数服务、服务网格、持续交付、可观测服务等。