使用NGINX为Kubernetes应用构建零信任安全架构

NGINX | 2022年9月26日

网络安全攻击的复杂程度和数量正呈指数级增长，使部署在本地、混合和多云Kubernetes环境中的应用面临显著的暴露风险。传统安全模型以边界为基础，假定处于环境安全边界内的用户可信，用户之间的通信也安全。在当今的分布式环境中，边界内已不再存在所谓的安全区域；源自环境“内部”的通信可能与外部威胁同样危险。

本文将探讨采用零信任模型保护Kubernetes基础设施的优势，以及NGINX如何帮助改善安全态势。

什么是零信任？

零信任是一种基于身份而非位置的安全模型。该模型假定，任何访问应用、数据和设备的请求都可能是攻击，无论请求者看似位于本地、远程位置还是云端。

为落实零信任的三项核心原则，即永不信任、始终验证、持续监控，每个用户、服务、应用和设备都必须持续提供身份验证和授权证明。系统根据动态访问策略，按照最小权限原则授予有时限的权限。

所有通信均经过加密，并通过策略决策点/策略执行点（PDP/PEP）进行路由。该决策点/执行点会对所有相关方进行身份验证，并根据动态访问策略授予相应权限。此外，还提供审计、监控、报告和自动化功能，用于分析、评估和缓解安全风险。

零信任如何改善安全态势

零信任可通过以下几种方式改善安全态势：

自动阻止未经授权的活动
实施访问控制，减少暴露的攻击面
检测行为异常和失陷指标
定义实时最小权限策略，限制访问时长
持续进行身份认证和验证，以阻止正在进行的攻击

对于在Kubernetes环境中运行的现代云原生应用，零信任尤为重要。分布式应用和服务采用松耦合、可移植的架构，经容器化后跨混合多云环境运行，无法采用基于位置的安全机制。因此，安全必须依赖对身份和权限的持续验证、端到端加密及监控。

如何实现零信任安全

要遵循零信任原则，Kubernetes环境必须为用户、应用和服务提供身份验证、授权、访问控制、策略、加密、监控和审计等关键安全功能。

一种可行的方法是将安全功能内置到应用本身。但这意味着开发人员必须实施多项安全流程，包括建立和验证信任、管理用户身份和证书、加密和解密所有通信等。他们还必须了解并集成TLS和单点登录（SSO）等第三方技术。这不仅会让本已复杂的Kubernetes部署更加复杂，还会分散开发人员的精力，使其无法专注于真正需要（也希望）完成的工作：优化应用的业务功能。

不必担心，还有更好的方法：将安全及其他非功能性需求交由Kubernetes基础设施处理。Kubernetes集群连接工具（例如Ingress控制器和服务网格）可为应用和服务之间的所有通信提供策略决策点（PDP）和策略执行点（PEP），无论通信是由用户还是其他应用或服务发起。这样，您就能专注于核心业务专长和功能，同时更快、更轻松地交付应用。

F5 NGINX 如何提供帮助

如下图所示，NGINX安全Kubernetes连接解决方案包含所需的全部基础设施无关型组件和工具，可在本地、混合和多云等任何环境中，端到端地大规模保护用户、分布式应用、微服务和API。该解决方案由广受欢迎的数据平面提供支持，整合了：

NGINX Ingress Controller作为Kubernetes的Ingress控制器和PDP/PEP，可与第三方身份认证和SSO提供商集成。基于NGINX Plus，NGINX Ingress Controller可处理高级连接、监控和可见性、身份认证和SSO，并充当API网关。
NGINX Service Mesh是一款轻量级、开箱即用且对开发者友好的服务网格，可保护Kubernetes集群内的服务连接。与每个Kubernetes服务共置并充当PDP/PEP的企业级边车基于NGINX Plus构建。
NGINX App Protect为现代应用和API提供全面保护，基于F5广受市场认可的安全技术构建。它采用模块化方法，可灵活适应不同部署场景并优化资源利用率：
- NGINX App Protect WAF，一款功能强大且轻量级的WAF，可防范OWASP十大安全风险，并满足PCI DDS合规要求
- NGINX App Protect DoS，通过行为分析检测和缓解DoS，并在不同云环境和架构中提供一致且自适应的防护

NGINX解决方案可帮助您：

在分布式环境中集成强大的安全控制措施，同时不降低发布速度或影响性能
通过持续身份认证、身份验证和行为异常检测，自动阻止正在进行的攻击
实施实时最小权限策略、精细化访问控制和端到端加密，并在多个团队之间开展治理
借助集成式强大WAF和应用级DoS防御，实现从代码到客户的应用安全交付
利用细粒度的实时和历史指标，持续评估并改善Kubernetes环境的安全状况
通过整合技术，简化安全的用户到服务及服务到服务通信的部署和管理

使用NGINX实施全面的零信任安全

随着组织规模扩大，将并非应用功能所特有的要求（例如零信任安全功能）从应用层卸载变得至关重要。如上所述，这可以让开发人员不必在各个应用中构建、维护和复制安全逻辑，而是能够轻松利用平台层面的安全技术。NGINX通过部署在集群边缘的NGINX Ingress Controller和集群内部的NGINX Service Mesh，为Kubernetes提供集中式安全策略实施。根据应用安全要求，可以在集群边缘或内部部署NGINX App Protect WAF和DoS，以增强应用防护，抵御复杂的网络攻击。

下面深入了解NGINX解决方案如何提供所需功能，帮助您为Kubernetes部署实施全面的零信任安全。

身份验证和授权

零信任安全的一项关键原则是，对每台设备、每位用户、每项服务和每个请求进行身份验证和授权。身份验证是核实身份的过程，也就是确保通信中的每一方都与其声称的身份相符。授权是核实某一方是否有权按其请求访问资源或功能的过程。

