目前，容器和镜像已经成为应用打包和交付的事实标准，同时，Kubernetes 也成为应用容器的标准 OS。作为云原生应用中最关键的技术之一，容器已经被大部分用户应用到生产环境中。但是，有研究报告显示，容器安全已经成为用户容器化应用的最大阻力。

容器安全的现状是什么？业界主要有哪些容器运行时安全技术或解决方案？企业对安全容器的诉求有哪些？… 针对容器安全的有关问题，InfoQ 记者采访了阿里巴巴技术专家高步双（花名：江博）。

容器安全的现状

高步双认为，与传统安全相比，云原生时代的安全挑战发生了很大变化，主要表现在三方面：

如今，一台服务器可能混合运行着成百上千个应用容器，其密度是传统模式的数十倍
容器和镜像加速了敏捷快速迭代的效率，应用变更更加频繁
在开放的云原生时代，有越来越多的开源技术和三方不可信应用被引入到企业内部

随着越来越多的应用容器化后，暴露的安全问题也更加严峻。以漏洞为例，自 2017 年以来，业界已经曝出 25+ 与 Kubernetes 相关的 CVE 漏洞。比如 CVE-2019-5736 runC 漏洞，它能让普通用户身份运行的恶意程序渗透到宿主机，修改 runC 程序，在下次创建容器时就会调用被修改的 runC，借此，攻击者可以实现任何非法目的。

“以往，一台机器只部署一个应用，容器化后，一台机器可能混合部署着各种各样的应用，这无疑提高了应用自身的安全风险。”他说。

此外，有越来越多的用户开始关注容器安全。根据 Tripwire 发布的“2019 年容器安全现状”报告表明，有高达 94% 的受访对象对容器安全比较关注，只有 6% 的受访者表示并不在乎。

在高步双看来，容器安全问题的影响可大可小。“逃逸的恶意容器应用会渗透到内网网络，嗅探网络、窃听，盗取重要数据，甚至对内网中的服务或其他业务应用发起攻击，给整个公司带来严重的负面影响，带来的损失有时甚至无法估量”。

容器安全分类

容器安全涉及范围较广，一般分成三大类：

运行时安全

安全容器运行时（简称安全容器，隔离不可信应用、阻断恶意非法访问）
网络隔离（Network Policy 等）
漏洞检测（主机 OS、Guest 等）
安全监控（进程异常行为、网络活动等检测）

软件供应链

数据保护（At-Rest、In-Use、In-Transit）
镜像安全（镜像签名、镜像扫描）
DevSecOps

基础设施安全

RAM 认证
细粒度 RAM 授权

这些容器安全问题中，最有挑战性的是容器安全运行时问题。从纵向看，安全容器技术涉及到硬件、OS、Kernel、Hypervisor、容器、K8s 等多层复杂技术；从横向看，涉及到网络、存储、监控、日志等适配。

以传统的 runC 容器为例，其最大的问题是隔离问题，包括系统隔离、数据隔离、网络隔离等安全隔离问题，还有性能和故障隔离，比如隔离不足、资源争抢导致延迟敏感型应用抖动、主机上的容器故障（CPU 泄露、频繁 CoreDump 等）都会影响主机上的其他容器。

此外，由于 runC 容器基于 Namespace 技术隔离，导致大部分非 Namespace 类别的内核参数的设置会影响主机上的所有其他容器。

业界主要的安全容器运行时技术对比

根据高步双介绍，业界安全容器运行时主要分为四大类：

OS 容器 + 安全机制

它的主要原理是在传统 OS 容器之上增加一些安全辅助手段来提高安全性，如 SELinux、AppArmor、Seccomp 等，还有 docker 19.03+ 可以让 Docker 运行在 Rootless 的模式之下。其实，这些都是通过辅助的工具手段来增强 OS 容器的安全性，但依然没有解决容器与 Host 共享内核利用内核漏洞逃逸带来的安全隐患问题；而且，这些安全访问控制工具对管理员的认知和技能要求比较高，安全性也相对最差。

用户态内核

此类典型代表是 Google 的 gVisor，通过实现独立的用户态内核去捕获和代理应用的所有系统调用，隔离非安全的系统调用，间接性达到安全目的，它是一种进程虚拟化增强。

但是，系统调用的代理和过滤的这种机制，导致它的应用兼容性以及系统调用方面性能相对传统 OS 容器较差。由于并不支持 virt-io 等虚拟框架，扩展性较差，不支持设备热插拔。

