|当Kubernetes遇到机密计算，如何保护容器内数据安全？

本文插图

8 月 26 日，我们发起了第 6 期 SIG Cloud-Provider-Alibaba 网研会直播。本次直播主要介绍了机密计算的概况，InclavareContainers 开源项目架构、已支持的功能和迭代计划，以及阿里云 ACK-TEE 的发展现状和规划。
本文汇集了此次直播完整视频回顾及资料下载，并整理了直播过程中收集的问题和解答，希望能够对大家有所帮助~阿里巴巴云原生公众号后台回复“826”即可下载相关 PPT 。
直播视频回顾链接：https://v.qq.com/x/page/z3143a6agsg.html
机密计算简介
1. 应用容器安全现状

本文插图

Portworx and Aqua Security 发布的《2019 容器接受度调研》报告显示，安全性成为了用户使用容器技术和业务上云面临的最大挑战，其中数据安全问题最为突出；根据 Risk Based Security 发布的数据泄露报告显示， 2019 年数据泄露事件发生的数量和泄露的数据量与 2018 年相比均增加了 50%+ 。
2. 机密计算时代到来

本文插图

数据在整个生命周期有三种状态：At-Rest（静态）、In-Transit（传输中）和 In-Use（使用中）。

At-Rest 状态下，一般会把数据存放在硬盘、闪存或其他的存储设备中。保护 At-Rest 状态的数据有很多方法，比如对文件加密后再存放或者对存储设备加密；
In-Transit 是指通过公网或私网把数据从一个地方传输到其他地方，用户可以在传输之前对文件加密或者采用安全的传输协议保证数据在传输中的安全，比如 HTTPS, SSL, TLS, FTPS 等；
然而 In-Use 状态的数据很长时间内都没有很好的保护的方法，直到机密计算的出现。

机密计算联盟给机密计算的定义是：机密计算是在一个基于硬件的可信执行环境（TEE）中保护数据执行计算。
机密计算的核心功能有：

保护 In-Use 数据的机密性：内存中的数据是被加密的，即便被攻击者窃取到内存数据也不会泄露数据；
保护 In-Use 数据的完整性：度量值保证了数据和代码的完整性，使用中有任何数据或代码的改动都会引起度量值的变化；
保护 In-Use 数据的安全性：相比普通应用，机密计算应用有更小的 TCB（Trusted Compute Base），意味着更小的攻击面，也意味着更安全。，以 Intel SGX 为例，除了 CPU 和可信应用自身以外，其他软硬件的访问都是被拒绝的，包括操作系统、Hypervisor 等。

在 2019 年 Gartner 的《计算基础设施成熟度曲线》中把机密计算也列入其中，虽然还处在早期阶段，这也说明机密计算开始逐步进入大家的视野并得到重视。
在 2020 年 Gartner的《云厂商本地安全解决方案比较》中，阿里云在 Trusted execution enviorments 中拿到一个 H ，是因为 2020 年年初阿里云容器服务发布了机密计算产品 ACK-TEE ，更多参考链接。
3. 机密计算业务场景

本文插图

机密计算旨在保护敏感的代码和数据。业务场景有：区块链、秘钥管理、金融、AI、多方计算、数据租赁、边缘计算等。
以多方计算为例，不同用户或厂商之间相互共享数据以便计算挖掘出更大的数据经济价值，但不想把自己的数据泄露给对方。机密计算可以保护共享数据运行在受硬件保护的可信执行环境中，数据在内存中是加密的，从而保证数据不会被泄露。
4. 安全容器与机密计算的区别

本文插图

除了机密计算外，还有一个与安全相关的概念-安全容器。阿里云在安全容器和机密计算领域都有布局，虽然二者都与安全相关，但它们的定位和应用场景是不同的。
安全容器的定位是隔离，把恶意应用隔离起来，防止它出去对其他应用搞破坏。主要的应用场景有三类：

不可信负载隔离
多租户应用隔离
性能和故障隔离

机密计算的定位是保护，保护应用不会被其他恶意应用进来窃取数据和搞破坏。应用场景是保护敏感代码和数据。
5. TEE 硬件平台

本文插图

支持 TEE 的硬件平台主要有 3 个：Intel SGX、ARM TrustZone 和 AMD SEV ，它们有不同的应用场景和实现方式：

