[译] Kubernetes 安全的 6 大零信任原则

本文是 NIST 的核心零信任架构原则以及建议在实践中应用它们的 Kubernetes 和 Istio 参考架构。

声明
此文为个人翻译,仅供参考,不代表我个人立场。翻译过程中可能有删改或遗漏,如需了解原文,请自行查阅。如有疏漏,欢迎指正。
查看本文大纲

传统的网络安全依赖于围绕可信内部网络的强大防御边界,以将不良行为者拒之门外,将敏感数据拒之门外。在日益复杂的网络环境中,维护强大的边界越来越困难。

零信任安全正在成为企业保护其传统和现代云原生应用程序的首选方法。零信任网络架构颠覆了边界安全的假设。在零信任网络中,每个资源都在内部受到保护,就好像它暴露在开放的互联网中一样。

为了为行业和美国联邦政府建立零信任安全指南,美国国家标准与技术研究院 (NIST) 在一系列出版物中建立了零信任安全指南,从 SP 800-207 开始,介绍一般的零信任架构及其配套SP 800-204 微服务安全标准系列

以下是 NIST 的核心零信任架构原则以及建议在实践中应用它们的 Kubernetes 和 Istio 参考架构。

零信任网络的六项原则

  1. 无论网络位置如何,所有通信都应该是安全的。网络位置和可达性并不意味着信任。企业拥有或其他专用网络内部的访问请求必须满足与来自任何其他位置的通信相同的安全要求。零信任系统的一个标准是,您可以将它暴露在开放的互联网上,并且它仍然是安全的,没有未经授权的系统、数据或通信访问。
  2. 所有通信都应加密。线路上的加密可防止窃听,并确保消息真实且未被篡改。这意味着至少为所有通信实施 TLS,将mTLS 和相关的安全工作负载身份作为服务间通信的最佳实践
  3. 对每个资源的访问都应该根据动态策略进行身份验证和授权。在允许任何访问之前,对服务身份和最终用户凭据进行动态身份验证和授权。访问请求的动态上下文应该是访问决策的一部分。这可能包括行为属性,如与观察到的使用模式的偏差或请求资产的状态,如安装的软件版本、网络位置和请求的时间 / 日期。授予访问权限时,应以所需的最低权限授予它。
  4. 对资源的访问应该在空间上有界。围绕资源的信任范围应尽可能小 —— 理想情况下为零。访问应该由每个能够检索和执行访问决策的资源前面的策略执行点 (PEP) 进行调解。这应该适用于所有入站、出站和服务到服务的访问。
  5. 应及时限制对资源的访问。身份验证和授权绑定到一个短暂的会话,之后它们必须重新建立。这可确保频繁做出访问决策,并使用最新的可用上下文。
  6. 对资源的访问应该是可观察的。应收集并使用尽可能多的信息来改善安全态势。这允许持续监控所有资产的完整性和安全状况,并持续确保策略执行。此外,应反馈从观察中获得的见解以改进政策。

为什么零信任安全性更好

  • 网络可达性不是授权。与边界安全性不同,对服务的访问不会仅仅因为该服务可访问而被授予。它也必须经过明确的身份验证和授权。
  • 周边突破口的有限爆炸半径可防止攻击者横向移动。经过身份验证和授权的工作负载免受边界破坏。及时限制凭证泄露的风险。
  • 细粒度策略。空间边界允许高粒度的策略执行。
  • 频繁的政策评估。通过在短期会话上执行动态策略来及时绑定可确保授权基于最新的策略。
  • 安全、真实的通信。加密和强大的工作负载身份限制了侦察并提供了通信的真实性。
  • 安全状况和合规性的实时和可审计保证。细粒度的可观测性允许实时保证和政策实施的事后审计以及故障排除和分析所需的数据。

如何使用 Istio 在 Kubernetes 中实现零信任安全:现代微服务应用程序的参考架构

作为 NIST 的一般零信任架构标准的补充,NIST 还发布了如何将零信任原则专门应用于微服务应用程序的标准。这些标准由 Tetrate 创始工程师 Zack Butcher 共同编写,并编入NIST 的 SP 800-204 系列

在该标准中,NIST 建立了一个由 Kubernetes 组成的参考平台,用于编排和资源管理,并使用 Istio 服务网格提供核心安全功能。

Kubernetes 安全漏洞

由于 Kubernetes 主要专注于编排、资源管理和基本连接,因此它将零信任网络安全问题留给其他方解决。Kubernetes 中的主要网络安全漏洞是(NIST SP 800-204B,§2.1.1):

  • 默认情况下不安全的通信
  • 缺少在 pod 之间强制执行 TLS 所需的内置证书管理机制
  • 缺乏身份和访问管理机制
  • 在 OSI L3 而非 L7 运行的防火墙策略,因此无法窥视数据包或做出元数据驱动的决策

服务网格填补了 Kubernetes 的安全漏洞:微服务应用程序的安全内核

为了增强 Kubernetes 的安全性,Istio 充当 NIST 参考架构中的安全内核。Istio 满足参考监视器的三个要求(NIST SP 800-204B,§5.1)。Istio 是:

  • 不可旁路
  • 防止修改
  • 验证和测试是正确的

Envoy 数据平面通过每个服务前面以及每个入口和出口网关的不可绕过的策略执行点 (PEP) 提供参考监视器。服务网格代码独立于应用程序,因此它的生命周期可以独立管理,并且不能在运行时修改。而且,网格是系统的一个严格控制的元素,可以通过更多的眼睛和更仔细的检查来强化(NIST SP 800-204B,§5.1)。

而且,作为专用的基础架构层,Istio 提供:

  • 解决横切应用程序问题的统一方法;
  • 快速解决这些问题的标准插件和构建自定义插件的框架;
  • 简化操作复杂性;
  • 易于管理第三方开发人员和集成商;
  • 降低开发和运营成本。

下一步

要从联邦安全标准的合著者那里了解有关如何实施零信任架构的更多信息,请阅读 Zack Butcher 的零信任架构白皮书

有关 NIST 安全建议的深入指南以及 Tetrate 如何帮助您实施该标准,请查看Tetrate 的微服务联邦安全要求指南

如果您正在寻找使用 Istio 投入生产的最快方式,请查看我们的开源Tetrate Istio Distro (TID)。TID 是经过审查的 Istio 上游发行版 ——Istio 的强化映像,具有持续支持,更易于安装、管理和升级。对于在联邦监管环境中运营的组织,Tetrate Istio Distro 是唯一具有可用 FIPS 验证构建的 Istio 发行版。

如果您需要一种统一且一致的方式来保护和管理一系列应用程序中的服务,请查看 Tetrate Service Bridge (TSB),这是我们基于 Istio 和 Envoy 构建的全面的边缘到工作负载应用程序连接平台。

最后更新于 2024/12/12