Library OS

基于 LibOS 技术的这种安全容器运行时，比较有代表性是 UniKernel、Nabla-Containers。LibOS 技术本质上是针对应用内核的一个深度裁剪和定制，需要把 LibOS 与应用编译打包在一起。因为需要打包拼在一起，因此本身兼容性比较差，应用和 LibOS 的捆绑编译和部署，这为传统的 DevOps 带来挑战。

MicroVM

目前，业界虚拟化 (机) 本身已经非常成熟，MicroVM 轻量虚拟化技术是对传统虚拟化的裁剪，比较有代表性的就是 Kata-Containers、Firecracker，扩展能力非常优秀。VM GuestOS 包括内核均可自由定制，由于具备完整的 OS 和内核，它的应用兼容性极其优秀；独立内核的好处是即便出现安全漏洞问题也会把安全影响范围限制到一个 VM 里面。当然，它也有自己的缺点，Overhead 可能会略大一点，启动速度相对较慢一点。

如何选择安全容器运行时？

对企业而言，它在选择安全容器运行时需要考虑三个方面：安全隔离、通用性以及资源效率。如下图所示：

具体而言，安全隔离注重不可信应用的安全隔离、故障隔离以及性能隔离；标准通用注重应用兼容性、K8sAPI、OCI 标准兼容以及原生性；资源效率注重应用性能、启动速度以及更低的 overhead 开销。

高步双向 InfoQ 记者指出：如何去平衡这三个方面，主要还是根据用户自己的业务场景和技术能力去选择，安全容器往往涉及从硬件、OS、Kernel、容器引擎、容器 Runtime、K8s 等多个层面的技术问题，同时还需要打通周边网络、存储、日志、监控等系统，门槛较高。

对大部分内部可信业务来说，这类应用安全风险较低，普通的 runC 容器足矣；
对来自三方、开源或存在潜在漏洞风险的应用，需要通过安全容器进行隔离；若追求高执行效率和更小的开销，可以考虑 LibOS 形态的安全容器，缺点是需要 LibOS 和应用捆绑编译；若追求通用性，可以考虑基于轻量虚拟机技术的安全容器，比如开源的 Kata Containers、firecracker，也可以考虑公有云安全容器产品，例如 ACK 安全沙箱容器等，虽然基于虚拟机技术，但依然能做到秒级创建和启动。

另外，开源的用户态内核实现，比如 gVisor，虽然开销较小、启动速度较快，但是兼容性稍差于 runC 以及轻量虚拟机安全容器。

安全容器在阿里 WebIDE 上的实践

高步双称，“除了边缘计算场景，安全沙箱容器也是很多云产品的底座，比如阿里的宜搭、WebIDE，外部的客户，比如银行、金融科技类公司等。”

这里以安全容器在 WebIDE 上的应用为例。WebIDE 是阿里云云端集成开发平台，用户仅需要打开浏览器，就能随时随地的编写代码、调试程序并提交部署，它还支持万人在线。并且，WebIDE 集成了 Theia 和开天（阿里自研）的前端，兼容 VSCode 插件。

据悉，整个 WebIDE 系统都是通过云原生技术、基于 ACK 神龙裸金属沙箱容器 K8s 集群打造的。同时，它也被 WrokBench、宜搭等云上产品和阿里集团内大量业务系统所集成。在支撑 WebIDE 的业务场景中，用户的每个开发空间都有独立的 Deployment、Service、Ingress、PV/PVC 等配置，并且万人在线的规模也带来了诸多挑战。

挑战 1：海量 Ingress 路由规则，社区 Nginx Ingress 长连接 reload 断连、LUA 反向代理转发间断性卡顿（70ms ->1.5s）。

这其中有两个问题：第一个问题，在 WebIDE 中，浏览器通过 WebSocket 与服务端交互，集群内大量的 service、ingress 对象，一旦任何对象发生变更，都会导致整个 Nginx Ingress Controller 重新 reload，引发长连接断连。

对这个问题，他们的解决办法是在社区 Nginx Ingress Controller 的基础上增加“dynamic-servers（动态 servers）功能。这里，解决的很重要的一点是配置（Http、Server、Upstream、Location 等）变更时，Nginx 不去 reload，这样就不会 fork 新的 worker 进程。将这些频繁变化的配置放到 Shared Memory（LUA）中，当 Nginx 接收请求时，就能基于最新的共享内存中的配置规则进行规则匹配和路由转发。

