蚂蚁是如何改进k8s集群敏感信息的安全防护的?

原创
2020/08/11 17:30
阅读数 129

在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的K8sSecret加密方案,谷歌云、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保护防护方案,增强了其自身安全和可信,提升了蚂蚁核心管控平面的安全水位,“这对于金融场景下高标准的数据安全和隐私保护来说不可或缺”。


END -

本文分享自微信公众号 - 支付宝技术(Ant-Techfin)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
0 评论
0 收藏
0
分享
返回顶部
顶部