乐趣区

关于javascript:当-Kubernetes-遇到机密计算阿里巴巴如何保护容器内数据的安全

简介: 8 月 26 日,咱们发动了第 6 期 SIG Cloud-Provider-Alibaba 网研会直播。本次直播次要介绍了秘密计算的详情,InclavareContainers 开源我的项目架构、已反对的性能和迭代打算,以及阿里云 ACK-TEE 的倒退现状和布局。本文会集了此次直播残缺视频回顾及材料下载,并整顿了直播过程中收集的问题和解答,心愿可能对大家有所帮忙~

作者 | 贾之光(甲卓)阿里巴巴高级开发工程师,专一于 Kubernetes 平安沙箱和秘密计算畛域,次要参加 Incalvare Containers 社区开发。

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 的工作流程如下:

  1. kubelet 向 Containerd 发动 CRI(Container Runtime Interface)申请,比方申请创立一个 Pod
  2. Containerd 中有一个 cri-containerd 的插件实现了 CRI 接口,Containerd 接管到申请后,把申请转给 shim-rune
  3. shim-rune 既能够创立 runc 容器也能够创立 rune 容器。在创立 runc 和 rune 容器的解决流程也有差别:

    1. 创立 runc 容器:与创立一般 runc 容器过程齐全一样,比方 Pod 的 pause 容器就是 runc 容器。
    2. 创立 rune 容器:利用 LibOS 把一般镜像转换成 TEE 镜像,rune 会在容器内创立 Enclave 并把利用运行在 Enclave 中。
  4. rune 加载 liberpal.so,用于 rune 与 LibOS 的通信。
  5. 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 的工作流程为:

  1. 以容器镜像为输出,利用 LibOS 生成未签名的 Enclave 动静库;
  2. 从 Enclave 动静库中导出签名资料;
  3. 以签名资料为输出,申请签名服务进行签名,返回的内容有摘要文件和公钥;
  4. 生成签名的动静库;
  5. 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. 简介

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 集群。

原文链接
本文为阿里云原创内容,未经容许不得转载。

退出移动版