ARM TrustZone 把硬件资源分为安全世界和非安全世界两部分，所有需要保密的操作在安全世界执行，其余操作在非安全世界执行，安全世界和非安全世界通过一个名为 Monitor Mode 的模式进行转换。典型的应用场景有移动支付、数字钱包等；
AMD 利用 SEV（AMD Secure Encrypted Virtualizationn）， SME（AMD Secure Memory Encryption）和SEV-ES（Secure Encrypted Virtualization-Encrypted State）等技术实现虚拟机的 Guest 内存加密和安全隔离；
Intel SGX 是 Intel 提供的一组指令，用于提高应用的代码和数据的安全性，用户可以把敏感数据放入到 Encalve 中， Enclave 是一种受保护的可信执行环境。

阿里云 ACK-TEE 和开源项目 Inclavare Containers 都是基于 Intel SGX 实现的机密计算。
6. Intel SGX 有更小的 TCB(Trusted Computing Base)

本文插图

按照普通方式部署敏感应用，应用会依赖操作系统、VMM、硬件甚至是云厂商， TCB 非常大，面临的攻击面也非常大。只要 TCB 中只要有一处遭到攻击，应用都有数据泄露和破坏的风险。
而把敏感应用部署在 Intel SGX 的 TEE 中， TCB 只有 CPU 和 TEE 本身。一方面攻击面变得很小，另一方面 TEE 的安全机制也会使应用更安全。
7. 基于 Intel SGX 的可信应用开发和使用流程

本文插图

Intel SGX 把应用分成了可信区和不可信区。用户可通过在 EDL（Enclave Definition Language）中定义可信区和不可信区以及用到的函数。这些函数用户可信区和不可信区之间的通信，分为 ECALL 和 OCALL 。 ECALL 用于不可信区访问可信区的数据， OCALL 用于可信区访问不可信区的数据。
基于 Intel SGX 的可信应用开发和使用流程如下：

申请秘钥：向 Intel 申请 SGX 相关的商业签名加密密钥；
安装环境：安装 Intel SGX 驱动安装 SGX SDK 和 PSW安装 AESM 服务
开发应用：明确应用可信区中须保护的代码和数据；编写 EDL 文件，明确 ECALL 和 OCALL 函数；编写可信区代码和非可信区代码；
编译构建使用 sgx_edger8r 基于 edl 文件生产用于 ECALL 的不可信区的代理函数和用于 OCALL 的可信代理函数；编译 Enclave动态链接库文件；签名上一步骤的 Enclave 动态链接库文件；编译应用，打包镜像。
用 Docker 运行容器

Inclavare Containers 保护敏感应用和数据
1. Inclavare Containers 的目标和价值

本文插图

Inclavare ，是 Enclave 一词的拉丁语词源，读音是 [?inklɑve?] 。 Enclave 指的是一种受保护的执行环境，能为其中的敏感和机密数据提供基于密钥学算法的强安全隔离，阻止不可信的实体访问用户的数字资产。
Inclavare Containers 是由阿里云操作系统安全团队和阿里云云原生容器服务团队主导，并联合了阿里经济体内多个研发团队（蚂蚁安全计算团队、云安全团队、语言 runtime 团队等）共同研发的面向机密计算场景的开源容器运行时技术栈。
当前机密计算在云原生场景中提供的技术，有很多缺陷和不足：

使用和开发成本都比较高；
容器化和对接 Kubernetes 的成本和复杂度高;
服务提供商提供的技术解决方案也相对单一

由于以上原因，非常不利用机密计算技术的普及和应用。而 Inclavare Containers 目的就是为业界提供一款面向机密计算领域的开源容器运行时引擎和安全架构，其价值在于：

抹平机密计算的高使用门槛，为用户提供与普通容器一致的使用体感；
基于处理器提供的多种硬件安全技术，为用户的工作负载提供多种不同的 Enclave 形态，在安全和成本之间提供更多的选择和灵活性。

2. Inclavare Containers 架构

本文插图

在介绍 Inclavare Containers 架构之前，先介绍一下架构中各个组件的作用：

