在 Kubernetes 中实施零信任的七条准则
原文作者:Matthew Yacobucci of F5转载来源:NGINX 官方网站
同年 8 月,美国国家标准与技术研究院 (NIST) 发布了一份
白皮书
,白皮书定义了零信任架构 (ZTA),并探讨了“零信任可以改善企业整体信息技术安全态势的部署模型和用例”。各个政府机构(包括网络安全和基础设施安全局 (CISA) 以及管理和预算办公室)相继发布零信任实施指导文件,其中包括一个成熟度模型以帮助实施者了解如何分步实现完全零信任部署。
多年来,Kubernetes 社区一直在
讨论如何让零信任
成为端到端加密战略的关键组成部分。service mesh 提供商已经实施了一些关键实践(例如 mTLS 和证书密钥轮换),旨在简化零信任的实施。但即便如此,我们仍处于在大规模应用中实施稳健零信任架构的早期阶段。关于零信任对 Kubernetes 意味着什么以及最佳实践是什么,仍然存在一些争议。相比传统 IT 和基础架构系统,开箱即用的 Kubernetes 给不了解 Kubernetes 网络和安全与前者的区别的团队带来了重大的安全挑战。
什么是零信任?为何零信任很重要?
传统的安全模型在部署环境周围构筑了一个强大的边界,并通过一个集中的“看门人”验证用户身份,且只允许授权用户访问内部的基础架构。随着
微服务
、云和分布式部署的采用,这种模型逐渐被淘汰,因为边界已变得越来越模糊,甚至不确定边界是否还存在。零信任应运而生。
在零信任模型中,几乎没有任何东西或任何人是可信的,包括用户、应用、网络、服务器、服务或 API。每一层的每一个元素都必须经过身份验证和授权测试。当技术资产、应用或服务连接并交换数据时,所有通信都通过指定的代理进行路由,该代理对所有各方进行身份验证并根据访问策略授予他们权限。重要的是,除了明确授权访问特定资源的人以外,零信任系统在每个级别都以最小权限运行,并拒绝所有各方的访问。
零信任具有很多优势——它可以通过以下方式改善安全状况:
-
自动阻止未经授权的活动
-
通过访问控制减少可访问的攻击面
-
快速检测行为异常和危害指标(Indicator of Compromise)
-
通过实时最小权限策略限制访问时间
-
使安全性独立于其他所有变量,包括环境和地理
-
通过持续的认证和身份验证拦截正在进行的攻击
零信任对于
云原生
应用和基础架构尤为重要。松散耦合且可移植的云原生应用被设计成在容器中运行,并根据需要改变位置和状态。除了代码、配置和少数必要元素(例如将云原生应用链接到外部世界或内部服务的 IP 地址)之外,一切都是短暂的。东西向流量(环境内部的流量)和南北向流量(进出环境的流量)看起来越来越相似。API 在所有通信(包括应用环境内的通信和与外部客户端的通信)中起中介作用。不断验证权限和身份不仅有用,而且最终还是一种安全需要。
在 Kubernetes 中实施零信任的七条准则
为 Kubernetes 驱动的基础架构和应用部署零信任可能具有一定的挑战性,为此我们提供了一系列实施准则。这些准则可能看起来平淡无奇,但要从零开始实施也不轻松。
准则 1:避免增加 Kubernetes 架构的复杂性
准则 2:将开发人员和最终用户的额外开销降至最低
开发人员不想考虑零信任,而且我们也没有理由强迫他们考虑。当零信任的实施迫使开发人员改变其行为或工作流程时,他们可能会抗拒,因为他们认为安全防护会影响开发速度。改变行为或工作流程也显著增加了人为错误的机会 ——
开发人员本身
始终是安全链中的薄弱环节。作为 NetOps 或 SecOps 工程师,如果零信任机制透明到开发人员(以及最终用户和客户)都不知道它们的存在,那么您就成功了。事实上,通过增强安全策略及提高其自动化水平,从理论上来说,零信任甚至可以消除多因素身份验证和许多安全流程中的不便,进而改善最终用户的体验。
准则 3:将零信任规则应用于数据平面和控制平面
虽然数据平面是应用的“活动所在地”,但控制平面通常也同样容易(有时甚至更容易)遭受
供应链攻击
和其他入侵。由于策略引擎以及用于遥测和跟踪的数据收集系统等复杂元素的介入,在控制平面上实施零信任合规要比在数据平面上更复杂。虽然我们很想为数据平面实施零信任,并减少对控制平面及其所有移动部件的担忧,但我们必须确保两者都符合要求,以最大限度发挥零信任的优势。
准则 4:为东西向和南北向流量实施零信任
许多组织开始选择仅将零信任应用到南北向流量,因为来自环境外部的流量似乎不如内部流量可信。这是一种错误的做法。在 Kubernetes 中,东西向流量无论在外观还是行为上都很像南北向流量。Kubernetes 服务、节点和 pod 都通过 API 在 HTTP 或 HTTPS 上进行通信。将相同的零信任策略和流程应用到所有流量会明显提高安全性,并且这样做不会产生更多开销。此外,一开始便在所有位置应用零信任还有一个好处,可避免在南北向零信任实践发生改变后对东西向零信任实践进行修补的风险或麻烦。
准则 5:同时使用 Ingress controller 和 service mesh
虽然不用
Ingress controller
或
service mesh
也可以在 Kubernetes 中构建和运行应用,但如果您想轻松地让零信任成为基础架构中所有元素的默认设置,您就需要用到它们了。Ingress controller 包含了 API 网关和负载均衡器的一些较有用的功能。它的另一项强大优势是可以用作真正的反向代理,能够将流量路由到特定的 Kubernetes pod(与传统的负载均衡器不同)。service mesh 从根本上简化了零信任在东西向流量上的实施、面向审计和验证目的的可观测性和报告。因此,如果您想通过更简单、更清晰的方式实现零信任,那么请在架构设计时同时考虑 Ingress controller 和 service mesh。
准则 6:将 Ingress controller 与 service mesh 集成
该准则与准则 5 密切相关。并非所有 Ingress controller 都可以与所有 service mesh 紧密集成。例如,基于 Istio 的 service mesh 使用与 NGINX Ingress Controller 不同类型的证书管理系统。在设计阶段确保这两个工具能够轻松地紧密集成,可以避免日后出现严重的复杂性和配置问题。有关集成南北向和东西向解决方案的示例,请阅读我们的博文
“如何简化 Kubernetes 出入向流量管理”
。
准则 7:自动化证书的正确处理
对于其他大多数安全的连接形式,证书维护对于在 Kubernetes 中运行用于加密的公钥基础设施 (PKI) 组件至关重要。而对于零信任一致性,证书管理必须是自动化和动态的,这意味着证书需要定期过期和轮换,以确保持续进行身份验证。service mesh 和 Ingress controller 都需要自动进行证书颁发、轮换和到期。如果 Ingress controller 或 service mesh 的本地或最佳集成证书管理工具无法做到这一点,您要不就需要想其他办法,要不就得选择放弃。
更多资源
想要更及时全面地获取 NGINX 相关的技术干货、互动问答、系列课程、活动资源?
请前往 NGINX 开源社区:
「其他文章」
- 选择合适的 API 网关模式,实现有效的 API 交付
- 分享实录|NGINX Gateway API(下)
- 分享实录|NGINX Gateway API(上)
- 如何在 NGINX 中安全地分发 SSL 私钥
- 课程实录 | 从 0 搭建高可用 Wordpress 博客(上)
- 实现 10 倍应用性能提升的 10 个技巧
- 将 NGINX 部署为 API 网关,第 1 部分
- 避免 10 大 NGINX 配置错误(下)
- 如何应对突发的流量激增和服务器过载问题
- 解决 NGINX LDAP 参考实施中的安全问题
- 收藏!0基础开源数据可视化平台FlyFish大屏开发指南
- 使用 NGINX 作为对象存储网关
- 借助 TCP 负载均衡和 Galera 集群扩展 MySQL
- 一张小图看尽 Nginx
- 在 Kubernetes 中实施零信任的七条准则
- API 网关 vs. Ingress Controller vs. Service Mesh,该怎么选?
- NGINX QUIC 和 HTTP/3 开发路线图
- NGINX Ingress Controller 2.0 版:那些你不得不知道的事儿
- 一把王者的时间,我就学会了 Nginx!
- NGINX 登顶全球 Web 服务器榜单,未来前景更为乐观