第二个问题，经排查和测试发现，当集群 Ingress 对象数量超过 600 个左右后，LUA 转发出现了明显的间断性卡住，响应时间从 70ms 左右剧增到 1.5s 左右。

如何解决这个问题？他们首先想到的方案是替换 Ingress Controller 方案，不仅测试了 Nginx 官方版本的 Nginx Ingress Controller，而且还测试了 gloo、contour 等基于 Envoy 实现的 Ingress Controller。

测试后发现，Nginx 官方版本的 Nginx Ingress Controller 并未提供动态 servers 等功能，reload 后在 worker_shutdown_timeout 会强制导致长连接断连。

gloo、contour 等基于 Envoy 实现的 Ingress Controller，在处理海量的 Ingress 对象（2k+) 性能上并未出现卡顿问题，单纯从反向代理转发性能来看，仍然可以看出 Envoy 的转发性能略差于 Nginx。

分片方案

考虑到集群业务规模的急速增长，每个 Ingress Controller 实例仍要处理所有集群 Ingress 对象路由，在规模大到一定量时，必然面临性能问题，所以团队想到了“分片”方案。详解方案前，我们先看看原生 Nginx Ingress 架构图：

分片方案 1：

通过 ingress-class 为 ingress 对象分片，每一个 class 都是一个独立的 ingress 集群，它的缺点是对用户有感，运维复杂，横向扩容 class 需要增加 ingress LoadBalancer 等，所以后来放弃这个方案。

分片方案 2：

团队决定基于一致性 Hash 开发了一个 Ingress Chunk Controller 的分片版本，方案如下：

方案核心原理解释：

Ingress Controller 划分成不同的分片，如上图 chunk-1、chunk-2…chunk-10 等，每个 chunk 内的 Ingress Controller（称为 Member）只负责一致性 Hash 算法过滤出的 Ingress 对象路由；
在“Ingress 路由层”之上新增“Chunk 路由层”，Chunk 路由层负责将 http 请求根据相同的 Hash 算法路由到缪戈 Chunk 上。

这打散了 Ingress 对象的分布，让每个 Nginx-Ingress-Controller（member）只负责少量的 Ingress 对象，而非纯粹去优化单体 Controller 的性能（如优化 LUA 脚本、Envoy 替代等），这样做的最大好处是 Ingress-Chunk 理论上可以无限横向扩容，而且 Nginx-Ingress-Controller 可与社区保持更新。

IngressChunkController上线后，断连问题得到有效的解决，虽然增加了一层 Chunk 路由层，但是响应时间仅仅增加了几十微秒。“我们不久也会把 IngressChunkController 在阿里云 ACK 的应用目录开放给所有用户”。

挑战 2：海量 K8s 对象给 Master、Addons 组件带来了巨大压力

据悉，海量 K8s 对象给 Master 和 Addons 组件带来了巨大压力，PV/PVC 创建变慢、Ingress 路由规则生效慢、网络策略插件 CPU 占用 800% 等一系列的问题。

对于上述问题，首先得益于 ACK 托管架构，可以轻松地为用户纵向扩容 Master 组件规格；其次，优化 Kube-controller-manager 的 List/Watch API 限速配置，解决了 PV/PVC、Ingress 路由规则生效慢等问题；然后，通过 calico-typha 中心化方案，将计算逻辑从 calico-felix 剥离到 typha 中，让节点 calico-felix CPU 占用从 800% 下降到 10%。

挑战 3：多租户网络、用户 VPC 打通，让用户在自己的业务空间使用自己 VPC 内的资源

上图是典型 Serverless 场景中解决多租户网络问题，资源（Pod、神龙）实际属主为产品方，运维、神龙等成本由产品方承担，大大降低用户的运维成本和资源成本。

用户期望在 Pod 内可以访问自己 VPC 内的资源，比如 RDS、应用服务等。但是 Pod 实际 VPC 和用户 VPC 是两个完全独立隔离的 VPC，那两者之间的网络应该如何打通？

产品方可以通过授权和角色扮演的方式，在用户 VPC 内购买一个 ENI 网卡，并将这个网卡绑定到产品 VPC 神龙的 Pod 内。

挑战 4：极速文件共享，对存储性能提出挑战