kubelet：Kubernetes 集群中每个 Node 节点上运行的主要“节点代理” ，负责与 Apiserver 的通信和管理节点上 Pod；
Containerd：一个工业级标准的容器运行时，它强调简单性、健壮性和可移植性， Containerd 可以在宿主机中管理完整的容器生命周期：容器镜像的传输和存储、容器的执行和管理、存储和网络等；
shim-rune：为容器运行时 rune 提供的 shim ，主要负责管理容器的生命周期、把普通镜像转换成 TEE 镜像；
rune：rune 是一个命令行工具，用于根据 OCI 规范在容器中生成和运行 Enclave 。rune 是在 runc 代码基础上开发的，既可以运行普通 runc 容器也可以运行 Enclave 容器；
SGX LibOS：SGX LibOS 是为了让普通应用在不做或做很少更改的情况下，就能够在 Intel SGX 上运行起来。目前 Inclavare Containers 支持的 LibOS 有 Occlum ， Graphene-SGX 正在对接中；
语言 Runtime：LibOS 对多语言的支持，比如 Occlum 中提供了 Golang 和 JDK 语言运行时；
PAL-API：rune 和 LibOS 之间通信的接口。比如 pal_init 用于初始化 Enclave ， pal_create_process 用于创建 Encalve 。
liberpal.so：是实现了 PAL-API 的 Linux 动态库，主要负责 rune 和 LibOS 的通信。

Inclavare Containers 的工作流程如下：

kubelet 向 Containerd 发起 CRI（Container Runtime Interface）请求，比如请求创建一个 Pod
Containerd 中有一个 cri-containerd 的插件实现了 CRI 接口， Containerd 接收到请求后，把请求转给 shim-rune
shim-rune 既可以创建 runc 容器也可以创建 rune 容器。在创建 runc 和 rune 容器的处理流程也有差异：创建 runc 容器：与创建普通 runc 容器过程完全一样，比如 Pod 的 pause 容器就是 runc 容器。创建 rune 容器：利用 LibOS 把普通镜像转换成 TEE 镜像， rune 会在容器内创建 Enclave 并把应用运行在 Enclave 中。
rune 加载 liberpal.so ，用于 rune 与 LibOS 的通信。
rune 把 Intel SGX 驱动载入容器内，并在容器内创建 1 号进程 init-runelet ，再由 init-runelet 创建 Encalve 。 Enclave 是一个受 Intel SGX 保护的可信执行环境， Enclave 内包含：LibOS、语言 Runtime 和应用本身。至此一个可信应用就运行起来了。

总结下来， Inclavare Containers 的特点有：

将 IntelSGX 与容器生态结合，兼容 OCIRuntime 和 OCI 镜像标准，实现 Enclave 容器形态；
与 Kubernetes 生态无缝整合；
基于 LibraryOS 技术，改善 IntelSGX 引入的约束条件所带来的兼容性问题；
提供对高级语言 Runtime 的支持，进一步提升兼容性；
定义通用的 EnclaveRuntimePALAPI 规范，构建 EnclaveRuntime 生态。

3. shim-rune 工作流程

本文插图

shim-rune 包含两部分 Core 和 Carrier ，它们的作用分别是：

管理容器生命周期
利用 LibOS 把普通容器转换为 TEE 镜像

shim-rune 的工作流程为：

以容器镜像为输入，利用 LibOS 生成未签名的 Enclave 动态库；
从 Enclave 动态库中导出签名材料；
以签名材料为输入，请求签名服务进行签名，返回的内容有摘要文件和公钥；
生成签名的动态库；
rune 加载签名的动态库，创建并启动 Enclave 。

4. 客户端签名与服务端签名

本文插图

Inclavare Containers 支持客户端签名和服务端签名两种工作方式，两种工作方式的差异如下：

本文插图

相比客户端签名，服务端签名优点如下：

降低了开发者使用门槛，开发者不需要掌握 Intel SGX 的技术，按照 LibOS 要求构建出普通镜像即可；

注意：每种 LibOS 对普通镜像也有一定要求，比如 Occlum 只支持 musl libc 而不支持 glibc ，所以 glibc 应用需要改造为 musl libc 应用之后才能在 Inclavare Containers 中运行起来。

用户不需要自己向 Intel 申请商业证书；
可运行在 Kubernetes 集群中。

5. 多团队共建合作

本文插图

Inclavare Containers 项目是由多个团队共建合作而成的，各组件作用和团队分工如下：

Occlum：由蚂蚁安全计算团队自研的基于 Intel SGX 技术并实现了内存安全的多进程 Library OS
Graphene-SGX：基于 IntelSGX 技术并可以运行未经修改程序的开源 library OS
Dragonwell：由阿里编译器团队定制的 LTS OpenJDK 发行版本
sgx-device-plugin：由阿里云容器服务团队和蚂蚁安全计算团队针对 IntelSGX 联合开发的 Kubernetes Device Plugin
AliyunLinux：由阿里 BaseOS 团队对 Inclavare Containers 提供全栈适配 aliyun linux 的支持

6. Inclavare Containers 开源项目

本文插图