为落实这一原则，NGINX解决方案提供了多种身份验证和授权实施方式，包括HTTP基本身份验证、JSON Web令牌（JWT），以及通过与Okta和Azure Active Directory（AD）等身份提供商集成来使用OpenID Connect。NGINX解决方案还会向服务颁发安全身份（类似于以证书形式向应用用户颁发身份证明），使这些服务能够通过身份验证和授权，在整个Kubernetes集群中执行操作。除处理工作负载身份外，NGINX解决方案还通过与公钥基础设施（PKI）和证书颁发机构的内置集成，实现证书管理自动化。

由于NGINX Ingress Controller已在检查所有进入集群的请求，并将其路由到相应的服务，因此它是集中进行用户身份验证和授权的高效位置，在某些场景下也适合进行服务身份验证。

有关更多详细信息，请阅读博客文章《使用Okta和NGINX Ingress Controller为Kubernetes实施OpenID Connect身份验证》。

数据加密与完整性

零信任的另一项原则是，无论通信参与方位于何处，都必须保护所有通信，确保其机密性和完整性。未经授权的各方不得读取数据，也不得在传输过程中修改数据。为遵循这一原则，NGINX解决方案对用户到服务的通信采用SSL/TLS加密，对服务到服务的通信采用双向TLS（mTLS）身份验证和加密。

如果应用架构不涉及Kubernetes集群内的服务间通信，NGINX Ingress Controller或许足以满足数据完整性需求。基本选项有两种：

借助TLS Passthrough，NGINX Ingress Controller可将SSL/TLS加密连接直接路由到服务，无需解密，也无需访问SSL/TLS证书或密钥。
使用SSL/TLS终止时，NGINX Ingress Controller充当反向代理，终止与请求方之间的TLS连接，然后使用mTLS或服务端SSL/TLS对与Kubernetes服务（后端和上游服务器）建立的新连接进行加密。

如果您的架构涉及集群内的服务间通信，则需要同时使用NGINX Ingress Controller和NGINX Service Mesh来确保数据完整性。NGINX Service Mesh可确保只有特定服务能够相互通信，并使用mTLS对这些服务进行身份验证，同时加密服务间的通信。借助NGINX Service Mesh，可以“零接触”方式实施mTLS，这意味着开发人员无需为应用程序改造证书支持，甚至无需了解正在进行双向身份验证。

要详细了解如何保护Kubernetes集群中的通信，请阅读我们博客上的《NGINX Service Mesh中的mTLS架构》。

访问控制和访问策略

访问控制是零信任模型中的另一个关键要素。Kubernetes使用基于角色的访问控制（RBAC）来规定不同用户可以访问哪些资源以及执行哪些操作。它决定了用户或用户组如何与集群中的任何Kubernetes对象或命名空间进行交互。

NGINX Kubernetes连接解决方案支持RBAC，可轻松与贵组织的安全策略保持一致。启用RBAC后，用户可以按权限访问工作所需的功能，无需提交IT工单并等待处理。如果没有RBAC，用户可能会获得不需要或无权拥有的权限；一旦这些权限遭到滥用，可能会产生安全漏洞。

为NGINX Ingress Controller配置RBAC后，可根据组织的应用开发和交付环境中的不同角色分配相应权限，从而控制众多人员和团队的访问权限。其精细化访问管理工具支持多个团队实现自助服务和治理。

要了解如何将RBAC与NGINX Ingress Controller结合使用，请观看我们在DevNetwork上的网络研讨会：使用NGINX Ingress Controller进行高级Kubernetes部署。从13:50开始，我们的专家将讲解如何利用RBAC和资源分配来实现安全性、自助服务和多租户。

可观测性

审计、监控、日志记录、追踪和报告是零信任环境中的关键要素。收集的Kubernetes应用基础设施状态信息越多，并且关联、分析和评估这些信息的效率越高，就越有助于增强安全态势。

您可能已在Kubernetes部署中使用监控工具，无需再增加一个。为了全面呈现集群内部的运行状况，我们为NGINX Plus API添加了检测功能，便于将指标导出到任何接受JSON的第三方工具，并提供与以下常用工具的预构建集成：OpenTelemetry以及Grafana和Prometheus。通过深度跟踪，可以有针对性地洞察应用连接情况，了解请求的端到端处理过程：NGINX Ingress Controller可洞察集群与外部客户端之间的连接情况，而NGINX Service Mesh则涵盖集群内基于容器化微服务的应用和服务之间的连接。

WAF和DoS防护

NGINX App Protect可保护分布式应用免受OWASP十大安全风险和第7层拒绝服务（DoS）攻击等威胁，进一步增强应用安全性。作为端到端NGINX安全连接解决方案的重要组成部分，NGINX App Protect提供敏捷、以应用为中心的安全防护，可抵御复杂威胁，其能力远不止基本特征码检测。它利用F5值得信赖的先进安全专业能力，同时不会影响发布速度和性能。它还可轻松将安全遥测数据转发至第三方分析和可视化解决方案，并通过高置信度特征码和自动化行为分析减少误报。

NGINX App Protect采用模块化设计，可根据需要在同一实例或不同实例上部署WAF和DoS防护中的一种或两种。例如，可以将其与NGINX Ingress Controller一起部署在集群边缘，从而为整个集群提供一致的精细化防护。如果需要为集群中的多个应用实施应用专属策略，则可在服务或Pod级别部署WAF和DoS防护中的一种或两种。

要详细了解如何部署WAF和DoS防护，请阅读我们博客上的文章《安全工具左移，打造更安全的应用》。