蚂蚁是如何改进 K8s 集群敏感信息的安全防御的？

在 Kubernetes 中，Secret 显得尤为重要。由于它是 K8s 中存储全部敏感信息的对象。据悉，这些敏感信息包含密码、集群的证书、OAuth token、ssh key 以及其余用户自定义的敏感文件等。所以，一旦 K8s 中 Secret 出现安全问题，后果将很是严重。此外，虽然社区提供了必定的安全防御方案，可是依然存在诸多问题。

K8s Secret 面临着哪些安全问题？这些安全问题会带来什么影响？社区提供的解决方案存在哪些不足？......针对这些问题，InfoQ 记者采访了蚂蚁集团高级工程师秦凯伦，他专一于可信计算、系统安全和虚拟化等领域，对 K8s Secret 有着深刻的研究和探索。

K8s Secret 的安全问题

根据 Kubernetes 文档，Secret 是 K8s 中存储全部敏感信息的对象。事实上，若是敏感信息直接存放于 K8s 的 Pod spec 或镜像中，不只管控困难，并且存在较大的安全隐患。所以，K8s 经过建立、管理、应用 Secret 对象，能够更好地控制敏感信息的用途，并下降其意外暴露的风险。

秦凯伦称，虽然引入 K8s Secret 对象，这在必定程度上下降了意外泄露的风险（更多地是经过集中式的管理），可是 K8s Secret 对象自身的安全性，“社区默认方案中仍存在许多安全问题”。

通常来讲，K8s 中，Secret 数据以纯文本的方式存储在 etcd 中，默认只有 base64 编码，未经加密。同时，共享该文件或将其检入代码库，密码容易泄露。

社区解决方案的不足

针对此问题，K8s 社区提供了基于 KMS 的 K8s Secret 加密方案，谷歌云、AWS 和 Azure 均支持该方案。他说，“这虽然解决了 etcd 中 Secret 明文存储问题，但依然有一些问题。”

• Secret、加密 Secret 的密钥在内存中明文存放、易被攻破；
• 攻击者能够假冒合法用户，调用解密接口，窃取密钥；

密钥一旦泄露，将致使全部数据的泄露，从而引发用户对整个系统的信任崩溃。“为此，社区和一些公司尝试为该方案中的 Plugin 加上基于硬件的安全保护，从而提高攻击难度。但对某些特定用户来讲，保护的覆盖面和程度依然不够”。

实际上，咱们能够从 K8s Secret 的整个生命周期来看：

• Secret 的生成及访问 Secret 的身份证书明文存放在用户侧内存中，用户侧环境复杂，容易被攻击者攻破；
• 加密 Secret 的密钥的生成、cache 等在 K8s API server 中明文存放在内存中，安全根易被窃取或破坏；
• 与 KMS 交互的 Plugin 的加解密接口没法防止攻击者假冒，存在泄漏风险；
• Secret 在 Node 中消费，依然明文内存存放，暴露出必定攻击面；

在秦凯伦看来，理想中，对 K8s 中 Secret 的保护程度应该考虑其整个生命周期的安全、可信，作到端到端的安全防御。

蚂蚁集团的探索

为此，他们基于 TEE 技术，将 K8s Secret 整个生命周期和端到端使用过程当中的关键组件、步骤保护起来。总体方案大体以下：

• 将 API Server 端与 KMS 交互的 KMS Plugin  用 TEE 保护，在保障了 Plugin 中根密钥（安全根）、数据加密密钥无泄漏风险的前提下，下降了性能开销；
• 将 API Server 端的 KMS provider 用 TEE 保护，避免数据密钥及 Secret 在任什么时候候明文直接暴露在内存中；同时，经过 TEE 的本地证实机制可以认证解密数据密钥接口的调用者，防止攻击者假冒，确保密钥的安全；
• 将用户端的 kubectl、kubeconfig 等使用 TEE 保护，一方面 kubeconfig 不落盘同时被硬件保护，提高了安全水位；另外一方面，用户的 Secret 经过安全信道直通到 TEE 中进行处理，避免了直接暴露在内存中，规避了被恶意窃取的风险，且用户对 API Server 进行 TEE 远程证实，能够帮助用户确信他正在把本身的 Secret 托付给可信的软件实体（没有含有故意泄露用户秘密的恶意逻辑），创建对 API Server 的信任；
• 将 Node 端的 kubelet 中 Secret 的消费过程用 TEE 保护，进一步避免了 Secret直接暴露在内存中，规避了被恶意窃取的风险；

秦凯伦向 InfoQ 记者指出，“这种方案是基于 TEE 的端到端 K8s Secret 保护，还引入 LibOS 技术，实现 TEE 保护对用户、开发者和运维团队彻底透明。”

据悉，KMS Plugin 和 TEE-based KMS Plugin 没有标准和开源的社区实现，所以他们设计并开发了本身的 KMS Plugin，并在灰度发布、应急处理、监控管理等方面进行了生产加强。“在与 TEE 结合的过程当中，咱们为了应对 SGX 机型存在的性能问题，提供了 standalone 和服务化 KMS Plugin 两套方案”。

一样，TEE-based kubectl 也没有标准和开源的社区实现，他说：“咱们基于 kubeproxy 开发了本身的安全 kubectl，实现了 kubeconfig 对用户透明、与用户身份绑定、不落盘并采用TEE保护内存安全等设计目标。”

此外，考虑到 TEE 保护的易用性、可靠性、可扩展性和可维护性等，他们在评估多套方案后，引入了由蚂蚁开源的 Occlum LibOS，屏蔽了 TEE 对用户、开发者和运维团队的影响，大大下降了 TEE 开发的门槛和成本。

在秦凯伦看来，K8s 做为蚂蚁大规模容器集群的管控根基，应用基于 TEE 的端到端 K8s Secret 保护防御方案，加强了其自身安全和可信，提高了蚂蚁核心管控平面的安全水位，“这对于金融场景下高标准的数据安全和隐私保护来讲不可或缺”。

K8s 相关阅读

• 备战双 11！蚂蚁金服万级规模 K8s 集群管理系统如何设计？
• Kubernetes: 微内核的分布式操做系统
• 开箱即用的 Java Kubernetes Operator 运行时
• 深刻Kubernetes 的“无人区” — 蚂蚁金服双十一的调度系统
• 深度 | 蚂蚁金服自动化运维大规模 Kubernetes 集群的实践之路