存储插件（如 CSI-Plugin）会把存储（如 NAS、云盘、OSS 等）先挂载到宿主机的一个目录，然后通过 mount bind 方式共享到容器内，这在 runC 容器上没有问题，但是在安全沙箱容器上会经过 9PFS，导致性能急剧下降数十倍甚至数百倍，所以采用了“存储直挂（直通）”方案。

阿里巴巴的最新探索

在数字经济时代，数据保护问题已经成为企业上云最大的挑战之一。

高步双认为，数据有三种形态：At-Rest（存储状态）、In-Tranist（传输状态）和 In-Use（使用中或计算中状态）。其中，前两种状态下的数据加密和数据保护的技术与产品已经相当成熟，加密数据在内存中，计算前通常会先解密，理论上，可以从内存获取解密后的明文数据或密钥。而如果想帮助用户保护 In-Use 状态下的数据，那么隐秘性和安全性则成为最大的难题。安全容器（如 ACK 安全沙箱等）可以帮助我们很好地隔离不可信应用，避免逃逸、渗透到后端造成无法估量的破坏，但是无法帮用户保护自己计算过程中（In-Use）的敏感数据或代码不被其他应用、管理员、运维人员、黑客甚至云厂商窃取。为此，他们和蚂蚁、操作系统、云安全以及神龙等多个团队合作，在阿里云容器服务 ACK-TEE 上推出了基于 Intel SGX 的“加密计算”集群。

Intel SGX 是 Intel 为软件开发者提供的安全技术，是把用户应用程序代码和数据运行在一个通过硬件孤岛和内存加密技术创建的特殊执行上下文环境 Enclave 中（此环境也可统称为可信执行环境 TEE – Trusted Execution Environment），任何其他应用、OS、Kernel、BIOS，甚至 CPU 之外的其他硬件均无法访问，并且 Enclave 内存中的数据全部是加密的。用户用自己的从 Intel 申请到的秘钥签名 & 加密 Enclave 里的代码和数据，Enclave 必须通过远程证明服务（Intel IAS）验证签名通过才可以正常启动。

此外，为降低可信应用的开发和交付门槛，高步双所在的团队还联合操作系统安全团队主导开源了业界第一款面向机密计算容器运行时项目 Inclavare Containers，它可以让用户很轻松地创建一个基于硬件孤岛和加密的可信执行环境，帮助用户在云上保护自己的敏感数据和应用；同时，它兼容 OCI 标准，传统应用容器无需或少量修改即可运行在可信执行环境（TEE）中，用户无需通过 SDK 重构应用，极大提高了可信应用的交付效率。

企业对安全容器的 3 大诉求

当前，云原生基础设施主流架构主要是 CaaS+Serverless，未来将向 Serverless+fPaaS（FaaS）演进，应用也会越来越轻量化，而轻量应用也会要求更高的灵活性，极致的弹性效率和更小的计算单位以及更低的成本。这些诉求必然对基础设施带来新的挑战。

在高步双看来，未来的安全容器运行时将发生以下变化：

边界突破

数字经济时代，越来越多的应用和数据需要安全容器保护，安全容器的用途将不再是单一的隔离不可信应用。

更轻更快

在保障安全性的前提下，未来的应用对安全容器的启动速度和 overhead 都提出了更高要求，启动速度从秒级降为毫秒级，内存开销从数百兆降低到数十兆，这将极大提高新时代应用交付效率，降低计算成本。

富运行时

在未来，单一的安全容器运行时无法满足需求。即使安全容器运行时不断在瘦身和优化，但对于轻应用而言，仍显得过重，这将催生应用运行时（Application Runtime）的产生，比如 WebAssembly 等。但是，应用运行时在资源隔离限制等方面存在一定的不足，通过 SecureContainerRuntime + ApplicationRuntime，既可以满足安全、资源隔离，又能满足轻应用的灵活调度和部署。

在可信应用和隐私数据保护方面，通过 SecureContainerRuntime +TEE Runtime，不仅可以保护应用，而且能避免应用受到外部的非法访问，实现双向隔离。

写在最后

虽然大部分终端用户还在使用 Docker runC 容器，但在各类 Serverless、FaaS 云产品云集的今天，安全容器已经成为这些云产品必备的安全隔离底座，有越来越多的用户开始选择安全容器替代 runC 运行时。“随着安全容器启动效率、overhead 的极致优化，甚至在某些场景优于 runC 容器，在兼容性、性能、启动效率、几乎可忽略的 overhead，安全容器会越来越普及”。

创作场景

安全容器在阿里巴巴的应用和实践