在 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 集群的实际之路