在 K8s 中,Secret 非常重要。因为它是 K8s 中存储所有敏感信息的对象。据悉,这些敏感信息包含密码、集群的证书、OAuth token、ssh key 以及其他用户自定义的敏感文件等。因此,一旦 K8s 中 Secret 出现安全问题,后果将非常严重。此外,虽然社区提供了一定的安全防护方案,但是依然存在诸多问题。
K8s Secret 面临着哪些安全问题?这些安全问题会带来什么影响?社区提供的解决方案存在哪些不足?…针对这些问题,InfoQ 记者采访了蚂蚁集团高级工程师秦凯伦,他专注于可信计算、系统安全和虚拟化等领域,对 K8s Secret 有着深入的研究和探索。
根据 K8ss 文档,Secret 是 K8s 中存储所有敏感信息的对象。事实上,如果敏感信息直接存放于 K8s 的 pod spec 或镜像中,不仅管控困难,而且存在较大的安全隐患。因此,K8s 通过创建、管理、应用 Secret 对象,可以更好地控制敏感信息的用途,并降低其意外暴露的风险。
秦凯伦称,虽然引入 K8s Secret 对象,这在一定程度上降低了意外泄露的风险(更多地是通过集中式的管理),但是 K8s Secret 对象自身的安全性,“社区默认方案中仍存在许多安全问题”。
一般来说,K8s 中,Secret 数据以纯文本的方式存储在 etcd 中,默认只有 base64 编码,未经加密。同时,共享该文件或将其检入代码库,密码容易泄露。
针对此问题,K8s 社区提供了基于 KMS 的 K8s Secret 加密方案,谷歌云、AWS 和 Azure 均支持该方案。他说,“这虽然解决了 etcd 中 Secret 明文存储问题,但依然有一些问题。”
密钥一旦泄露,将导致所有数据的泄露,从而引起用户对整个系统的信任崩溃。“为此,社区和一些公司尝试为该方案中的 Plugin 加上基于硬件的安全保护,从而提升攻击难度。但对某些特定用户来说,保护的覆盖面和程度依然不够”。实际上,我们可以从 K8s Secret 的整个生命周期来看:
在秦凯伦看来,理想中,对 K8s 中 Secret 的保护程度应该考虑其整个生命周期的安全、可信,做到端到端的安全防护。
为此,他们基于 TEE 技术,将 K8s 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 保护防护方案,增强了其自身安全和可信,提升了蚂蚁核心管控平面的安全水位,“这对于金融场景下高标准的数据安全和隐私保护来说不可或缺”。