Inclavare Containers 是业界首个面向云原生的机密计算场景下的开源容器运行时技术栈，被阿里巴巴开源委员会评为重点开源项目。并且已经加入到官方机密计算 OCIRuntime 参考实现列表。
目前支持的功能有：

支持通过 K8s 和 Docker 启动 Enclave 容器
支持 Occlum 和 Graphene 两个主流 LibOS
支持 Java 和 Golang 语言 Runtime

该项目每个月月底进行一次发布，面向社区提供 CentOS 和 Ubuntu 的 binary release ，并对内提供 AliyunLinux 发行版本。
7. Inclavare Containers 里程碑

本文插图

本文插图
8. 2020 年机密计算技术业产业

本文插图

ACK-TEE
1. 简介

本文插图

【|当Kubernetes遇到机密计算，如何保护容器内数据安全？】ACK-TEE 于 2019 年 9 月立项
功能：

对数字资产（算法、数据、代码）有强安全诉求的云用户提供基于硬件加密技术的可信执行环境(TEE)
降低机密计算技术的应用门槛
简化可信/机密应用的开发、交付和管理成本。

合作团队：阿里云容器服务团队、操作系统内核团队、云安全团队、蚂蚁安全团队和运行时语言团队
定位：云原生机密计算容器平台
使命：让天下没有难用的机密计算
产品原则：可信安全、易开发交付、标准开放、云原生
2. ACK-TEE 1.0

本文插图

ACK-TEE 1.0 于 2020 年 1 月份上线
目标用户群体：原生 SGX 用户
全新 K8s 托管集群形态：机密计算专用集群，支持 Intel SGX1 。
复用 Managed K8s 已有能力，包括各种云产品集成， K8s 集群运维能力，降低 K8s 集群的运维复杂度；
支持 EPC 加密内存的管理和调度，降低用户使用 SGX 设备的复杂度。
3. ACK-TEE 2.0

本文插图
ACK-TEE2.0 计划在 2020 下半年上线
功能：支持原生应用在 TEE 中运行起来
目标用户：没有掌握机密计算技术但有数据安全需求的用户
方案

把普通镜像转换成 TEE 镜像后运行在 TEE 中；
通过 controller 提供安全可信的服务组件，如 KMS-Enclave-Plugin 等。

Q & A
Q1：这个依赖于 Intel 的芯片？为啥还需要单独找 Intel 申请密钥？A1：Intel 芯片能保证应用执行在基于硬件的 Enclave （一种可信执行环境）中，保证应用的安全，但不能保证创建者一定是合法的。而在构建 Enclave 时我们会用 Intel 的秘钥对其签名，保证使用者是合法的。
Q2：Inclavare Containers 本质上是一个容器运行时实现吗？它能完全替代 Docker 容器运行时的场景吗？A2：Inclavare Containers 是一个软件栈，它包含了 rune、shim-rune、runelet 等多个工具。其中 rune 是一个容器运行时，它是在 runc 代码基础上开发的。既可以运行普通 runc 容器，也可以跑有 Enclave 的容器。功能上说，可以替代 Docker 容器运行（runc）时，但最大的意义在于运行 Enclave 容器，保证代码和数据的安全。
Q3：应用的性能有多少影响，有做过类似的测试吗？A3：Inclavare Containers 的重点是解决数据安全问题的。底层是基于 Intel SGX 的技术，目前 Intel SGX1 的 ECP 只有 128 MB 内存，相比原生容器应用的性能肯定会差很多。
Q4：所以理解下来，只把它用在最核心的需要 in-use 加密的地方，对吗？A4：是的，保护 In-Use 代码和数据的安全是机密计算的最大价值。
Q5：ACK 现在有这个使用方法和 sample 吗？A5：ACK 里有托管版“加密计算” ，即分享里讲到的 ACK-TEE 1.0 。但面向客户是 SGX 原生客户，需要客户自己基于 SGX 做应用改造和构造镜像。 ACK-TEE 2.0 还在规划中，计划年底上线，会把 Inclavare Containers 的能力移植过来。我理解你是想要 ACK-TEE 2.0 的 sample 是吗？如果有兴趣，你可以按照 Inclavare Containers 0.3.0 的文档，搭建一个支持机密计算的 Kubernetes 集群。
作者 | 贾之光（甲卓）阿里巴巴高级开发工程师，专注于 Kubernetes 安全沙箱和机密计算领域，主要参与 Incalvare Containers 社区开发。
本文为阿里云原创内容，未经允许不得转载。